Os service workers de extensão respondem aos eventos de service worker padrão e aos eventos em 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 na
Chrome Web Store ou quando ele carrega ou atualiza uma extensão descompactada
usando a chrome://extensions página. Três eventos ocorrem nesta ordem:
install(evento do service worker)chrome.runtime.onInstalled(evento de extensão)activate(evento do service worker)
ServiceWorkerRegistration.install
O primeiro evento disparado durante a instalação é o evento de instalação de um service worker da Web.
chrome.runtime.onInstalled
Em seguida, há o evento onInstalled da extensão, que é disparado quando a extensão (não o service worker) é instalada pela primeira vez, quando a extensão é atualizada para uma nova versão e quando o Chrome é atualizado para uma nova versão. Use este
evento para definir um estado ou para 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 de ativação 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 um recarregamento de página em uma extensão.
Inicialização da extensão
Quando um perfil de usuário é iniciado, o chrome.runtime.onStartup evento é disparado, mas nenhum evento de service worker é invocado.
Inatividade e desligamento
Normalmente, o Chrome encerra um service worker quando uma das seguintes condições é atendida:
- Após 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 5 minutos para ser processada.
- Quando uma
fetch()resposta leva mais de 30 segundos para chegar.
Eventos e chamadas para APIs de extensão redefinem esses timers e, se o service worker estiver inativo, um evento recebido vai reativá-los. No entanto, você precisa projetar seu service worker para ser resiliente contra encerramentos inesperados.
Para otimizar o consumo de recursos da extensão, evite manter o service worker ativo indefinidamente, se possível. Teste suas extensões para garantir que você não esteja 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 estão listadas.
- API chrome.storage
- Uma API de extensão que oferece vários tipos de armazenamento: local, de sessão, gerenciado (domínio) e de sincronização. 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 no 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 muitas vezes 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 é fundamental que os usuários vejam dados atualizados. Para mais informações, consulte O livro de receitas off-line. A menos que você esteja fazendo proxy de solicitações de rede usando o handler de busca, use
chrome.storage.
Escolher uma versão mínima do Chrome
Desde o lançamento do Manifest V3, fizemos várias melhorias nos tempos de vida do service worker. Isso significa que, se a extensão do Manifest V3 for compatível com versões anteriores do Chrome, haverá condições que você precisará conhecer. Se essas condições não afetarem sua extensão, você poderá pular esta seção. Se elas afetarem, considere especificar uma versão mínima do Chrome no seu manifesto.
Chrome 120
Os alarmes agora 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 usando a chrome.debugger API agora mantêm o service worker ativo. Isso impede que os service workers atinjam o tempo limite durante as chamadas para essa API.
Chrome 116
O Chrome 116 introduziu as seguintes melhorias no tempo de vida do service worker:
As conexões
WebSocketativas agora estendem os tempos de vida do service worker de extensão. O envio ou recebimento de mensagens em umWebSocketem 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 service workers de extensão. Essas APIs mostram uma solicitação do usuário e, portanto, podem levar mais de cinco minutos para serem resolvidas. Elas incluem
desktopCapture.chooseDesktopMedia(),identity.launchWebAuthFlow(),management.uninstall()epermissions.request().
Chrome 114
O envio de uma mensagem com mensagens de longa duração mantém o service worker ativo. A abertura de uma porta não redefine mais os timers.
Chrome 110
As chamadas de API de extensão redefinem os timers. Antes disso, apenas os handlers de eventos em execução mantinham um service worker ativo. Os eventos enfileirados, mas para os quais um handler 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 do host falhar ou for desligado, 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.