Interfejs Page Lifecycle API

Philip Walton

Nowoczesne przeglądarki czasami zawieszają lub odrzucają strony, zasoby systemowe są ograniczone. W przyszłości przeglądarki chcą to robić proaktywnie zużywają więc mniej energii i pamięci. Interfejs Page Lifecycle API udostępnia punkty zaczepienia cyklu życia, dzięki którym strony mogą bezpiecznie obsługiwać i interwencji bez wpływu na wygodę użytkowników. Zapoznaj się z interfejsem API, aby: sprawdzić, czy warto wdrożyć te funkcje w aplikacji.

Tło

Cykl życia aplikacji to kluczowy sposób, w jaki nowoczesne systemy operacyjne zarządzają i zasobami Google Cloud. Na Androidzie, iOS i w najnowszych wersjach systemu Windows można uruchamiać aplikacje zatrzymana przez system operacyjny. Dzięki temu platformy mogą uprościć i usprawnić przydzielać zasoby tam, gdzie są najbardziej przydatne dla użytkownika.

W internecie wcześniej nie było takiego cyklu życia, a aplikacje można przechowywać, żyje bez końca. Przy dużej liczbie uruchomionych stron internetowych krytyczny system Zasoby takie jak pamięć, procesor, bateria i sieć mogą mieć nadmiarowe subskrypcje, co pogarsza wrażenia użytkowników.

Na platformie internetowej od dawna występowały zdarzenia związane ze stanami cyklu życia – np. load, unload i visibilitychange – te zdarzenia są dostępne tylko dla deweloperów aby reagować na zainicjowane przez użytkownika zmiany stanu cyklu życia. Aby internet mógł działać niezawodnie korzystające z urządzeń o niskim zużyciu energii (i przy większej świadomości zasobów na wszystkich platformach), potrzebują sposobu na proaktywne odzyskiwanie i przydzielanie systemu i zasobami Google Cloud.

Obecnie przeglądarki podejmują już aktywne działania, aby oszczędzać zasoby może wyświetlać się na kartach w tle, a wiele przeglądarek (zwłaszcza Chrome) robić to znacznie więcej, aby zmniejszyć ogólny zużycie zasobów.

Niestety deweloperzy nie są w stanie przygotować się na tego typu i interwencji inicjowanych przez system, a nawet wiedzą, że mają miejsce. Oznacza to, że że przeglądarki muszą być zachowawcze lub ryzykować uszkodzenia stron.

Interfejs Page Lifecycle API próbuje rozwiązać ten problem przez:

• Wprowadzenie i ustandaryzowanie koncepcji stanów cyklu życia w internecie.
• Definiowanie nowych stanów inicjowanych przez system, które umożliwiają przeglądarkom ograniczenie i które mogą zużywać ukryte lub nieaktywne karty.
• Tworzenie nowych interfejsów API i zdarzeń, które umożliwiają programistom tworzenie stron internetowych przejścia do i z tych nowych stanów zainicjowanych przez system.

Zapewnia ono przewidywalność, której programiści stron internetowych potrzebują aplikacji, są odporne na interwencje systemowe i pozwalają przeglądarkom agresywnie optymalizują zasoby systemowe, co przynosi korzyści wszystkim użytkownikom internetu.

W pozostałej części tego posta omówimy nowe funkcje Cykl życia strony. i dowiedzieć się, jak mają się one do wszystkich stanów platformy internetowej. i zdarzeniach. Znajdziesz w nim też rekomendacje i sprawdzone metody pracy programistów, którzy powinni (i nie powinni) wykonywać w każdym stanie.

Omówienie stanów cyklu życia strony i zdarzeń

Wszystkie stany cyklu życia strony są dyskretne i wzajemnie się wykluczają, czyli strona może znajdować się tylko w jednym stanie naraz. większość zmian stanu cyklu życia strony, można zazwyczaj obserwować za pomocą zdarzeń DOM (wyjątki znajdziesz w zaleceniach dewelopera dla każdego stanu).

