Page Lifecycle API

Unterstützte Browser

  • Chrome: 68 <ph type="x-smartling-placeholder">
  • Edge: 79. <ph type="x-smartling-placeholder">
  • Firefox: nicht unterstützt <ph type="x-smartling-placeholder">
  • Safari: nicht unterstützt. <ph type="x-smartling-placeholder">

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">
</ph> <ph type="x-smartling-placeholder"></ph> Eine visuelle Darstellung des in diesem Dokument beschriebenen Zustands- und Ereignisflusses.
Page Lifecycle API-Status und Ereignisfluss.

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:
passiver (über das Ereignis focus)
gefroren (über das Ereignis resume, dann pageshow-Ereignis)

Mögliche nächste Status:
passiver (über das Ereignis blur)

Passiv

Eine Seite ist im passiven Status, wenn sie sichtbar und nicht keinen Eingabefokus haben.

Mögliche vorherige Status:
aktiv (über das Ereignis blur)
ausgeblendet (über die visibilitychange-Ereignis)
gefroren (über das Ereignis resume, dann pageshow-Ereignis)

Mögliche nächste Status:
aktiv (über das Ereignis focus)
ausgeblendet (über die visibilitychange-Ereignis)

Ausgeblendet

Eine Seite befindet sich im Status ausgeblendet, wenn sie nicht sichtbar ist eingefroren, verworfen oder beendet wurden).

Mögliche vorherige Status:
passiver (über die visibilitychange-Ereignis)
gefroren (über das Ereignis resume, dann pageshow-Ereignis)

Mögliche nächste Status:
passiver (über die visibilitychange-Ereignis)
gefroren (über das Ereignis freeze)
Verworfen (keine ausgelösten Ereignisse)
beendet (keine ausgelösten Ereignisse)

Eingefroren

Im Status eingefroren hält der Browser die Ausführung von <ph type="x-smartling-placeholder"></ph> einfrierend <ph type="x-smartling-placeholder"></ph> 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 freeze-Callbacks gesendet werden, ist aber möglicherweise in Bezug auf das, was sie wie lange sie aktiv sein können.

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:
ausgeblendet (über das Ereignis freeze)

Mögliche nächste Status:
aktiv (über das Ereignis resume, dann den pageshow-Ereignis)
Passiv (über das Ereignis resume, dann pageshow Termin)
ausgeblendet (über die Veranstaltung resume)
Verworfen (keine ausgelösten Ereignisse)

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:
ausgeblendet (über das Ereignis pagehide)

Mögliche nächste Status:
KEINE

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:
ausgeblendet (keine ausgelösten Ereignisse)
eingefroren (keine ausgelösten Ereignisse)

Mögliche nächste Status:
KEINE

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 den gesamten Lebenszyklus betreffen, und die Statusangaben, in die sie wechseln können.

Name Details
focus

Ein DOM-Element hat den Fokus erhalten.

Hinweis: Ein focus-Ereignis wird nicht auf eine Zustandsänderung hinweisen. Es signalisiert nur dann eine Statusänderung, auf der Seite zuvor keinen Eingabefokus hatte.

Mögliche vorherige Status:
passiver

Mögliche aktuelle Status:
aktiv

blur

Ein DOM-Element hat den Fokus verloren.

Hinweis: Ein blur-Ereignis wird nicht auf eine Zustandsänderung hinweisen. Es signalisiert nur dann eine Statusänderung, Die Seite hat keinen Eingabefokus mehr (d.h. die Seite wurde nicht nur Fokus von einem Element zum anderen).

Mögliche vorherige Status:
aktiv

Mögliche aktuelle Status:
passiver

visibilitychange

Das Dokument <ph type="x-smartling-placeholder"></ph> visibilityState-Wert hat sich geändert. Dies kann wenn Nutzende eine neue Seite aufrufen, Tabs wechseln, einen Tab schließen, minimiert oder schließt den Browser oder wechselt bei Verwendung eines Mobilgeräts zwischen Apps Systeme.

Mögliche vorherige Status:
passiver
ausgeblendet

Mögliche aktuelle Status:
passiver
ausgeblendet

<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:
ausgeblendet

Mögliche aktuelle Status:
eingefroren

<ph type="x-smartling-placeholder"></ph> resume *

Der Browser hat eine eingefrorene Seite fortgesetzt.

Mögliche vorherige Status:
eingefroren

Mögliche aktuelle Status:
aktiv (wenn gefolgt vom pageshow-Ereignis)
passiv (wenn gefolgt vom pageshow-Ereignis)
ausgeblendet

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 persisted ist true, andernfalls ist es false

Mögliche vorherige Status:
eingefroren (ein resume ausgelöst hätten)

Mögliche aktuelle Status:
aktiv
Passiv
ausgeblendet

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 persisted des Ereignisses ist true. Wenn true, tritt die Seite in den frozen, andernfalls wechselt er in den Status terminated.

Mögliche vorherige Status:
ausgeblendet

Mögliche aktuelle Status:
eingefroren (event.persisted ist wahr, freeze folgt)
beendet (event.persisted ist falsch, unload folgt dem Ereignis)

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 beforeunload werden nur verwendet, um den Nutzer auf nicht gespeicherte Änderungen hinzuweisen. Sobald diese werden die Änderungen gespeichert, sollte der Termin entfernt werden. Es sollte niemals unbedingt zur Seite hinzugefügt werden, da dies die Leistung in in manchen Fällen. Siehe Legacy Weitere Informationen finden Sie im Abschnitt „APIs“.

Mögliche vorherige Status:
ausgeblendet

Mögliche aktuelle Status:
gekündigt

unload

Die Seite wird entladen.

Warnung: die Verwendung des Ereignisses unload wird nie empfohlen, unzuverlässig und kann in einigen Fällen die Leistung beeinträchtigen. Weitere Informationen finden Sie in der Abschnitt zu Legacy-APIs .

Mögliche vorherige Status:
ausgeblendet

Mögliche aktuelle Status:
gekündigt

* 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 bei einer Änderung 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. pagehide und pageshow werden am window ausgelöst. visibilitychange, freeze und resume werden auf document ausgelöst und focus und blur werden 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.

Hidden

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. beforeunload, pagehide und unload -Ereignisse werden in diesen Fällen nicht ausgelöst.

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 <ph type="x-smartling-placeholder"></ph> 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 ebenfalls beibehalten werden. in einer unendlichen Listenansicht) <ph type="x-smartling-placeholder"></ph> sessionStorage (oder IndexedDB über commit()), die wiederhergestellt werden sollen, falls die Seite verworfen und später neu geladen.

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. beforeunload, pagehide und unload) gehen wahrscheinlich Daten verloren.

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 document.wasDiscarded.

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- oder pagehide-Event-Listener, über den Sie Daten an Ihren Service Worker senden können postMessage(), 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.

<ph type="x-smartling-placeholder">
</ph> <ph type="x-smartling-placeholder"></ph> Verwirft die Benutzeroberfläche von Chrome
Verworfene Benutzeroberfläche in Chrome

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 können Browser nicht verwendete Seiten einfrieren und verwerfen. Dieses verbrauchen Browser weniger Arbeitsspeicher, CPU, Akku und Netzwerkressourcen. was für die Nutzenden von Vorteil ist.