Cette page a été traduite par l'API Cloud Translation.

Cycle de vie des service workers des extensions

Les nœuds de calcul de service d'extension répondent à la fois aux événements de nœud de calcul de service standard et aux événements des espaces de noms d'extension. Ils sont présentés ensemble, car un type suit souvent l'autre au cours de l'utilisation d'une extension.

Installation

L'installation se produit lorsque l'utilisateur installe ou met à jour un service worker depuis le Chrome Web Store, ou lorsqu'il charge ou met à jour une extension décompressée à l'aide de la page chrome://extensions. Trois événements se produisent dans l'ordre ci-dessous.

ServiceWorkerRegistration.install

Le premier événement déclenché lors de l'installation est l'événement install (installation) d'un worker de service Web.

chrome.runtime.onInstalled

Vient ensuite l'événement onInstalled de l'extension, qui est déclenché lorsque l'extension (et non le service worker) est installée pour la première fois, lorsqu'elle est mise à jour vers une nouvelle version et lorsque Chrome est mis à jour vers une nouvelle version. Utilisez cet événement pour définir un état ou pour une initialisation ponctuelle, comme un menu contextuel.

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

Enfin, l'événement activate du service worker est déclenché. Notez que, contrairement aux workers de service Web, cet événement se déclenche immédiatement après l'installation d'une extension, car il n'y a rien de comparable à un rechargement de page dans une extension.

Démarrage de l'extension

Lorsqu'un profil utilisateur démarre, l'événement chrome.runtime.onStartup se déclenche, mais aucun événement de service worker n'est appelé.

Inactivité et arrêt

Normalement, Chrome arrête un service worker lorsqu'une des conditions suivantes est remplie:

Après 30 secondes d'inactivité La réception d'un événement ou l'appel d'une API d'extension réinitialise ce minuteur.
Lorsqu'une seule requête, telle qu'un événement ou un appel d'API, prend plus de cinq minutes à traiter.
Lorsqu'une réponse fetch() prend plus de 30 secondes à arriver.

Les événements et les appels aux API d'extension réinitialisent ces minuteurs. Si le service worker est devenu inactif, un événement entrant le réactive. Toutefois, vous devez concevoir votre service worker pour qu'il soit résilient en cas d'arrêt inattendu.

Pour optimiser la consommation de ressources de votre extension, évitez de maintenir votre service worker actif indéfiniment, si possible. Testez vos extensions pour vous assurer que vous ne le faites pas par inadvertance.

Persistance des données plutôt que d'utiliser des variables globales

Toutes les variables globales que vous définissez seront perdues si le service worker s'arrête. Au lieu d'utiliser des variables globales, enregistrez les valeurs dans l'espace de stockage. Les options qui s'offrent à vous sont indiquées ci-dessous. Notez que l'API Web Storage n'est pas disponible pour les service workers d'extensions.

API chrome.storage: API d'extension proposant plusieurs types de stockage : local, par session, géré (domaine) et synchronisé. Cette API stocke des objets JSON identifiés et récupérés à l'aide de clés définies par le développeur. Ce type de stockage n'est pas supprimé lorsqu'un utilisateur vide le cache Web.
API IndexedDB: API de bas niveau permettant de stocker des données structurées côté client, y compris des fichiers et des blobs. Cette API fournit des primitives pour créer le stockage et la récupération de données transactionnelles. Bien que cette API soit souvent trop complexe pour les cas d'utilisation simples, un certain nombre de solutions de stockage tiers sont basées dessus.
API CacheStorage: Mécanisme de stockage persistant pour les paires d'objets Request et Response. Cette API a été conçue spécifiquement pour les workers de service Web et permet de récupérer des données à partir d'un point de terminaison. Il existe plusieurs façons d'utiliser cette API, selon que les utilisateurs doivent voir des données à jour et dans quelle mesure. Pour en savoir plus, consultez le Cookbook hors connexion. Sauf si vous proxyez spécifiquement les requêtes réseau via le gestionnaire de récupération, vous devez utiliser chrome.storage.

Choisir une version minimale de Chrome

Depuis la publication de Manifest V3, nous avons apporté plusieurs améliorations à la durée de vie des service workers. Cela signifie que si votre extension Manifest V3 est compatible avec des versions antérieures de Chrome, vous devez tenir compte de certaines conditions. Si ces conditions ne s'appliquent pas à votre extension, vous pouvez passer à la section suivante. Si c'est le cas, envisagez de spécifier une version minimale de Chrome dans votre fichier manifeste.

Chrome 120

Vous pouvez désormais définir une période minimale de 30 secondes pour les alarmes afin qu'elles correspondent au cycle de vie du service worker. Pour en savoir plus, consultez chrome.alarms.

Chrome 118

Les sessions de débogage actives créées à l'aide de l'API chrome.debugger maintiennent désormais le service worker actif. Cela empêche les travailleurs de service de dépasser le délai d'expiration lors des appels de cette API.

Chrome 116

Chrome 116 a introduit les améliorations de durée de vie des service workers suivantes:

Les connexions actives WebSocket prolongent désormais la durée de vie des service workers d'extension. L'envoi ou la réception de messages via un WebSocket dans un service worker d'extension réinitialise le minuteur d'inactivité du service worker.
Les API d'extension supplémentaires sont autorisées à dépasser le délai avant expiration de cinq minutes pour les service workers d'extension. Ces API affichent une invite à l'utilisateur. Leur résolution peut donc prendre plus de cinq minutes. Parmi lesquels desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow(), management.uninstall() et permissions.request().

Chrome 114

L'envoi d'un message à l'aide de la messagerie durable maintient le service worker actif. Auparavant, l'ouverture d'un port réinitialisait les minuteurs, mais l'envoi d'un message ne le faisait pas. L'ouverture d'un port ne réinitialise plus les minuteurs.

Chrome 110

Les appels d'API d'extension réinitialisent les minuteurs. Auparavant, seuls les gestionnaires d'événements en cours d'exécution permettaient de maintenir un service worker en vie. Les événements mis en file d'attente, mais pour lesquels aucun gestionnaire n'a été appelé, ne provoquent pas de réinitialisation.

Chrome 109

Les messages envoyés depuis un document hors écran réinitialisent les minuteurs.

Chrome 105

Se connecter à un hôte de messagerie native à l'aide de chrome.runtime.connectNative() permet de maintenir un service worker actif. Si le processus hôte plante ou est arrêté, le port est fermé et le service worker s'arrête une fois les délais terminés. Pour éviter cela, appelez chrome.runtime.connectNative() dans le gestionnaire d'événements onDisconnect du port.