Diese Seite wurde von der Cloud Translation API übersetzt.

Lebenszyklus des Erweiterungs-Service-Workers

Service Worker der Erweiterung reagieren sowohl auf die standardmäßigen Service Worker-Ereignisse als auch auf Ereignisse in Erweiterungs-Namespaces. Sie werden zusammen angezeigt, weil bei der Verwendung einer Erweiterung häufig ein Typ auf einen anderen folgt.

Installation

Die Installation erfolgt, wenn der Nutzer einen Service Worker aus dem Chrome Web Store installiert oder aktualisiert oder eine entpackte Erweiterung über die Seite chrome://extensions lädt oder aktualisiert. Es treten drei Ereignisse in der unten angegebenen Reihenfolge auf.

ServiceWorkerRegistration.install

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

chrome.runtime.onInstalled

Als Nächstes kommt das onInstalled-Ereignis der Erweiterung, das ausgelöst wird, wenn die Erweiterung (nicht der Service Worker) zum ersten Mal installiert, die Erweiterung auf eine neue Version oder Chrome auf eine neue Version aktualisiert wird. Verwenden Sie dieses Ereignis, um einen Status festzulegen oder eine einmalige Initialisierung durchzuführen, beispielsweise 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. Beachten Sie, dass dieses Ereignis im Gegensatz zu Web Service Workern sofort nach der Installation einer Erweiterung ausgelöst wird, da nichts mit einem Neuladen einer Seite in einer Erweiterung vergleichbar ist.

Start der Erweiterung

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

Inaktiv 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 eines API-Aufrufs, länger als 5 Minuten dauert.
Wenn eine fetch()-Antwort länger als 30 Sekunden dauert.

Durch Ereignisse und Aufrufe an Erweiterungs-APIs werden diese Timer zurückgesetzt. Wenn der Service Worker nicht mehr aktiv ist, werden sie durch ein eingehendes Ereignis reaktiviert. Dennoch sollten Sie Ihren Service Worker so konzipieren, dass er gegen eine unerwartete Beendigung geschützt ist.

Um den Ressourcenverbrauch der Erweiterung zu optimieren, sollten Sie den Service Worker nach Möglichkeit nicht auf unbestimmte Zeit aktiv lassen. Testen Sie Ihre Erweiterungen, um sicherzustellen, dass dies nicht ungewollt passiert.

Daten beibehalten, anstatt globale Variablen zu verwenden

Alle festgelegten globalen Variablen gehen verloren, wenn der Service Worker heruntergefahren wird. Anstatt globale Variablen zu verwenden, speichern Sie Werte. Die verfügbaren Optionen sind unten aufgeführt. Die Web Storage API ist für Extension Service Worker nicht verfügbar.

chrome.storage API: Eine Erweiterungs-API, die mehrere Speichertypen bietet: lokal, sitzungsspezifisch, verwaltet (Domain) und Synchronisierung. Diese API speichert JSON-Objekte, die mit vom Entwickler definierten Schlüsseln identifiziert und abgerufen wurden. Diese Art von Speicher wird nicht entfernt, wenn ein Nutzer den Web-Cache leert.
IndexedDB API: Eine Low-Level-API zum clientseitigen Speichern strukturierter Daten, einschließlich Dateien und Blobs. Diese API bietet Primitive zum Erstellen und Abrufen von Transaktionsdaten. Diese API ist für einfache Anwendungsfälle oft zu kompliziert, doch eine Reihe von Speicherlösungen von Drittanbietern baut darauf auf.
CacheStorage API: Ein dauerhafter Speichermechanismus für Anfrage- und Antwortobjektpaare. Diese API wurde speziell für Webdienst-Worker entwickelt und wird verwendet, um Daten von einem Endpunkt abzurufen. Es gibt verschiedene Möglichkeiten, diese API zu verwenden, je nachdem, ob und wie wichtig es ist, dass Nutzer aktuelle Daten sehen. Weitere Informationen findest du im Offline Cookbook. Sofern Sie Netzwerkanfragen nicht 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 Service Workern mehrfach verbessert. Wenn Ihre Manifest V3-Erweiterung also ältere Versionen von Chrome unterstützt, müssen Sie bestimmte Bedingungen kennen. Wenn diese Bedingungen keine Auswirkungen auf Ihre Erweiterung haben, können Sie mit diesem Abschnitt fortfahren. Falls ja, sollten Sie in Ihrem Manifest eine Mindestversion von Chrome angeben.

Chrome 120

Alarme können jetzt auf einen Mindestzeitraum von 30 Sekunden eingestellt werden, um dem Service Worker-Lebenszyklus zu entsprechen. Unter chrome.alarms findest du weitere Informationen.

Chrome 118

Aktive Debugger-Sitzungen, die mit der chrome.debugger API erstellt wurden, halten den Service Worker jetzt aktiv. Dadurch wird verhindert, dass Service Worker bei Aufrufen dieser API eine Zeitüberschreitung verursachen.

Chrome 116

In Chrome 116 wurden die folgenden Verbesserungen der Service Worker-Lebensdauer eingeführt:

Aktive WebSocket-Verbindungen verlängern jetzt die Lebensdauer von Erweiterungs-Service-Workern. Durch das Senden oder Empfangen von Nachrichten über eine WebSocket in einem Service Worker der Erweiterung wird der Timer für die Inaktivität des Service Workers zurückgesetzt.
Zusätzliche Erweiterungs-APIs dürfen das Zeitlimit von fünf Minuten für Worker von Erweiterungsdiensten überschreiten. Diese APIs zeigen eine Nutzeraufforderung an und die Behebung kann daher vernünftigerweise länger als fünf Minuten dauern. Dazu gehören desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow(), management.uninstall() und permissions.request().

Chrome 114

Durch das Senden einer Nachricht mit langlebigem Messaging bleibt der Service Worker am Leben. Bisher wurden durch das Öffnen eines Ports die Timer zurückgesetzt, das Senden einer Nachricht hingegen nicht. Durch das Öffnen eines Ports werden die Timer nicht mehr zurückgesetzt.

Chrome 110

Extension API-Aufrufe setzen die Timer zurück. Bisher konnte ein Service Worker nur durch das Ausführen von Event-Handlern am Leben gehalten werden. Ereignisse in der Warteschlange, für die kein Handler aufgerufen wurde, führen nicht zu einer Zurücksetzung.

Chrome 109

Nachrichten, die von einem nicht sichtbaren Dokument gesendet werden, setzen die Timer zurück.

Chrome 105

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