Page Lifecycle API

Philip Walton

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> <ph type="x-smartling-placeholder"></ph>

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.

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.

* 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.

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> <ph type="x-smartling-placeholder"></ph>

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.