Prawdopodobnie najprostszy sposób na wyjaśnienie stanów cyklu życia strony, a także zdarzenia sygnalizujące przejście między nimi – to schemat:

Stany

Tabela poniżej zawiera szczegółowe informacje na temat każdego stanu. Wyświetlane są też możliwe stanów, które mogą wystąpić przed i po niej, jak również wydarzenia, które programiści mogą które pozwalają obserwować zmiany.

Wydarzenia

Przeglądarki wysyłają wiele zdarzeń, ale tylko niewielka ich część sygnalizuje możliwa zmiana stanu cyklu życia strony. W poniższej tabeli znajdziesz informacje o wszystkich zdarzeniach które są powiązane z cyklem życia, i zawierają listę stanów, do których mogą przejść.

* wskazuje nowe zdarzenie zdefiniowane przez interfejs Page Lifecycle API.

Nowe funkcje dodane w Chrome 68

Poprzedni wykres przedstawia 2 stany, które są inicjowane przez system, a nie inicjowane przez użytkownika: zablokowane i odrzucone; Jak już wspominaliśmy, obecne przeglądarki już czasem zawieszają się i usuwają na ukrytych kartach (według własnego uznania), ale deweloperzy nie mają żadnego sposobu na to, to właśnie się dzieje.

W Chrome 68 deweloperzy mogą teraz obserwować, kiedy ukryta karta jest wstrzymywana odblokowujesz, słuchając utworu freeze i wydarzenia resume w dniu document.

document.addEventListener('freeze', (event) => {
  // The page is now frozen.
});

document.addEventListener('resume', (event) => {
  // The page has been unfrozen.
});

Od Chrome w wersji 68 obiekt document zawiera teraz wasDiscarded. w przeglądarce Chrome na komputerze (w tym problemie monitorujemy pomoc dotyczącą Androida). Sprawdzanie, czy strona została odrzucona po ukryciu , możesz sprawdzić jej wartość w czasie wczytywania strony (uwaga: aby ponownie użyć odrzuconych stron, trzeba je ponownie załadować).

if (document.wasDiscarded) {
  // Page was previously discarded by the browser while in a hidden tab.
}

Porady na temat tego, co należy zrobić na stronie freeze i resume oraz jak postępować w przypadku odrzucania stron i jak przygotować się na nie, zapoznaj się z artykułem zalecenia dla deweloperów dotyczące każdego stanu.

W kilku kolejnych sekcjach znajdziesz omówienie tego, jak nowe funkcje istniejących stanów i zdarzeń platformy internetowej.

Jak obserwować stany cyklu życia strony w kodzie

Dostępne opcje: aktywne, pasywne i ukryte można uruchomić kod JavaScript, który określi bieżącą Stan cyklu życia strony z istniejących interfejsów API platformy internetowej.

const getState = () => {
  if (document.visibilityState === 'hidden') {
    return 'hidden';
  }
  if (document.hasFocus()) {
    return 'active';
  }
  return 'passive';
};

Stany zawieszone i zakończone na może zostać wykryty tylko w odpowiednich detektorach zdarzeń. (freeze i pagehide) zgodnie z stanem zmian.

Jak obserwować zmiany stanu

Korzystając z zdefiniowanej wcześniej funkcji getState(), możesz obserwować wszystkie strony Stan cyklu życia zmieni się za pomocą tego kodu.

// Stores the initial state using the `getState()` function (defined above).
let state = getState();

// Accepts a next state and, if there's been a state change, logs the
// change to the console. It also updates the `state` value defined above.
const logStateChange = (nextState) => {
  const prevState = state;
  if (nextState !== prevState) {
    console.log(`State change: ${prevState} >>> ${nextState}`);
    state = nextState;
  }
};

// Options used for all event listeners.
const opts = {capture: true};

// These lifecycle events can all use the same listener to observe state
// changes (they call the `getState()` function to determine the next state).
['pageshow', 'focus', 'blur', 'visibilitychange', 'resume'].forEach((type) => {
  window.addEventListener(type, () => logStateChange(getState()), opts);
});

