Você está recebendo a mensagem no Edge ou console do Chrome?
“a rescisão do service worker por um temporizador de tempo limite foi cancelada porque DevTools está anexado”
Você está preocupado por ter adicionado algo ruim ao seu trabalhador de serviço ?
Não há necessidade de se preocupar, esta é uma mensagem de’informação’do Chrome e do registro do Edge. Não se preocupe, isso não indica que há algo errado com seu código ou lógica.
Esta mensagem tem mais a ver com o funcionamento das Ferramentas de Desenvolvimento do navegador do que com qualquer outra coisa.
No entanto, isso levanta a questão: quanto tempo vive um prestador de serviço ou quanto tempo dura o ciclo de vida do prestador de serviço?
Como a vida útil de um prestador de serviços é determinada
Não deve ser confundido com o Ciclo de Vida do Service Worker, o tempo que um navegador mantém o service worker de um site ativo depois de acionado varia de acordo com o navegador e é o que estamos discutindo aqui.
Quando um usuário abre uma página associada a um service worker registrado e o service worker não está ativo, o navegador instancia o service worker. Ele roda em seu próprio segmento, tecnicamente externo à página. Para conservar recursos, apenas uma instância do service worker é criada e todas as páginas associadas usam a única instância.
Mesmo que uma página seja aberta em uma guia, ela pode estar ociosa, o que significa que não há necessidade de um service worker estar ativo. Se estivesse ativo, o excesso de CPU, memória e outros recursos são ocupados quando não são necessários. Isso significa que a bateria do usuário se esgota mais rápido do que o necessário e ninguém quer isso.
Cada navegador o usa em cálculos para determinar quando eliminar um service worker ativo, mas não utilizado. Não há tempo mágico em segundos quando um service worker morre. Pelo que sei, pode demorar um minuto ou 30 minutos.
Evidentemente Chrome tenta para encerrar service workers inativos em 30 segundos .
A especificação afirma o seguinte:
Um agente de usuário pode rescindir service workers a qualquer momento:
- Não tem evento para controlar
- Detecta operação anormal: como loops infinitos e tarefas que excedem os limites de tempo impostos (se houver) ao lidar com os eventos
Meu palpite é que cada navegador faz algum tipo de cálculo interno com base nos recursos disponíveis, se o dispositivo está usando a bateria ou conectado, etc. Algo semelhante a como determina quanto espaço de armazenamento está disponível para um domínio .
Sabemos que os navegadores podem e devem matar agressivamente service workers não utilizados para otimizar o desempenho do dispositivo.
Não se preocupe em quebrar seu aplicativo. Se o service worker estiver morto e o usuário acioná-lo novamente, o navegador apenas ativa uma nova instância. Este processo é muito rápido e não deve ser perceptível para o seu cliente.
Por que o Chrome exibe a mensagem de aviso
O Chrome e o Edge detectam quando DevTools estão abertos e não mata o burro do service worker de forma agressiva. O navegador assume que um desenvolvedor está usando DevTools e pode estar depurando o código do funcionário do serviço. Matar o operário causaria todo tipo de puxão de cabelo e, acredite, fazemos isso do jeito que está.
As últimas versões do Chrome adicionaram a mensagem”encerramento do service worker por um temporizador de tempo limite porque o DevTools está anexado”ao fluxo de trabalho. Isso é feito como uma cortesia para ajudar os desenvolvedores a perceber que o que eles estão depurando pode não ser exatamente o que o usuário experimentaria.
Para desenvolvedores, o problema número um é confiar na persistência do estado global. Não sou um defensor de se apoiar pesado ou mesmo médio no estado global como referência de valor. Eu ensino, sempre presumo que o service worker está sendo instanciado recentemente.
Isso não é exclusivo dos prestadores de serviço. Tenho visto o uso abusivo do estado global quase toda a minha carreira. Pessoalmente, vejo que o padrão MVVM (pense Angular) é o padrão mais abusivo e leva a grandes extensões de memória e baixo desempenho. Além disso, você deve escrever mais código (na minha experiência) do que faria se dependesse de hidratar o que precisa para a página.
O modelo de programação é semelhante a como você deve usar ao desenvolver AWS Lambdas ou Azure Functions. Escreva um código que seja executado estaticamente e presuma que nada está predefinido antes da execução. Não há problema em usar algumas variáveis ’globais’, mas não as use demais.
Como desenvolvedor, você pode enfrentar cenários em que pensa que está atualizando valores com escopo global, mas porque o service worker não foi encerrado como você esperava. Isso pode levar à perda de tempo na solução de problemas de porque seu novo código não está funcionando conforme o esperado. Pode ser necessário encerrar explicitamente o service worker nas DevTools.
Faço isso com frequência e também cancelo o registro manualmente dos service workers, porque eles ficam malucos depois de fazer várias camadas de alterações durante um ciclo de desenvolvimento (o que chamo quando me sento por algumas horas com meus fones de ouvido e meu mente focada).
Isso não significa que você não deve criar variáveis globais em seu service worker, significa apenas ser inteligente sobre o que está declarando.
O Service Worker não está respondendo
Outra mensagem relacionada que você pode ver no console é”o service worker não está respondendo”.
Isso é comum se você estiver sentado em um ponto de interrupção por um longo período de tempo. Eu vi essa mensagem algumas vezes, normalmente quando vejo algum código quebrado e começo um conjunto de trilhas de coelho, atualizando o código ou alguma outra distração interrompe meu foco.
Todos nós já passamos por isso.
Acho que é melhor matar a instância de depuração e começar do zero depois de fazer as alterações de qualquer maneira. Portanto, não deixe este te assustar.
Você deve se preocupar com a rescisão de um service worker?
Não surte se um usuário se sentar em uma página ou deixar a guia aberta em segundo plano. Seu service worker ficará dormente. Assim que o usuário carrega uma nova página, atualiza uma página, dispara uma solicitação de rede ou um gatilho externo, como uma notificação push acontece, o service worker volta à vida.
Semelhante a um AWS Lambda ou a funções do Azure, os funcionários passam de inativos para ativos quase instantaneamente. Pessoalmente, acho que essa latência costuma ser de 5 a 10ms. Poderia ser mais, mas essas são minhas observações aproximadas nos últimos anos.
Você pode ficar estressado por causa de um estado dormente, mas esse não é um bom uso de seus recursos, porque os prestadores de serviço são projetados para estarem presentes quando você precisar deles.
Resumo
A”rescisão do service worker por um temporizador de tempo limite foi cancelada porque o DevTools está anexado”é uma mensagem de cortesia para ajudar os desenvolvedores a saber que a experiência do service worker com a qual estão testando pode não refletir a experiência de um usuário de produção. Se você vir isso e quiser ter certeza de que o seu service worker executa conforme o esperado, você deve pensar em executar o aplicativo da web progressivo sem as DevTools abertas.
Claro, você deve sempre testar como seus usuários reais experimentariam seus aplicativos. Isso significa que você também deve testar em dispositivos móveis reais, como um telefone de US $ 100 do Walmart em uma rede 3G. Mas apenas fechar as DevTools pode ser um bom primeiro passo para aprofundar os problemas comuns.
