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 unten stehenden 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 zum Festlegen eines Status oder zur einmaligen Initialisierung, 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 Service 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. Trotzdem sollten Sie Ihren Service Worker so konzipieren, dass er vor einer unerwarteten Beendigung geschützt ist.

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 das clientseitige Speichern strukturierter 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 keine Netzwerkanfragen ausdrücklich über den Abruf-Handler weiterleiten, 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 keine Auswirkungen auf Ihre Erweiterung haben, können Sie mit diesem Abschnitt fortfahren. Ist dies der Fall, sollten Sie in Ihrem Manifest eine Mindestversion von Chrome angeben.

Chrome 120

Alarme können jetzt auf einen Mindestzeitraum von 30 Sekunden festgelegt werden, um dem Lebenszyklus des Service Workers zu entsprechen. Weitere Informationen finden Sie unter chrome.alarms.

Chrome 118

Aktive Debugger-Sitzungen, die mit der chrome.debugger API erstellt wurden, halten den Service 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 Sie Nachrichten über eine WebSocket in einem Erweiterungs-Service-Worker senden oder empfangen, wird der Inaktivitäts-Timer des Service 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 hingegen nicht. Durch das Öffnen eines Anschlusses werden die Timer nicht mehr zurückgesetzt.

Chrome 110

Durch Erweiterungs-API-Aufrufe werden die Timer zurückgesetzt. Davor hielten nur die Ausführung von Event-Handlern einen Service Worker aktiv. Ereignisse, die in die Warteschlange gestellt wurden, für die jedoch kein Handler aufgerufen wurde, würden nicht zurückgesetzt werden.

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.