// The next two listeners, on the other hand, can determine the next
// state from the event itself.
window.addEventListener('freeze', () => {
  // In the freeze event, the next state is always frozen.
  logStateChange('frozen');
}, opts);

window.addEventListener('pagehide', (event) => {
  // If the event's persisted property is `true` the page is about
  // to enter the back/forward cache, which is also in the frozen state.
  // If the event's persisted property is not `true` the page is
  // about to be unloaded.
  logStateChange(event.persisted ? 'frozen' : 'terminated');
}, opts);

Ten kod ma trzy zadania:

• Ustawia stan początkowy za pomocą funkcji getState().
• Definiuje funkcję, która akceptuje następny stan, a jeśli wystąpiła zmiana, rejestruje zmiany stanu w konsoli.
• Dodania rejestrowanie detektorów wszystkich niezbędnych zdarzeń cyklu życia, które z kolei wywołują logStateChange() z następnym stanem.

Warto zapamiętać, że wszystkie detektory zdarzeń zostały dodane do: window. Wszystkie te osoby {capture: true} Dzieje się tak z kilku przyczyn:

• Nie wszystkie zdarzenia cyklu życia strony mają tę samą wartość docelową. pagehide i pageshow są uruchamiane na window; visibilitychange, freeze i Roboty resume są uruchamiane w dniu document, a w przypadku ich kont tagi „focus” i „blur” są uruchamiane odpowiednich elementów DOM.
• Większość z tych zdarzeń nie jest wyświetlana jako bąbelki, co oznacza, że nie da się dodać nieprzechwytujących detektorów zdarzeń ze wspólnym elementem nadrzędnym i obserwować wszystkie z nich.
• faza przechwytywania następuje przed fazą celu lub bąbelka, więc dodanie pozwalają na ich uruchomienie, zanim inny kod je anuluje.

Rekomendacje deweloperów w każdym stanie

Ponieważ jesteś deweloperem, ważne jest, aby rozumieć stany cyklu życia strony oraz jak obserwować je w kodzie – trzeba wiedzieć, jaki rodzaj pracy należy (i powinno) zależy od stanu strony.

Na przykład wyświetlanie powiadomienia tymczasowego nie ma sensu w przypadku, gdy strona jest ukryta. Ten przykład jest całkiem niezły są też inne, niezbyt oczywiste rekomendacje, które nie są tak oczywiste. wyliczać.

Przypominamy, że niezawodność i kolejność zdarzeń cyklu życia nie są spójnie wdrożona we wszystkich przeglądarkach, w tabeli jest użycie PageLifecycle.js.

Unikaj starszych interfejsów API cyklu życia

Poniższe zdarzenia należy unikać, gdy tylko jest to możliwe.

Zdarzenie wyładowania

Wielu deweloperów traktuje zdarzenie unload jako gwarantowane wywołanie zwrotne i używa go jako sygnału końca sesji, żeby zapisać stan i wysłać dane analityczne. jest bardzo mało wiarygodne, zwłaszcza na urządzeniach mobilnych. Zdarzenie unload nie: uruchamianie w wielu typowych sytuacjach, w tym podczas zamykania karty z karty. na urządzeniu mobilnym lub zamknij aplikację w przeglądarce.

Z tego powodu lepiej zawsze polegać na visibilitychange, aby określić, kiedy i uważamy, że stan ukryty jest ostatni niezawodny czas na oszczędzanie danych aplikacji i użytkowników.

Ponadto samo obecność zarejestrowanego modułu obsługi zdarzeń unload (w ramach onunload lub addEventListener()) może uniemożliwiać przeglądarkom aby szybciej umieszczać strony w pamięci podręcznej stanu strony internetowej wczytywania stron w przód i w tył.

