O ciclo de vida do service worker de extensão

Os service workers de extensão respondem aos eventos padrão do service worker e aos eventos nos namespaces de extensão. Eles são apresentados juntos porque, muitas vezes, um tipo segue o outro durante o uso de uma extensão.

Instalação

A instalação ocorre quando o usuário instala ou atualiza um service worker da Chrome Web Store ou quando carrega ou atualiza uma extensão descompactada usando a página chrome://extensions. Três eventos ocorrem nesta ordem:

1. install
2. onInstall
3. activate

ServiceWorkerRegistration.install

O primeiro evento disparado durante a instalação é o evento install de um service worker da Web.

chrome.runtime.onInstalled

Em seguida, temos o evento onInstalled da extensão, que é acionado quando a extensão (não o service worker) é instalada pela primeira vez, quando ela é atualizada para uma nova versão e quando o Chrome é atualizado para uma nova versão. Use esse evento para definir um estado ou para uma inicialização única, como um menu de contexto.

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

Por fim, o evento activate do service worker é disparado. Ao contrário dos service workers da Web, esse evento é disparado imediatamente após a instalação de uma extensão porque não há nada comparável a uma atualização de página em uma extensão.

Inicialização da extensão

Quando um perfil de usuário é iniciado, o evento chrome.runtime.onStartup é acionado, mas nenhum evento do service worker é invocado.

Inatividade e desligamento

Normalmente, o Chrome encerra um service worker quando uma das seguintes condições é atendida:

• Depois de 30 segundos de inatividade. Receber um evento ou chamar uma API de extensão redefine esse timer.
• Quando uma única solicitação, como um evento ou uma chamada de API, leva mais de cinco minutos para ser processada.
• Quando uma resposta fetch() leva mais de 30 segundos para chegar.

Eventos e chamadas para APIs de extensão redefinem esses timers. Se o service worker estiver inativo, um evento recebido vai reativá-los. No entanto, você precisa projetar o service worker para que ele seja resiliente contra encerramentos inesperados.

Para otimizar o consumo de recursos da sua extensão, evite manter o service worker ativo indefinidamente, se possível. Teste suas extensões para garantir que você não está fazendo isso sem querer.

Manter dados em vez de usar variáveis globais

Todas as variáveis globais definidas serão perdidas se o service worker for desligado. Em vez de usar variáveis globais, salve os valores no armazenamento. Suas opções são listadas.

API chrome.storage

Uma API de extensão que oferece vários tipos de armazenamento: local, por sessão, gerenciado (domínio) e sincronizado. Essa API armazena objetos JSON identificados e recuperados com chaves definidas pelo desenvolvedor. Esse tipo de armazenamento não é removido quando um usuário limpa o cache da Web.

API IndexedDB

Uma API de baixo nível para armazenamento do lado do cliente de dados estruturados, incluindo arquivos e blobs. Essa API fornece primitivos para criar armazenamento e recuperação de dados transacionais. Embora essa API seja muito complicada para alguns casos de uso, várias soluções de armazenamento de terceiros são criadas com base nela.

API CacheStorage

Um mecanismo de armazenamento persistente para pares de objetos de solicitação e resposta. Essa API foi projetada especificamente para service workers da Web e é usada para recuperar dados de um endpoint. Há várias maneiras de usar essa API, dependendo de se e como é importante que os usuários vejam dados atualizados. Para mais informações, consulte The Offline Cookbook (em inglês). A menos que você esteja especificamente fazendo proxy de solicitações de rede usando o manipulador de busca, use chrome.storage.

Escolher uma versão mínima do Chrome

Desde o lançamento do Manifest V3, fizemos várias melhorias na vida útil dos service workers. Isso significa que, se a extensão do Manifest V3 for compatível com versões anteriores do Chrome, você precisará estar ciente de algumas condições. Se essas condições não afetarem sua extensão, você pode pular esta seção. Se for o caso, especifique uma versão mínima do Chrome no manifesto.

Chrome 120

Agora, os alarmes podem ser definidos para um período mínimo de 30 segundos para corresponder ao ciclo de vida do service worker. Consulte chrome.alarms para mais detalhes.

Chrome 118

As sessões de depurador ativas criadas com a API chrome.debugger agora mantêm o service worker ativo. Isso evita que os service workers atinjam o tempo limite durante as chamadas para essa API.

Chrome 116

O Chrome 116 introduziu as seguintes melhorias no ciclo de vida do service worker:

• As conexões WebSocket ativas agora estendem os tempos de vida do service worker de extensão. O envio ou recebimento de mensagens em um WebSocket em um service worker de extensão redefine o timer de inatividade do service worker.

• Outras APIs de extensão podem ultrapassar o período de tempo limite de cinco minutos para workers de serviço de extensão. Essas APIs mostram uma solicitação ao usuário e, portanto, podem levar mais de cinco minutos para serem resolvidas. Isso inclui desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow(), management.uninstall() e permissions.request().

Chrome 114

Enviar uma mensagem com mensagens de longa duração mantém o service worker ativo. Abrir uma porta não redefine mais os timers.

Chrome 110

As chamadas da API Extension redefinem os timers. Antes, apenas os manipuladores de eventos em execução mantinham um service worker ativo. Os eventos que foram enfileirados, mas para os quais um manipulador não foi chamado, não causariam uma redefinição.

Chrome 109

As mensagens enviadas de um documento fora da tela redefinem os timers.

Chrome 105

A conexão com um host de mensagens nativas usando chrome.runtime.connectNative() mantém um service worker ativo. Se o processo host falhar ou for encerrado, a porta será fechada e o service worker será encerrado após a conclusão dos timers. Para evitar isso, chame chrome.runtime.connectNative() no manipulador de eventos onDisconnect da porta.