Lebenszyklus des Erweiterungs-Service-Workers

Dienstworker für Erweiterungen reagieren sowohl auf die Standardereignisse von Dienstworkern als auch auf Ereignisse in Erweiterungs-Namespaces. Sie werden zusammen aufgeführt, da bei der Verwendung einer Erweiterung häufig ein Typ dem anderen folgt.

Installation

Die Installation erfolgt, wenn der Nutzer einen Dienst-Worker aus dem Chrome Web Store installiert oder aktualisiert oder wenn er eine entpackte Erweiterung über die Seite chrome://extensions lädt oder aktualisiert. Drei Ereignisse treten in der folgenden Reihenfolge auf.

ServiceWorkerRegistration.install

Das erste Ereignis, das während der Installation ausgelöst wird, ist das install-Ereignis eines Webservice-Workers.

chrome.runtime.onInstalled

Als Nächstes folgt das Ereignis onInstalled der Erweiterung. Es wird ausgelöst, wenn die Erweiterung (nicht der Dienst-Worker) zum ersten Mal installiert, auf eine neue Version aktualisiert oder Chrome auf eine neue Version aktualisiert wird. Verwenden Sie dieses Ereignis, um einen Status festzulegen oder eine einmalige Initialisierung durchzuführen, z. B. für ein Kontextmenü.

chrome.runtime.onInstalled.addListener((details) => {
  if(details.reason !== "install" && details.reason !== "update") return;
  chrome.contextMenus.create({
    "id": "sampleContextMenu",
    "title": "Sample Context Menu",
    "contexts": ["selection"]
  });
});

ServiceWorkerRegistration.active

Schließlich wird das Ereignis activate des Service Workers ausgelöst. Im Gegensatz zu Web-Dienst-Workern wird dieses Ereignis sofort nach der Installation einer Erweiterung ausgelöst, da es in einer Erweiterung nichts Vergleichbares zu einem Seitenaktualisieren gibt.

Start der Erweiterung

Wenn ein Nutzerprofil gestartet wird, wird das Ereignis chrome.runtime.onStartup ausgelöst, aber es werden keine Service Worker-Ereignisse aufgerufen.

Inaktivität und Herunterfahren

Normalerweise beendet Chrome einen Dienst-Worker, wenn eine der folgenden Bedingungen erfüllt ist:

• Nach 30 Sekunden Inaktivität Wenn ein Ereignis empfangen oder eine Erweiterungs-API aufgerufen wird, wird dieser Timer zurückgesetzt.
• Wenn die Verarbeitung einer einzelnen Anfrage, z. B. eines Ereignisses oder API-Aufrufs, länger als 5 Minuten dauert.
• Wenn die Antwort auf eine fetch()-Anfrage länger als 30 Sekunden dauert.

Ereignisse und Aufrufe von Erweiterungs-APIs setzen diese Timer zurück. Wenn der Dienst-Worker inaktiv geworden ist, wird er durch ein eingehendes Ereignis wieder aktiviert. Dennoch sollten Sie Ihren Dienst-Worker so konzipieren, dass er unerwartete Beendigungen abfangen kann.

Um den Ressourcenverbrauch Ihrer Erweiterung zu optimieren, sollten Sie Ihren Service Worker nach Möglichkeit nicht unbegrenzt aktiv halten. Testen Sie Ihre Erweiterungen, um sicherzustellen, dass dies nicht versehentlich geschieht.

Daten beibehalten, anstatt globale Variablen zu verwenden

Alle von Ihnen festgelegten globalen Variablen gehen verloren, wenn der Dienstarbeiter heruntergefahren wird. Speichern Sie Werte stattdessen im Speicher, anstatt globale Variablen zu verwenden. Ihre Optionen sind unten aufgeführt. Die Web Storage API ist für Erweiterungs-Service-Worker nicht verfügbar.

chrome.storage API

Eine Erweiterungs-API, die mehrere Speichertypen bietet: lokal, Sitzung, verwaltet (Domain) und Synchronisierung. Diese API speichert JSON-Objekte, die mithilfe von vom Entwickler definierten Schlüsseln identifiziert und abgerufen werden. Diese Art von Speicher wird nicht entfernt, wenn ein Nutzer den Webcache löscht.

IndexedDB API