We wszystkich nowoczesnych przeglądarkach zaleca się używanie pagehide, aby wykryć możliwe usunięcia strony (czyli zakończone), a nie w przypadku zdarzenia unload. Jeśli przeglądarki Internet Explorer w wersji 10 lub starszej, dodaj wykrywają zdarzenie pagehide i używają unload tylko wtedy, gdy przeglądarka nie obsługuje tej funkcji pagehide:

const terminationEvent = 'onpagehide' in self ? 'pagehide' : 'unload';

window.addEventListener(terminationEvent, (event) => {
  // Note: if the browser is able to cache the page, `event.persisted`
  // is `true`, and the state is frozen rather than terminated.
});

Zdarzenie beforeunload

ze zdarzeniem beforeunload występuje podobny problem jak ze zdarzeniem unload, ponieważ: wcześniej wystąpienie zdarzenia beforeunload uniemożliwiało stronom kwalifikuje się do korzystania z pamięci podręcznej stanu strony internetowej. Nowoczesne przeglądarki nie mają tego ograniczenia. Chociaż niektóre przeglądarki nie uruchamiają się ze względów bezpieczeństwa zdarzenie beforeunload podczas próby umieszczenia strony w przebiegu stanu strony internetowej. pamięci podręcznej, co oznacza, że zdarzenie nie jest wiarygodne jako sygnał zakończenia sesji. Oprócz tego niektóre przeglądarki (w tym Chrome) wymagać interakcji użytkownika na stronie przed zezwoleniem na zdarzenie beforeunload uruchomienia, co jeszcze bardziej wpływa na jego niezawodność.

Jedna z różnic między beforeunload a unload jest taka, że występuje zgodnie z prawem (beforeunload). Gdy na przykład chcesz ostrzec użytkownika, o niezapisanych zmianach, które utracą, jeśli będą kontynuować usuwanie strony.

Istnieją pewne powody, dla których warto używać usługi beforeunload, dlatego zalecamy tylko dodaj odbiorniki beforeunload, gdy użytkownik ma niezapisane zmiany, a następnie usuwać je natychmiast po ich zapisaniu.

Nie rób tego, ponieważ spowoduje to dodanie detektora beforeunload bezwarunkowo):

addEventListener('beforeunload', (event) => {
  // A function that returns `true` if the page has unsaved changes.
  if (pageHasUnsavedChanges()) {
    event.preventDefault();

    // Legacy support for older browsers.
    return (event.returnValue = true);
  }
});

Zrób tak (bo dodaje detektor beforeunload tylko wtedy, gdy i usuwa ją, gdy nie jest potrzebna):

const beforeUnloadListener = (event) => {
  event.preventDefault();
  
  // Legacy support for older browsers.
  return (event.returnValue = true);
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  removeEventListener('beforeunload', beforeUnloadListener);
});

Najczęstsze pytania

Dlaczego nie widzę przycisku „wczytywania”? w jakimś stanie?

Interfejs Page Lifecycle API określa stany, które są dyskretne i wzajemnie się wykluczają. Ponieważ strona może być ładowana jako aktywna, pasywna lub ukryta, ponieważ może on zmienić stan – a nawet zostać zamknięty – przed zakończeniem wczytywania, w tym modelu nie ma sensu.

Moja strona działa, gdy jest ukryta. Jak mogę zapobiec jej zablokowaniu lub odrzuceniu?

Istnieje wiele uzasadnionych powodów, dla których strony internetowe nie powinny być blokowane w stanie ukrytym. Najbardziej oczywistym przykładem jest aplikacja do odtwarzania muzyki.

Są też sytuacje, gdy odrzucenie strony przez Chrome może być ryzykowne, np. jeśli zawiera formularz z nieprzesłanymi danymi wejściowymi użytkownika Moduł obsługi beforeunload, który ostrzega przed wyładowywaniem strony.

Na razie Chrome będzie ostrożnie odrzucać strony i rób to tylko wtedy, gdy masz pewność, że nie ma to wpływu na użytkowników. Na przykład strony, które gdy zaobserwowano, że w trybie ukrycia wykonywana jest któraś z poniższych czynności. zostać odrzucona, chyba że zasoby są bardzo ograniczone:

