Unterstützte Browser
- 68
- 79
- x
- x
Bei modernen Browsern werden Seiten manchmal ausgesetzt oder vollständig verworfen, Systemressourcen begrenzt sind. Künftig möchten Browser damit sie weniger Strom und Arbeitsspeicher verbrauchen. Die Page Lifecycle API bietet Lebenszyklus-Hooks, damit Ihre Seiten diese Browser sicher verarbeiten können ohne die Nutzererfahrung zu beeinträchtigen. Werfen Sie einen Blick auf die API, ob Sie diese Funktionen in Ihrer Anwendung implementieren sollten.
Hintergrund
Der Anwendungslebenszyklus spielt bei modernen Betriebssystemen eine wichtige Rolle Ressourcen. Auf Android- und iOS-Geräten sowie neueren Windows-Versionen lassen sich Apps starten und jederzeit vom Betriebssystem angehalten werden. So können diese Plattformen Ressourcen so umverteilen, wo sie den Nutzenden am meisten zugutekommen.
Im Web gibt es einen solchen Lebenszyklus noch nie und Apps können daher beibehalten werden, für unbestimmte Zeit lebendig werden. Da eine große Anzahl von Webseiten aktiv ist, Ressourcen wie Arbeitsspeicher, CPU, Akku und Netzwerk überlastet sind, was zu einer schlechten Endnutzererfahrung führt.
Auf der Webplattform gab es schon lange Ereignisse, die sich auf den Lebenszyklusstatus beziehen.
– z. B. load,
unload und
visibilitychange
— diese Ereignisse ermöglichen nur Entwicklern
um auf vom Nutzer initiierte Änderungen des Lebenszyklusstatus zu reagieren. Damit das Web funktioniert
zuverlässig auf leistungsschwachen Geräten (und achten Sie allgemein
Plattformen) müssen Browser eine Möglichkeit bieten, Systeme proaktiv zurückzufordern und neu zuzuweisen
Ressourcen.
Browser ergreifen bereits heute aktive Maßnahmen zur Schonung von Ressourcen. für Seiten im Hintergrund. Viele Browser, insbesondere Chrome, um wesentlich mehr davon zu tun – um ihren Ressourcenbedarf insgesamt zu verringern.
Das Problem ist, dass sich Entwickler nicht auf diese Arten von vom System initiierte Maßnahmen einleiten oder sogar wissen, dass sie erfolgen. Das bedeutet, müssen die Browser konservativ sein, da sonst die Gefahr besteht, dass Webseiten beschädigt werden.
Die Page Lifecycle API versucht, dieses Problem auf folgende Weise zu lösen:
- Einführung und Standardisierung des Konzepts von Lebenszyklusstatus im Web
- Definieren neuer, vom System initiierter Status, die es Browsern ermöglichen, Ressourcen, die von ausgeblendeten oder inaktiven Tabs verbraucht werden können.
- Erstellen neuer APIs und Ereignisse, mit denen Webentwickler auf vom System initiierte Zustände wechseln.
Diese Lösung bietet die Vorhersehbarkeit, die Webentwickler für und Anwendungen sind widerstandsfähiger gegen Systemeingriffe und können Browser die Systemressourcen aktiv optimieren, wovon letztendlich alle Webnutzer profitieren.
Im weiteren Verlauf dieses Beitrags stellen wir die neuen Funktionen des Seitenlebenszyklus vor. und untersuchen, wie sie mit den bestehenden Webplattformstatus zusammenhängen, und Ereignisse. Außerdem erhalten Sie Empfehlungen und Best Practices für die Typen der Arbeit, die Entwickler in jedem Bundesstaat durchführen sollten (und sollten nicht).
Status und Ereignisse des Seitenlebenszyklus – Übersicht
Alle Status des Seitenlebenszyklus sind diskret und schließen sich gegenseitig aus, d. h. eine Seite kann jeweils nur einen Status haben. Die meisten Änderungen am Lebenszyklusstatus einer Seite im Allgemeinen über DOM-Ereignisse beobachtbar sind. Ausnahmen finden Sie in den Entwicklerempfehlungen für die einzelnen Status.
Das ist die vielleicht einfachste Möglichkeit, die Status der Seitenlebenszyklus Die Ereignisse, die Signale zwischen ihnen übertragen, finden Sie in einem Diagramm:
<ph type="x-smartling-placeholder">
Bundesstaaten
In der folgenden Tabelle werden die einzelnen Bundesstaaten ausführlich erläutert. Außerdem werden die möglichen Bundesstaaten, die vorher und nachher kommen können, sowie die Ereignisse, die Entwickler um Veränderungen zu beobachten.
| Status | Beschreibung |
|---|---|
| Aktiv |
Eine Seite hat den Status Aktiv, wenn sie sichtbar und Eingabefokus.
Mögliche vorherige Status: |
| Passiv |
Eine Seite ist im passiven Status, wenn sie sichtbar und nicht keinen Eingabefokus haben.
Mögliche vorherige Status:
Mögliche nächste Status: |
| Ausgeblendet |
Eine Seite befindet sich im Status ausgeblendet, wenn sie nicht sichtbar ist eingefroren, verworfen oder beendet wurden).
Mögliche vorherige Status:
Mögliche nächste Status: |
| Eingefroren |
Im Status eingefroren hält der Browser die Ausführung von
<ph type="x-smartling-placeholder"></ph>
einfrierend
Aufgaben im
Aufgabenwarteschlangen, bis die Fixierung der Seite aufgehoben wird. Das sind Dinge wie
JavaScript-Timer und Abruf-Callbacks werden nicht ausgeführt. Wird bereits ausgeführt
Aufgaben abgeschlossen werden können (vor allem die
Browser fixieren Seiten, um die CPU-, Akku- und Datennutzung zu schonen. sie um eine schnellere <ph type="x-smartling-placeholder"></ph> hin- und herwechseln, sodass keine ganze Seite erforderlich ist. neu laden.
Mögliche vorherige Status:
Mögliche nächste Status: |
| Beendet |
Eine Seite hat den Status Beendet, sobald sie begonnen hat, vom Browser entladen und aus dem Speicher gelöscht. Nein <ph type="x-smartling-placeholder"></ph> können neue Aufgaben in diesem Status beginnen und laufende Aufgaben getötet werden, wenn sie zu lange laufen.
Mögliche vorherige Status:
Mögliche nächste Status: |
| Verworfen |
Eine Seite hat den Status Verworfen, wenn sie vom um Ressourcen zu sparen. Keine Aufgaben, Ereignis-Callbacks oder In diesem Zustand kann jeder JavaScript-Code ausgeführt werden, da Verwerfungen in der Regel treten bei Ressourceneinschränkungen auf, bei denen das Starten neuer Prozesse unmöglich ist. Im Status Verworfen befindet sich der Tab selbst. (einschließlich Tab-Titel und Favicon) ist normalerweise für den Nutzer sichtbar. obwohl die Seite verschwunden ist.
Mögliche vorherige Status:
Mögliche nächste Status: |
Ereignisse
Browser senden viele Ereignisse, aber nur ein kleiner Teil davon signalisiert Mögliche Änderung des Status des Seitenlebenszyklus. In der folgenden Tabelle sind alle Ereignisse aufgeführt. die sich auf den Lebenszyklus beziehen und welche Stadien sie wechseln können.
| Name | Details |
|---|---|
focus
|
Ein DOM-Element hat den Fokus erhalten.
Hinweis: Ein
Mögliche vorherige Status:
Mögliche aktuelle Status: |
blur
|
Ein DOM-Element hat den Fokus verloren.
Hinweis: Ein
Mögliche vorherige Status:
Mögliche aktuelle Status: |
visibilitychange
|
Das Dokument
<ph type="x-smartling-placeholder"></ph>
Mögliche vorherige Status:
Mögliche aktuelle Status: |
<ph type="x-smartling-placeholder"></ph>
freeze
*
|
Die Seite wurde gerade eingefroren. Beliebig <ph type="x-smartling-placeholder"></ph> Freezable-Aufgabe in den Aufgabenwarteschlangen der Seite nicht gestartet wird.
Mögliche vorherige Status:
Mögliche aktuelle Status: |
<ph type="x-smartling-placeholder"></ph>
resume
*
|
Der Browser hat eine eingefrorene Seite fortgesetzt.
Mögliche vorherige Status:
Mögliche aktuelle Status: |
pageshow
|
Es wird ein Sitzungsverlaufseintrag durchsucht. Dies kann entweder ein neuer Seitenaufbau oder eine Seite aus der
Back-Forward-Cache aus. Wenn die Seite
aus dem Back-Forward-Cache entnommen wurde,
Das Attribut
Mögliche vorherige Status:
Mögliche aktuelle Status: |
pagehide
|
Ein Sitzungsverlaufseintrag wird durchlaufen. Wenn der Nutzer zu einer anderen Seite navigiert und der Browser
von der aktuellen Seite zum Zurück-/Vorwärts-
zur späteren Verwendung im Cache, die Eigenschaft
Mögliche vorherige Status:
Mögliche aktuelle Status: |
beforeunload
|
Das Fenster, das Dokument und seine Ressourcen werden gleich entladen. Das Dokument ist weiterhin sichtbar und der Termin kann zu diesem Zeitpunkt noch abgebrochen werden Punkt.
Wichtig: Das Ereignis
Mögliche vorherige Status:
Mögliche aktuelle Status: |
unload
|
Die Seite wird entladen.
Warnung:
die Verwendung des Ereignisses
Mögliche vorherige Status:
Mögliche aktuelle Status: |
* Weist auf ein neues Ereignis hin, das von der Page Lifecycle API definiert wurde.
Neue Funktionen in Chrome 68
Das vorherige Diagramm zeigt zwei Zustände, die nicht vom System, sondern vom System initiiert werden. vom Nutzer initiiert: eingefroren und verworfen. Wie bereits erwähnt, bleiben Browser heute schon gelegentlich einfrieren und verwerfen (nach eigenem Ermessen) ausgeblendet, aber die Entwickler können nicht wissen, was passiert.
In Chrome 68 können Entwickler jetzt beobachten,
durch Listener für freeze aufgehoben
und resume Termine am document.
document.addEventListener('freeze', (event) => {
// The page is now frozen.
});
document.addEventListener('resume', (event) => {
// The page has been unfrozen.
});
Ab Chrome 68 enthält das document-Objekt jetzt ein
wasDiscarded
Property in Chrome für Computer (in dieser Ausgabe wird die Android-Unterstützung erfasst). Um zu ermitteln, ob eine Seite in einer ausgeblendeten
können Sie den Wert dieser Eigenschaft bei der Seitenladezeit überprüfen (Hinweis:
verworfene Seiten müssen neu geladen werden, damit sie wieder verwendet werden können.
if (document.wasDiscarded) {
// Page was previously discarded by the browser while in a hidden tab.
}
Tipps dazu, was du in den freeze und resume tun solltest
sowie zur Handhabung und Vorbereitung auf das Verwerfen von Seiten finden Sie unter
Entwicklerempfehlungen für jeden Bundesstaat.
In den nächsten Abschnitten erhalten Sie einen Überblick darüber, wie diese neuen Funktionen die Status und Ereignisse auf der Webplattform.
Status des Seitenlebenszyklus im Code beobachten
Aktiv, Passiv und Ausgeblendet ist es möglich, JavaScript-Code auszuführen, der den aktuellen Lebenszyklusstatus der Seite aus vorhandenen Webplattform-APIs.
const getState = () => {
if (document.visibilityState === 'hidden') {
return 'hidden';
}
if (document.hasFocus()) {
return 'active';
}
return 'passive';
};
Der Status eingefroren und beendet auf der
können dagegen nur im jeweiligen Event-Listener erkannt werden.
(freeze und pagehide), da der Bundesstaat
ändern.
Zustandsänderungen beobachten
Aufbauend auf der zuvor definierten getState()-Funktion können Sie alle Seiten
Der Lebenszyklusstatus ändert sich mit dem folgenden Code.
// 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);
Mit diesem Code werden drei Dinge umgesetzt:
- Legt den Anfangszustand mithilfe der Funktion
getState()fest. - Definiert eine Funktion, die einen nächsten Zustand annimmt und, falls es eine Änderung gibt, protokolliert die Statusänderungen in der Konsole.
- Hinzufügen
aufnehmen
für alle erforderlichen Lifecycle-Events, die wiederum
logStateChange()und übergibt den nächsten Status.
Zu beachten ist, dass alle Ereignis-Listener
an window und sie alle bestehen
{capture: true}
Das kann verschiedene Gründe haben:
- Nicht alle Lebenszyklusereignisse der Seite haben dasselbe Ziel.
pagehideundpageshowwerden amwindowausgelöst.visibilitychange,freezeundresumewerden aufdocumentausgelöst undfocusundblurwerden auf ihren DOM-Elemente. - Die meisten dieser Ereignisse werden nicht als Bubble angezeigt. Das heißt, es ist nicht möglich, Ereignisse hinzuzufügen, nicht die Erfassung von Ereignis-Listenern für ein gemeinsames Ancestor-Element, und beobachten alle von ihnen.
- Die Erfassungsphase findet vor der Ziel- oder Blasenphase statt. Listener sorgen dafür, dass sie ausgeführt werden, bevor anderer Code sie abbrechen kann.
Empfehlungen für Entwickler für jeden Bundesstaat
Als Entwickler ist es wichtig, den Status des Seitenlebenszyklus zu verstehen und wie Sie diese im Code beobachten können, denn die Art der Arbeit, nicht) davon abhängt, welchen Status Ihre Seite hat.
Es ist beispielsweise offensichtlich nicht sinnvoll, eine vorübergehende Benachrichtigung anzuzeigen. wenn die Seite ausgeblendet ist. Auch wenn dieses Beispiel Es gibt aber auch andere, nicht so offensichtliche Empfehlungen, die sich lohnen. Aufzählung.
| Status | Empfehlungen für Entwickler |
|---|---|
Active |
Der Status Aktiv ist die kritischste Zeit für den Nutzer. ist der wichtigste Zeitpunkt, <ph type="x-smartling-placeholder"></ph> auf Nutzereingaben reagieren. Alle Nicht-UI-Elemente, die den Hauptthread blockieren könnten, sollten herabgestuft werden. an Inaktivitätszeiten oder an einen Web Worker übertragen. |
Passive |
Im passiven Zustand interagiert der Nutzer nicht mit der Seite, aber er kann sie immer noch sehen. Das bedeutet, dass UI-Aktualisierungen und Animationen reibungslos sein, aber der Zeitpunkt dieser Aktualisierungen ist weniger wichtig. Wenn die Seite von aktiv zu passiv wechselt, ist es eine ist ein guter Zeitpunkt, um den nicht gespeicherten Anwendungsstatus beizubehalten. |
|
Wenn die Seite von passiver zu verborgener Seite wechselt, ist dass die Nutzenden erst wieder damit interagieren, wenn sie neu geladen wurde. Der Übergang zu hidden ist ebenfalls oft die letzte Statusänderung.
der von Entwickelnden zuverlässig beobachtet werden kann. Dies gilt insbesondere
da Nutzende Tabs oder die Browser-App selbst schließen können.
Der verborgene Zustand ist also das wahrscheinliche Ende des Nutzersitzung. Mit anderen Worten: Alle ungespeicherten App-Status beibehalten und nicht gesendete Analysedaten senden. Sie sollten auch keine Aktualisierungen der Benutzeroberfläche mehr vornehmen, da diese sonst nicht sichtbar sind. der Nutzenden) und Sie sollten alle Aufgaben beenden, die Nutzende nicht die im Hintergrund laufen. |
|
Frozen |
Im Status frozen (eingefroren) <ph type="x-smartling-placeholder"></ph> fixierte Aufgaben im Aufgabenwarteschlangen gesperrt werden, bis die Fixierung der Seite aufgehoben wird. Dies kann zu nie passieren (z.B. wenn die Seite verworfen wird). Wenn die Seite also von ausgeblendet zu eingefroren wechselt ist es wichtig, alle Timer zu stoppen oder Verbindungen zu trennen, Das Einfrieren könnte sich auf andere geöffnete Tabs mit demselben Ursprung auswirken oder sich auf die dass der Browser die Seite in der Back-Forward-Cache gespeichert werden. Insbesondere sind die folgenden Punkte wichtig:
Der Status der dynamischen Ansicht (z. B. Scrollposition) sollte beibehalten werden.
in einer unendlichen Listenansicht)
<ph type="x-smartling-placeholder"></ph>
Wenn die Seite von eingefroren wieder zu verborgen wechselt, können Sie geschlossene Verbindungen wieder öffnen oder als die Seite zunächst eingefroren war. |
Terminated |
In der Regel müssen Sie beim Wechsel einer Seite nichts unternehmen. in den Status terminated versetzt. Da Seiten, die aufgrund einer Nutzeraktion entladen werden, hidden, bevor Sie in den Status terminated wechseln. ist der Status hidden der Ort, an dem die Logik zum Beenden der Sitzung (z.B. bleibenden Anwendungsstatus und die Berichterstellung an Analytics) sollten durchgeführt wurde. Außerdem (wie in den Empfehlungen für
ausgeblendet), ist es für Entwickler sehr wichtig,
dass der Übergang in den Status Beendet nicht zuverlässig möglich ist
werden häufig erkannt (insbesondere auf Mobilgeräten), sodass Entwickler, die
bei Kündigungen (z.B. |
Discarded |
Der Status discarded kann von Entwicklern nicht erkannt werden. wann eine Seite verworfen wird. Das liegt daran, dass Seiten in der Regel werden unter Ressourceneinschränkungen verworfen und die Fixierung einer Seite aufgehoben, um ein Skript, das als Reaktion auf ein Verwerfen-Ereignis ausgeführt werden soll, in den meisten Fällen. Deshalb sollten Sie sich darauf vorbereiten,
von ausgeblendet zu eingefroren ändern.
auf die Wiederherstellung einer verworfenen Seite beim Laden der Seite reagieren,
Prüfen von |
Auch hier gilt: Da Zuverlässigkeit und Reihenfolge von Lebenszyklusereignissen die konsequent in allen Browsern implementiert sind. in der Tabelle ist die Verwendung PageLifecycle.js:
Zu vermeidende Legacy-Lebenszyklus-APIs
Die folgenden Ereignisse sollten nach Möglichkeit vermieden werden.
Das Unload-Ereignis
Viele Entwickler behandeln das unload-Ereignis als garantierten Callback und verwenden es als
ein Ende-der-Sitzungssignal, um den Status zu speichern und Analysedaten zu senden.
ist sehr unzuverlässig, insbesondere auf Mobilgeräten. Das unload-Ereignis ist nicht
in vielen typischen Unload-Situationen ausgelöst, z. B. beim Schließen eines Tabs aus dem Tab
oder die Browser-App über den App-Schnellzugriff schließen.
Aus diesem Grund ist es immer besser, sich auf die
visibilitychange-Ereignis, um zu bestimmen, wann eine Sitzung
und betrachten den verborgenen Zustand,
letzte zuverlässige Zeit zum Speichern von App- und Nutzerdaten
Darüber hinaus ist das bloße Vorhandensein eines registrierten unload-Event-Handlers (über
Entweder onunload oder addEventListener()) können Browser
um Seiten schneller im Back-Forward-Cache zu speichern
vorwärts und rückwärts zu laden.
In allen modernen Browsern wird empfohlen,
pagehide-Ereignis, um mögliche Seitenentladen (auch als das
beendet) anstelle des Ereignisses unload. Wenn Sie
Internet Explorer Version 10 und niedriger unterstützen,
pagehide-Ereignis erkennen und unload nur verwenden, wenn der Browser dies nicht unterstützt
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.
});
Das „beforeunload“-Ereignis
Das beforeunload-Ereignis hat ein ähnliches Problem wie das unload-Ereignis:
Bisher konnte das Vorhandensein eines beforeunload-Ereignisses auf den Seiten
da sie für den Back-Forward-Cache infrage kommen. Moderne Browser
die diese Einschränkung nicht haben. Obwohl einige Browser vorsichtshalber nicht ausgelöst werden,
beforeunload-Ereignis, wenn versucht wird, eine Seite im Back-Forward-Modus zu platzieren
was bedeutet, dass das Ereignis als End-of-Session-Signal nicht zuverlässig ist.
Außerdem werden einige Browser, einschließlich Chrome,
Erfordert eine Nutzerinteraktion auf der Seite, bevor das beforeunload-Ereignis zugelassen wird
was die Zuverlässigkeit zusätzlich beeinträchtigt.
Ein Unterschied zwischen beforeunload und unload besteht darin, dass
legitime Nutzung von beforeunload. Wenn Sie beispielsweise den Nutzer warnen möchten,
dass ungespeicherte Änderungen verloren gehen, wenn sie mit dem Entfernen der Seite fortfahren.
Da es gute Gründe für die Verwendung von beforeunload gibt, empfehlen wir Ihnen,
Fügen Sie nur beforeunload-Listener hinzu, wenn ein Nutzer nicht gespeicherte Änderungen hat.
sofort nach dem Speichern entfernen.
Mit anderen Worten: Vermeiden Sie das, weil dadurch ein beforeunload-Listener hinzugefügt wird.
unbedingt):
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);
}
});
Tun Sie dies stattdessen, da der Listener beforeunload nur hinzugefügt wird, wenn er
und entfernt sie, falls dies nicht der Fall ist):
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);
});
Häufig gestellte Fragen
Warum wird das Symbol „Wird geladen“ nicht angezeigt? Bundesstaat?
Die Page Lifecycle API definiert Status als diskret und schließen sich gegenseitig aus. Da eine Seite im aktiven, passiven oder ausgeblendeten Zustand geladen werden kann und da sie den Status ändern oder sogar beendet werden kann, bevor der Ladevorgang abgeschlossen ist. ist ein separater Ladezustand in diesem Paradigma nicht sinnvoll.
Meine Seite funktioniert wichtig, wenn sie ausgeblendet ist. Wie kann ich verhindern, dass sie eingefroren oder verworfen wird?
Es gibt viele legitime Gründe dafür, dass Webseiten bei der Ausführung nicht eingefroren werden sollten im ausgeblendeten Zustand. Das naheliegendste Beispiel ist eine App, die Musik abspielt.
Es gibt auch Situationen, in denen Chrome eine Seite verwirft,
z. B. ob sie ein Formular mit nicht eingereichten Nutzereingaben enthält
beforeunload-Handler, der warnt, wenn die Seite entladen wird.
Chrome geht beim Verwerfen von Seiten und sollten Sie davon ausgehen, dass es keine Auswirkungen auf die Nutzenden hat. Zum Beispiel Seiten, die im ausgeblendeten Zustand keine der folgenden Aktionen durchgeführt hat, werden verworfen, sofern keine extremen Ressourcenbeschränkungen gelten:
- Audio wird wiedergegeben
- WebRTC verwenden
- Tabellentitel oder Favicon aktualisieren
- Benachrichtigungen werden angezeigt
- Push-Benachrichtigungen senden
Für die aktuellen Listenfunktionen, mit denen bestimmt wird, ob ein Tab bedenkenlos eingefroren oder verworfen, siehe Heuristik beim Einfrieren und Wird verworfen in Chrome.
Was ist der Back-Forward-Cache?
Mit dem Begriff Back-Forward-Cache wird ein Navigationsoptimierung implementieren, die die Nutzung der Seiten die Vorwärts-Tasten.
Wenn ein Nutzer eine Seite verlässt, friert der Browser eine Version dieser Seite ein
sodass er schnell fortgesetzt werden kann, falls der Nutzer
„Zurück“- oder „Vorwärts“-Tasten. Denken Sie daran, dass das Hinzufügen eines unload
-Event-Handler verhindert, dass diese Optimierung möglich ist.
Das Einfrieren funktioniert in jeder Hinsicht die Browser nicht reagieren, um CPU/Akku zu schonen; Deshalb ist es als Teil des eingefrorenen Lebenszyklusstatus betrachtet.
Wenn ich keine asynchronen APIs im Status „eingefroren“ oder „beendet“ ausführen kann, wie kann ich dann Daten in IndexedDB speichern?
Im Status „eingefrorener“ oder „geschlossener Status“ einfrierende Aufgaben in der Aufgabenwarteschlange einer Seite Ausgesetzt werden, was asynchrone und Callback-basierte APIs wie IndexedDB bedeutet. nicht zuverlässig verwendet werden.
Zukünftig fügen wir den IDBTransaction-Objekten eine commit()-Methode hinzu,
Sie geben Entwicklern die Möglichkeit, effektiv schreibgeschützte Transaktionen auszuführen.
die keine Callbacks erfordern. Mit anderen Worten: Wenn die Entwickelnden nur schreiben,
Daten an IndexedDB zu senden und keine komplexe Transaktion aus Lesevorgängen durchzuführen
und schreibt, kann die Methode commit() beendet werden, bevor Aufgabenwarteschlangen erstellt werden.
angehalten (vorausgesetzt, die IndexedDB-Datenbank ist bereits geöffnet).
Für Code, der heute noch funktionieren muss, haben Entwickler jedoch zwei Möglichkeiten:
- Sitzungsspeicher verwenden:Sitzungsspeicher ist synchron und bleibt über Seitenverwirrungen hinweg erhalten.
- IndexedDB vom Service Worker verwenden:Ein Service Worker kann Daten in
IndexedDB verwendet, nachdem die Seite beendet oder verworfen wurde. Im
freeze- oderpagehide-Event-Listener, über den Sie Daten an Ihren Service Worker senden könnenpostMessage(), und der Service Worker kann die Daten speichern.
App im eingefrorenen und verworfenen Zustand testen
Wenn du testen möchtest, wie sich deine App im eingefrorenen und verworfenen Zustand verhält, kannst du Folgendes tun:
chrome://discards zum Einfrieren oder Verwerfen
offenen Tabs öffnen.
So kannst du sicherstellen, dass deine Seite die freeze und resume korrekt verarbeitet.
sowie das Flag document.wasDiscarded, wenn Seiten nach dem
ein Verwerfen.
Zusammenfassung
Entwickler, die die Systemressourcen der Geräte ihrer Nutzer respektieren möchten ihre Apps unter Berücksichtigung des Seitenlebenszyklus erstellen. Es ist wichtig, die Webseiten nicht übermäßig viele Systemressourcen verbrauchen, Nutzer nicht erwartet hatten,
Je mehr Entwickler mit der Implementierung der neuen Page Lifecycle APIs beginnen, desto sicherer wird festgelegt, dass Browser nicht verwendete Seiten einfrieren und verwerfen. Dieses verbrauchen Browser weniger Arbeitsspeicher, CPU, Akku und Netzwerkressourcen. was für die Nutzenden von Vorteil ist.