Eine Low-Level-API für den clientseitigen Speicher von strukturierten Daten, einschließlich Dateien und Blobs. Diese API bietet Primitive zum Erstellen von Transaktionsdatenspeichern und -abrufen. Diese API ist für einfache Anwendungsfälle oft zu kompliziert, aber es gibt eine Reihe von Speicherlösungen von Drittanbietern, die darauf aufbauen.

CacheStorage API

Ein persistenter Speichermechanismus für Anfrage- und Antwortobjektpaare. Diese API wurde speziell für Webservice-Worker entwickelt und dient zum Abrufen von Daten von einem Endpunkt. Es gibt verschiedene Möglichkeiten, diese API zu verwenden, je nachdem, wie wichtig es ist, dass Nutzer aktuelle Daten sehen. Weitere Informationen finden Sie im Offline-Kochbuch. Sofern Sie Netzwerkanfragen nicht speziell über den Abruf-Handler proxyn, sollten Sie chrome.storage verwenden.

Mindestversion von Chrome auswählen

Seit der Veröffentlichung von Manifest V3 haben wir die Lebensdauer von Dienstarbeitern erheblich verbessert. Wenn Ihre Manifest V3-Erweiterung ältere Chrome-Versionen unterstützt, müssen Sie einige Bedingungen beachten. Wenn diese Bedingungen nicht auf Ihre Erweiterung zutreffen, können Sie mit dem nächsten Abschnitt fortfahren. In diesem Fall sollten Sie in Ihrem Manifest eine Mindestversion von Chrome angeben.

Chrome 120

Wecker können jetzt auf eine Mindestdauer von 30 Sekunden festgelegt werden, um dem Dienst-Worker-Lebenszyklus zu entsprechen. Weitere Informationen finden Sie unter chrome.alarms.

Chrome 118

Aktive Debugger-Sitzungen, die mit der chrome.debugger API erstellt wurden, halten den Dienst-Worker jetzt aktiv. So wird verhindert, dass bei Aufrufen dieser API ein Zeitüberschreitungsfehler auftritt.

Chrome 116

In Chrome 116 wurden die folgenden Verbesserungen für die Lebensdauer von Service Workern eingeführt:

• Aktive WebSocket-Verbindungen verlängern jetzt die Lebensdauer von Dienst-Workern für Erweiterungen. Wenn in einem Erweiterungs-Dienst-Worker Nachrichten über eine WebSocket gesendet oder empfangen werden, wird der Inaktivitätstimer des Dienst-Workers zurückgesetzt.

• Für zusätzliche Erweiterungs-APIs darf die Zeitüberschreitung von fünf Minuten für Erweiterungs-Service-Worker überschritten werden. Bei diesen APIs wird eine Aufforderung für den Nutzer angezeigt. Daher kann die Behebung der Probleme mehr als fünf Minuten dauern. Dazu gehören desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow(), management.uninstall() und permissions.request().

Chrome 114

Wenn Sie eine Nachricht mit Long-Lived Messaging senden, bleibt der Service Worker aktiv. Bisher wurden die Timer beim Öffnen eines Ports zurückgesetzt, beim Senden einer Nachricht jedoch nicht. Durch das Öffnen eines Anschlusses werden die Timer nicht mehr zurückgesetzt.

Chrome 110

Durch Erweiterungs-API-Aufrufe werden die Timer zurückgesetzt. Bisher wurde ein Dienstarbeiter nur durch laufende Ereignishandler am Leben gehalten. Ereignisse, die in die Warteschlange gestellt, aber für die noch kein Handler aufgerufen wurde, führen nicht zu einem Zurücksetzen.

Chrome 109

Wenn Nachrichten von einem nicht sichtbaren Dokument gesendet werden, werden die Timer zurückgesetzt.

Chrome 105

Wenn Sie über chrome.runtime.connectNative() eine Verbindung zu einem nativen Messaging-Host herstellen, bleibt ein Service Worker aktiv. Wenn der Hostprozess abstürzt oder heruntergefahren wird, wird der Port geschlossen und der Dienstarbeiter wird nach Ablauf der Timer beendet. Sie können dies verhindern, indem Sie chrome.runtime.connectNative() im onDisconnect-Ereignis-Handler des Ports aufrufen.