Obsługa przeglądarek
Nowoczesne przeglądarki czasami zawieszają strony lub całkowicie je odrzucają, gdy zasoby systemowe są ograniczone. W przyszłości przeglądarki chcą to robić proaktywnie, więc zużywają mniej energii i pamięci. Interfejs API cyklu życia strony udostępnia elementy cyklu życia, dzięki którym strony mogą bezpiecznie obsługiwać interwencje przeglądarki bez wpływu na komfort użytkownika. 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ą zasobami. Na Androidzie, iOS i w najnowszych wersjach Windowsa aplikacje mogą być uruchamiane i zatrzymywane w dowolnym momencie przez system operacyjny. Dzięki temu mogą one usprawnić działanie i przeznaczać zasoby tam, gdzie przyniosą one użytkownikom największe korzyści.
W internecie dotychczas nie było takiego cyklu życia, a aplikacje można przechowywać w nieskończoność. Przy dużej liczbie uruchomionych stron internetowych ważne zasoby systemowe, takie jak pamięć, procesor, bateria i sieć, mogą być nadmiarowe, co może negatywnie wpływać na wygodę użytkowników.
Platforma internetowa od dawna zawierała zdarzenia związane ze stanami cyklu życia, takie jak load
, unload
i visibilitychange
. Jednak te zdarzenia umożliwiają deweloperom reagowanie tylko na zmiany stanu cyklu życia zainicjowane przez użytkownika. Aby internet działał niezawodnie na urządzeniach o małej mocy (i ogólnie był bardziej oszczędny pod względem zasobów) przeglądarki muszą mieć możliwość proaktywnego odzyskiwania i przeznaczania zasobów systemowych.
W rzeczywistości przeglądarki już teraz podejmują aktywne działania w celu oszczędzania zasobów na stronach na kartach w tle, a wiele przeglądarek (zwłaszcza Chrome) chciałoby robić to jeszcze bardziej, aby zmniejszyć ogólne zużycie zasobów.
Problem polega na tym, że deweloperzy nie mają możliwości przygotowania się na tego typu interwencje inicjowane przez system ani nawet nie wiedzą, że mają one miejsce. Oznacza to, że przeglądarki muszą być zachowawcze, aby nie uszkodzić stron internetowych.
Interfejs Page Lifecycle API próbuje rozwiązać ten problem, wykonując te czynności:
- Wprowadzenie i standaryzacja koncepcji stanów cyklu życia w internecie.
- Definiowanie nowych stanów inicjowanych przez system, które umożliwiają przeglądarkom ograniczanie zasobów, z których mogą korzystać ukryte lub nieaktywne karty.
- Tworzenie nowych interfejsów API i zdarzeń, które umożliwiają deweloperom stron internetowych reagowanie na przejścia do i z tych nowych stanów inicjowanych przez system.
To rozwiązanie zapewnia przewidywalność, której programiści potrzebują do tworzenia aplikacji odpornych na interwencje systemowe, oraz pozwala przeglądarkom bardziej agresywnie optymalizować zasoby systemowe, co w efekcie przynosi korzyści wszystkim użytkownikom internetu.
W dalszej części tego posta przedstawimy nowe funkcje cyklu życia strony i omówimy ich związek ze wszystkimi stanami i zdarzeniami na platformie internetowej. Zawiera on również rekomendacje i sprawdzone metody dotyczące rodzajów prac, które deweloperzy powinni (lub nie powinni) wykonywać w każdym stanie.
Omówienie stanów cyklu życia strony i zdarzeń
Wszystkie stany cyklu życia strony są oddzielne i wykluczają się wzajemnie, co oznacza, że strona może znajdować się tylko w jednym stanie w danym momencie. Większość zmian stanu cyklu życia strony można zazwyczaj obserwować na podstawie zdarzeń DOM (wyjątki znajdziesz w zaleceniach dewelopera dla każdego stanu).
Najłatwiej wyjaśnić stany cyklu życia strony oraz zdarzenia sygnalizujące przejścia między nimi za pomocą diagramu:
Stany
Tabela poniżej zawiera szczegółowe informacje o każdym stanie. Zawiera ona też listę możliwych stanów, które mogą wystąpić przed i po zdarzeniu, a także zdarzenia, których deweloperzy mogą używać do obserwowania zmian.
Stan | Opis |
---|---|
Aktywne |
Strona jest w stanie aktywny, jeśli jest widoczna i ma fokus wprowadzania danych.
Możliwe stany poprzednie: |
Pasywna |
Strona jest w stanie pasywnym, jeśli jest widoczna i nie ma aktywnego pola wprowadzania danych.
Możliwe stany poprzednie:
Możliwe następne stany: |
Ukryta |
Strona jest w stanie ukrytej, jeśli nie jest widoczna (i nie została zamrożona, odrzucona ani zakończona).
Możliwe stany poprzednie:
Możliwe następne stany: |
Zablokowany |
W stanie zamrożonej przeglądarka wstrzymuje wykonywanie
zadań w
kolejkach zadań strony do momentu odmrożenia strony. Oznacza to, że takie elementy jak liczniki czasu JavaScript i wywołania zwrotne pobierania nie są uruchamiane. Zadania, które są już wykonywane, mogą się zakończyć (przede wszystkim wywołanie Przeglądarki blokują strony, aby zmniejszyć wykorzystanie procesora, baterii i danych, a także aby przyspieszyć przechodzenie wstecz i do przodu, unikając ponownego wczytywania całej strony.
Możliwe stany poprzednie:
Możliwe następne stany: |
Zakończona |
Gdy przeglądarka zacznie wyładowywać stronę i usuwać ją z pamięci, strona będzie w stanie zakończona. W tym stanie nie można uruchamiać nowych zadań, a trwająco wykonywane zadania mogą zostać przerwane, jeśli trwają zbyt długo.
Możliwe stany poprzednie:
Możliwe następne stany: |
Odrzucono |
Gdy przeglądarka wyładuje stronę, aby oszczędzać zasoby, strona jest w stanie odrzucona. W tym stanie nie można uruchamiać żadnych zadań, wywołań zwrotnych zdarzeń ani JavaScriptu, ponieważ odrzucenia zazwyczaj występują w przypadku ograniczeń zasobów, gdzie nie można uruchomić nowych procesów. W stanie odrzuconej karta (w tym jej tytuł i ikona) jest zwykle widoczna dla użytkownika, nawet jeśli strona została zamknięta.
Możliwe stany poprzednie:
Możliwe następne stany: |
Wydarzenia
Przeglądarki wysyłają wiele zdarzeń, ale tylko niewielka ich część sygnalizuje możliwą zmianę stanu cyklu życia strony. Tabela poniżej zawiera wszystkie zdarzenia związane z cyklem życia oraz stany, między którymi mogą się one przełączać.
Nazwa | Szczegóły |
---|---|
focus
|
element DOM został zaznaczony;
Uwaga: zdarzenie
Możliwe stany poprzednie:
Możliwe stany bieżące: |
blur
|
Element DOM utracił fokus.
Uwaga: zdarzenie
Możliwe stany poprzednie:
Możliwe stany bieżące: |
visibilitychange
|
Wartość
|
freeze
*
|
Strona została właśnie zablokowana. Nie rozpocznie się żadne zadanie podlegające zamrożeniu w kole zadania strony.
Możliwe stany poprzednie:
Możliwe aktualne stany: |
resume
*
|
Przeglądarka wznowiła zablokowaną stronę.
Możliwe stany poprzednie:
Możliwe stany bieżące: |
pageshow
|
Przechodzimy do wpisu z historii sesji. Może to być zupełnie nowa strona lub strona pobrana z pamięci podręcznej. Jeśli strona została pobrana z pamięci podręcznej stanu strony internetowej, właściwość
Możliwe stany poprzednie: |
pagehide
|
Przechodzimy z poziomu wpisu z historii sesji. Jeśli użytkownik przechodzi na inną stronę i przeglądarka może dodać bieżącą stronę do pamięci podręcznej stanu strony internetowej, aby użyć jej później, właściwość
Możliwe stany poprzednie:
Możliwe bieżące stany: |
beforeunload
|
Okno, dokument i jego zasoby zostaną wkrótce wyładowane. Dokument jest nadal widoczny, a wydarzenie można anulować.
Ważne: zdarzenie
Możliwe poprzednie stany:
Możliwe stany: |
unload
|
Trwa wyładowywanie strony.
Ostrzeżenie: używanie zdarzenia
Możliwe poprzednie stany:
Możliwe aktualne stany: |
* 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 przez użytkownika: zablokowano i odrzucone. Jak wspomnieliśmy wcześniej, obecne przeglądarki czasem się blokują i usuwają ukryte karty (według własnego uznania), ale deweloperzy nie mają możliwości sprawdzenia, kiedy to się dzieje.
W Chrome 68 deweloperzy mogą teraz obserwować, kiedy ukryta karta jest zablokowana i odblokowana, nasłuchując zdarzeń freeze
i resume
w systemie document
.
document.addEventListener('freeze', (event) => {
// The page is now frozen.
});
document.addEventListener('resume', (event) => {
// The page has been unfrozen.
});
Od wersji 68 w Chrome na komputery obiekt document
zawiera teraz właściwość wasDiscarded
(w tym zgłoszeniu śledzimy obsługę Androida). Aby sprawdzić, czy strona została odrzucona, gdy karta była ukryta, możesz sprawdzić wartość tej właściwości podczas wczytywania strony (uwaga: aby ponownie użyć odrzuconej strony, musisz ją ponownie załadować).
if (document.wasDiscarded) {
// Page was previously discarded by the browser while in a hidden tab.
}
Wskazówki dotyczące ważnych czynności w przypadku zdarzeń freeze
i resume
, a także informacje o tym, jak obsługiwać i przygotowywać strony do odrzucenia, znajdziesz w rekomendacjach dla programistów dotyczących każdego stanu.
W kolejnych sekcjach omawiamy, jak te nowe funkcje pasują do istniejących stanów i zdarzeń platformy internetowej.
Jak obserwować stany cyklu życia strony w kodzie
W stanach active (aktywny), passive (bierny) i hidden (ukryty) można uruchamiać kod JavaScript, który określa bieżący stan cyklu życia strony za pomocą istniejących interfejsów API platformy internetowej.
const getState = () => {
if (document.visibilityState === 'hidden') {
return 'hidden';
}
if (document.hasFocus()) {
return 'active';
}
return 'passive';
};
Stany zamrożone i zakończone można natomiast wykryć tylko w odpowiednich detektorówach zdarzeń (freeze
i pagehide
), ponieważ stany te się zmieniają.
Jak obserwować zmiany stanu
Korzystając z zdefiniowanej wcześniej funkcji getState()
, możesz obserwować wszystkie zmiany stanu cyklu życia strony za pomocą poniższego 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 przyjmuje następny stan i w razie zmiany rejestruje zmiany stanu w konsoli.
- Dodaje metody odbierające zdarzenia dla wszystkich niezbędnych zdarzeń cyklu życia, które z kolei wywołują metodę
logStateChange()
, przekazując jej następny stan.
Warto zwrócić uwagę na to, że wszystkie detektory zdarzeń zostały dodane do window
i wszystkie przekazują {capture: true}
.
Dzieje się tak z kilku przyczyn:
- Nie wszystkie zdarzenia z cyklu życia strony mają ten sam cel.
pagehide
ipageshow
są wywoływane w elementachwindow
;visibilitychange
,freeze
iresume
są wywoływane w elementachdocument
, afocus
iblur
są wywoływane w odpowiednich elementach DOM. - Większość z tych zdarzeń nie ma dymków, co oznacza, że nie można dodać detektorów zdarzeń, które nie przechwytują, do wspólnego elementu nadrzędnego i obserwować ich wszystkie.
- Faza przechwytywania jest wykonywana przed fazą celu lub bąbelka, dlatego dodanie w niej detektorów pomaga zapewnić ich uruchomienie, zanim inny kod je anuluje.
Rekomendacje deweloperów w każdym stanie
Jako programiści powinniście znać stany cyklu życia strony oraz wiedzieć, jak je sprawdzać w kodzie, ponieważ rodzaj działań, które należy wykonywać (lub nie), zależy w dużej mierze od stanu strony.
Nie ma sensu wyświetlanie użytkownikowi powiadomienia przejściowego, jeśli strona jest ukryta. Chociaż ten przykład jest dość oczywisty, warto wymienić inne, mniej oczywiste rekomendacje.
Stan | Rekomendacje dla deweloperów |
---|---|
Active |
Stan aktywny jest najważniejszy dla użytkownika, a więc strona powinna reagować na jego działania. Wszelkie zadania niezwiązane z interfejsem użytkownika, które mogą blokować wątek główny, powinny być odprawiane na dalszy plan podczas okresów bezczynności lub przekazywane do wątku internetowego. |
Passive |
W stanie pasywnym użytkownik nie wchodzi w interakcję ze stroną, ale nadal może ją widzieć. Oznacza to, że animacje i aktualizacje interfejsu powinny przebiegać płynnie, ale czas ich trwania nie jest tak istotny. Gdy strona zmieni stan z aktywnej na bierną, warto zapisać niezapisane stany aplikacji. |
Gdy strona zmieni się z pasywnej na ukrytą, użytkownik może nie wejść z nią ponownie w interakcję, dopóki strona nie zostanie ponownie wczytana. Przejście na tryb ukryty jest też często ostatnią zmianą stanu, która jest zauważalna dla deweloperów (zwłaszcza na urządzeniach mobilnych, ponieważ użytkownicy mogą zamykać karty lub samą przeglądarkę i w takich przypadkach zdarzenia Oznacza to, że stan ukryty należy traktować jako prawdopodobne zakończenie sesji użytkownika. Inaczej mówiąc, zachować niezapisane stany aplikacji i wysłać niezasłane dane analityczne. Powinieneś też przestać aktualizować interfejs (ponieważ użytkownik nie będzie widzieć tych zmian) i zatrzymać wszystkie zadania, których użytkownik nie chce wykonywać w tle. |
|
Frozen |
W stanie zamrożonej strony zadania podlegające zamrożeniu w kolejkach zadań są zawieszone do czasu odblokowania strony, co może nigdy nie nastąpić (np. jeśli strona zostanie odrzucona). Oznacza to, że gdy strona zmieni stan z ukrytej na zamrożoną, konieczne jest zatrzymanie wszystkich zegarów lub zerwanie połączeń, które w przypadku zamrożenia mogłyby wpłynąć na inne otwarte karty w tej samej domenie lub na możliwość umieszczenia strony w pamięci podręcznej przeglądarki. W szczególności ważne jest, aby:
Musisz też zachować stan dynamicznego widoku (np. pozycję przewijania w nieskończonej liście) w Jeśli strona zmieni się z zablokowanej z powrotem na ukrytą, możesz ponownie otworzyć wszystkie zamknięte połączenia lub ponownie uruchomić ankiety zatrzymane, gdy strona była początkowo zablokowana. |
Terminated |
Zwykle nie musisz nic robić, gdy strona przechodzi do stanu zakończona. Strony, które są wyładowywane w wyniku działania użytkownika, zawsze przechodzą przez stan ukryty, zanim staną się stanem zakończony. W stanie ukrytym powinna być wykonywana logika kończenia sesji (np. zapisywanie stanu aplikacji i raportowanie do Analytics). Ponadto (jak wspomniano w zaleceniach dotyczących stanu ukryty), deweloperzy powinni pamiętać, że w wielu przypadkach (zwłaszcza na urządzeniach mobilnych) nie można niezawodnie wykryć przejścia do stanu zakończony, dlatego deweloperzy, którzy polegają na zdarzeniach zakończenia (np. |
Discarded |
Deweloperzy nie mogą zauważyć stanu wyrzucony w momencie, gdy strona zostaje wyrzucona. Dzieje się tak, ponieważ strony są zazwyczaj odrzucane z powodu ograniczeń zasobów, a w większości przypadków odblokowanie strony tylko po to, aby umożliwić uruchomienie skryptu w odpowiedzi na zdarzenie odrzucenia, jest po prostu niemożliwe. W związku z tym musisz przygotować się na możliwość odrzucenia zmiany ze stanu ukryta na zablokowana. Następnie możesz zareagować na przywrócenie odrzuconej strony podczas wczytywania strony, zaznaczając pole |
Ponieważ niezawodność i kolejność zdarzeń cyklu życia nie są konsekwentnie wdrażane we wszystkich przeglądarkach, najłatwiej jest postępować zgodnie z zaleceniami w tabeli, używając pliku PageLifecycle.js.
Starsze interfejsy API cyklu życia, których należy unikać
Należy unikać tych zdarzeń, jeśli to możliwe.
Zdarzenie wyładowania
Wielu deweloperów traktuje zdarzenie unload
jako gwarantowany wywołanie zwrotne i używa go jako sygnału o zakończeniu sesji, aby zapisać stan i przesłać dane analityczne. Takie działanie jest jednak bardzo niepewne, zwłaszcza na urządzeniach mobilnych. Zdarzenie unload
nie jest wywoływane w wielu typowych sytuacjach rozładowania, np. przy zamykaniu karty w przełączniku kart na urządzeniu mobilnym lub zamykaniu aplikacji przeglądarki w przełączniku aplikacji.
Dlatego zawsze lepiej jest polegać na zdarzeniu visibilitychange
, aby określić, kiedy kończy się sesja, i uznać stan ukryty za ostatni niezawodny moment zapisywania danych aplikacji i użytkowników.
Co więcej, sama obecność zarejestrowanego modułu obsługi zdarzenia unload
(za pomocą onunload
lub addEventListener()
) może uniemożliwić przeglądarce umieszczanie stron w pamięci podręcznej stanu strony internetowej w celu szybszego wczytywania stron wstecz i do przodu.
We wszystkich nowoczesnych przeglądarkach zalecamy zawsze używać zdarzenia pagehide
, aby wykrywać możliwe wyładowania strony (czyli stan zakończony), zamiast zdarzenia unload
. Jeśli musisz obsługiwać Internet Explorera w wersji 10 i starszych, włącz wykrywanie zdarzenia pagehide
i używaj unload
tylko wtedy, gdy przeglądarka nie obsługuje 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
Zdarzenie beforeunload
ma podobny problem do zdarzenia unload
, ponieważ w przeszłości obecność zdarzenia beforeunload
mogła uniemożliwić stronom kwalifikowanie się do korzystania z pamięci podręcznej stanu strony internetowej. Nowoczesne przeglądarki nie mają tego ograniczenia. Niektóre przeglądarki nie wywołują zdarzenia beforeunload
, gdy próbują umieścić stronę w pamięci podręcznej wstecz/wprzód, co oznacza, że to zdarzenie nie jest wiarygodnym sygnałem końca sesji.
Poza tym niektóre przeglądarki (w tym Chrome) wymagają interakcji użytkownika na stronie przed zezwoleniem na uruchomienie zdarzenia beforeunload
, co jeszcze bardziej zwiększa niezawodność.
Jedną z różnic między beforeunload
a unload
jest to, że beforeunload
może być używany w legalnych celach. Możesz na przykład ostrzec użytkownika, że jeśli będzie kontynuować wylogowywanie, utraci niezapisane zmiany.
Ponieważ istnieją uzasadnione powody, dla których warto używać beforeunload
, zalecamy tylko dodawanie odbiorców beforeunload
, gdy użytkownik ma niezapisane zmiany, a następnie usuwanie ich natychmiast po zapisaniu.
Inaczej mówiąc, nie rób tego (ponieważ bezwarunkowo dodajesz listenera beforeunload
):
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);
}
});
Zamiast tego użyj tego kodu (ponieważ dodaje on parametr beforeunload
listener tylko wtedy, gdy jest to potrzebne, a usuwanie go, gdy nie jest to konieczne):
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 ma stanu „Ładowanie”?
Interfejs Page Lifecycle API definiuje stany jako oddzielne i wzajemnie się wykluczające. Strona może być ładowana w stanie aktywnym, pasywnym lub ukrytym, a ponieważ może zmieniać stan – a nawet zostać zamknięta – przed zakończeniem wczytywania, w ramach tego schematu osobny stan wczytywania nie ma sensu.
Moja strona wykonuje ważne zadania, gdy jest ukryta. Jak mogę zapobiec jej zamrożeniu lub odrzuceniu?
Istnieje wiele uzasadnionych powodów, dla których strony internetowe nie powinny być zamrażane podczas działania w stanie ukrytym. Najbardziej oczywistym przykładem jest aplikacja odtwarzająca muzykę.
Istnieją też sytuacje, w których odrzucenie przez Chrome strony może być ryzykowne, np. gdy zawiera ona formularz z nieprzesłanymi danymi wejściowymi użytkownika lub zawiera moduł obsługi beforeunload
, który ostrzega, gdy strona jest wyładowywana.
Na razie Chrome będzie ostrożnie odrzucać strony i robi to tylko wtedy, gdy ma pewność, że nie wpłynie to na użytkowników. Na przykład strony, które w stanie ukrytym mają wykonać jedną z tych czynności, nie zostaną odrzucone, chyba że zasoby będą skrajnie ograniczone:
- Odtwarzanie dźwięku
- Korzystanie z WebRTC
- Aktualizowanie tytułu tabeli lub jej ikony
- Pokazuję alerty
- Wysyłam powiadomienia push
Informacje o obecnych funkcjach listy, które służą do określania, czy kartę można bezpiecznie zamrozić lub odrzucić, znajdziesz w artykule Heurystyka zamrażania i odrzucania kart w Chrome.
Czym jest pamięć podręczna stanu strony internetowej?
Pamięć podręczna stanu strony internetowej to termin używany do opisania optymalizacji nawigacji, która jest implementowana w niektórych przeglądarkach, aby przyspieszyć korzystanie z przycisków Wstecz i Dalej.
Gdy użytkownik opuści stronę, przeglądarki tego typu blokują jej wersję, aby można było ją szybko wznowić, nawet jeśli użytkownik wróci za pomocą przycisków Wstecz lub Dalej. Pamiętaj, że dodanie unload
obsługi zdarzeń uniemożliwia tę optymalizację.
W praktyce zamrażanie jest takie samo jak zamrażanie przeglądarek w celu oszczędzania procesora lub baterii. Z tego powodu jest to uważane za część stanu cyklu życia zamrożonego.
Jeśli nie mogę uruchomić interfejsów API asynchronicznych w zamrożonym lub zakończonym stanie, jak mogę zapisać dane w IndexedDB?
W stanach zamrożonego i zakończonego zadania zamrożalne w kole zadań strony są zawieszone, co oznacza, że nie można niezawodnie używać interfejsów API asynchronicznych i opartych na wywołaniu zwrotnym, takich jak IndexedDB.
W przypadku kodu, który musi działać już teraz, deweloperzy mają 2 opcje:
- Używanie pamięci sesji: pamięć sesji działa synchronicznie i zapisuje dane po odrzuceniu strony.
- Użyj metody IndexedDB z skryptu service worker: skrypt service worker może przechowywać dane w IndexedDB po zamknięciu lub odrzuceniu strony. W detektorze zdarzeń
freeze
lubpagehide
możesz wysłać dane do skryptu service worker za pomocąpostMessage()
, który może zająć zapisywanie danych.
Testowanie aplikacji w zamrożonym i odrzuconym stanie
Aby sprawdzić, jak aplikacja zachowuje się w zamrożonym i odrzuconym stanie, możesz kliknąć chrome://discards
, aby zamrozić lub odrzucić dowolną otwartą kartę.
Dzięki temu możesz mieć pewność, że Twoja strona prawidłowo obsługuje zdarzenia freeze
i resume
, a także flagę document.wasDiscarded
podczas ponownego wczytywania stron po odrzuceniu.
Podsumowanie
Programiści, którzy chcą szanować zasoby systemowe urządzeń użytkowników, powinni tworzyć aplikacje z uwzględnieniem stanów cyklu życia strony. Ważne jest, aby strony internetowe nie zużywały nadmiernych zasobów systemowych w sytuacjach, których użytkownik nie przewidział.
Im więcej deweloperów zacznie wdrażać nowe interfejsy API cyklu życia strony, tym bezpieczniejsze będzie blokowanie i odrzucanie nieużywanych stron przez przeglądarki. Oznacza to, że przeglądarki będą zużywać mniej pamięci, procesora, baterii i zasobów sieciowych, co jest korzystne dla użytkowników.