Cycle de vie des service workers des extensions

Les service workers d'extensions répondent à la fois aux événements de service worker standards et aux événements dans les espaces de noms d'extensions. Ils sont présentés ensemble, car un type suit souvent l'autre lors de l'utilisation d'une extension.

Installation

L'installation se produit lorsque l'utilisateur installe ou met à jour un service worker à partir du Chrome Web Store, ou lorsqu'il charge ou met à jour une extension non empaquetée à l'aide de la chrome://extensions page. Trois événements se produisent, dans cet ordre :

  1. install (événement de service worker)
  2. chrome.runtime.onInstalled (événement d'extension)
  3. activate (événement de service worker)

ServiceWorkerRegistration.install

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

chrome.runtime.onInstalled

Vient ensuite l'événement onInstalled de l'extension, qui est déclenché lors de la première installation de l'extension (et non du service worker), lorsque l'extension 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 unique, 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 d'activation du service worker est déclenché. Notez que, contrairement aux service workers Web, cet événement est déclenché immédiatement après l'installation d'une extension, car il n'existe 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 est déclenché, mais aucun événement de service worker n'est appelé.

Inactivité et arrêt

Normalement, Chrome arrête un service worker lorsque l'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 fetch() réponse met plus de 30 secondes à arriver.

Les événements et les appels aux API d'extension réinitialisent ces minuteurs. Si le service worker est en veille, un événement entrant le réactivera. Néanmoins, vous devez concevoir votre service worker pour qu'il résiste aux arrêts inattendus.

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

Persister les 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 le stockage. Les options disponibles sont listées.

API chrome.storage
Une API d'extension qui propose plusieurs types de stockage : local, session, géré (domaine) et synchronisation. 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 efface le cache Web.
API IndexedDB
Une API de bas niveau pour le stockage côté client de données structurées, y compris des fichiers et des blobs. Cette API fournit des primitives pour la création et la récupération de stockage de données transactionnelles. Bien que cette API soit souvent trop complexe pour certains cas d'utilisation, un certain nombre de solutions de stockage tierces sont basées sur elle.
API CacheStorage
Un mécanisme de stockage persistant pour les paires d'objets Request et Response. Cette API a été conçue spécifiquement pour les service workers Web et permet de récupérer des données à partir d'un point de terminaison. Il existe différentes façons d'utiliser cette API, selon que les utilisateurs doivent ou non voir des données à jour. Pour en savoir plus, consultez The Offline Cookbook. Sauf si vous utilisez spécifiquement des requêtes réseau proxy à l'aide du gestionnaire de récupération, vous devez utiliser chrome.storage.

Choisir une version minimale de Chrome

Depuis la sortie 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 connaître certaines conditions. Si ces conditions n'affectent pas votre extension, vous pouvez passer à la section suivante. Dans le cas contraire, envisagez de spécifier une version minimale de Chrome dans votre fichier manifeste.

Chrome 120

Les alarmes peuvent désormais être définies sur une période minimale de 30 secondes pour correspondre 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 service workers d'expirer lors des appels à cette API.

Chrome 116

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

  • Les connexions WebSocket actives prolongent désormais la durée de vie des service workers d'extensions. 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.

  • D'autres API d'extension sont autorisées à dépasser le délai d'expiration de cinq minutes pour les service workers d'extensions. Ces API affichent une invite utilisateur et peuvent donc raisonnablement prendre plus de cinq minutes à résoudre. Il s'agit de desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow(), management.uninstall() et permissions.request().

Chrome 114

L'envoi d'un message avec une messagerie de longue durée maintient le service worker actif. 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 maintenaient un service worker actif. Les événements mis en file d'attente, mais pour lesquels un gestionnaire n'avait pas été appelé, n'entraînaient pas de réinitialisation.

Chrome 109

Les messages envoyés à partir d'un document hors écran réinitialisent les minuteurs.

Chrome 105

La connexion à un hôte de messagerie natif à l'aide de chrome.runtime.connectNative() maintient 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 minuteurs terminés. Pour éviter cela, appelez chrome.runtime.connectNative() dans le gestionnaire d'événements onDisconnect du port.