• Odtwarzam dźwięk
• Korzystanie z WebRTC
• Aktualizowanie tytułu lub favikony tabeli
• Pokazuję alerty
• Wysyłam powiadomienia push

Na potrzeby bieżącej listy funkcji służących do określania, czy karta może być bezpiecznie zamrożone lub odrzucone, patrz: Heurystyka do zamrażania & Odrzucam w Chrome.

Co to jest pamięć podręczna stanu strony internetowej?

Pamięć podręczna stanu strony internetowej to termin opisujący optymalizacja nawigacji w niektórych przeglądarkach, czyli korzystanie z przyciskach przejścia dalej.

Gdy użytkownik opuści stronę, przeglądarki blokują jej wersję aby można ją było szybko wznowić w razie powrotu użytkownika za pomocą za pomocą przycisków Wstecz i Dalej. Pamiętaj, że dodanie właściwości unload moduł obsługi zdarzeń uniemożliwia przeprowadzenie tej optymalizacji.

We wszystkich intencjach i celach to zawieszenie działa tak samo jak które zawieszają się, by oszczędzać procesor lub baterię; Dlatego jest to jest częścią zawieszonego stanu cyklu życia.

Jak mogę zapisać dane w IndexedDB, jeśli nie mogę uruchomić asynchronicznych interfejsów API w stanie zawieszenia lub zakończenia?

W stanach zablokowanych i zablokowanych zadania, które można zablokować w kolejkach zadań na stronie. są zawieszone, co oznacza, że interfejsy API asynchroniczne i oparte na wywołaniach zwrotnych, takie jak IndexedDB których nie da się prawidłowo użyć.

W przyszłości dodamy do obiektów IDBTransaction metodę commit(), która pozwoli Zapewnij programistom możliwość przeprowadzania transakcji w rzeczywistości w trybie tylko do zapisu które nie wymagają wywołań zwrotnych. Innymi słowy, jeśli deweloper tylko pisze, danych do IndexedDB bez wykonywania złożonej transakcji składającej się z odczytów i zapisy, metoda commit() będzie mogła zakończyć działanie, zanim kolejki zadań zostaną zawieszone (przy założeniu, że baza danych IndexedDB jest już otwarta).

W przypadku kodu, który musi już działać dzisiaj, programiści mają do wyboru 2 opcje:

• Użycie pamięci sesji: miejsce na dane sesji jest synchroniczny i zachowywany w ramach odrzucania stron.
• Użyj metody IndexedDB z skryptu service worker: skrypt service worker może przechowywać dane IndexedDB po zamknięciu lub odrzuceniu strony. W: freeze lub Detektor zdarzeń pagehide, przez który możesz wysyłać dane do skryptu service worker postMessage(), a skrypt service worker może zapisać dane.

Testowanie aplikacji w stanie blokady i odrzuconej

Aby sprawdzić, jak aplikacja działa w stanie blokady i odrzucenia, otwórz stronę chrome://discards, aby zablokować lub odrzucić otwartych kart.

Dzięki temu będziesz mieć pewność, że strona prawidłowo obsługuje atrybuty freeze i resume zdarzeń oraz flagę document.wasDiscarded, gdy strony są odświeżane po odrzucenie.

Podsumowanie

Deweloperzy, którzy chcą szanować zasoby systemowe urządzeń użytkowników przy tworzeniu aplikacji z myślą o stanach cyklu życia strony. Bardzo ważne jest, nie zużywają nadmiernych zasobów systemowych w sytuacjach, w których użytkownik nie spodziewałby się

Im więcej deweloperów zacznie wdrażać nowe interfejsy API cyklu życia strony, tym bezpieczniejsze umożliwia przeglądarkom blokowanie i odrzucanie nieużywanych stron. Ten przeglądarki zużywają mniej pamięci, procesora, baterii i zasobów sieciowych co jest korzystne dla użytkowników.