Il Service Worker sembra fermarsi automaticamente ad un certo punto. Questo comportamento chiude involontariamente la connessione WebSocket stabilita all'attivazione.Impedire l'intervento del servizio di assistenza dall'arresto automatico
Quando e perché si ferma? Come posso disabilitare questa azione inaspettata per mantenere il Service Worker in esecuzione?
Quello che vedi è il comportamento previsto e non è probabile che cambi.
Gli addetti all'assistenza hanno intenzionalmente una durata molto breve. Sono "nati" in risposta a un evento specifico (install, activate, message, fetch, push, ecc.), Eseguono il loro compito e quindi "muoiono" poco dopo. La durata della vita è normalmente abbastanza lunga da poter gestire più eventi (ad esempio un install potrebbe essere seguito da un activate seguito da un fetch) prima che il lavoratore muoia, ma alla fine morirà. Questo è il motivo per cui è molto importante non fare affidamento su nessuno stato globale nei propri script e per eseguire il bootstrap di qualsiasi informazione di stato necessaria tramite IndexedDB o Cache Storage API all'avvio dell'operatore di servizio.
Gli addetti all'assistenza sono effettivamente processi in background che vengono installati ogni volta che si visitano determinate pagine Web. Se i processi in background sono stati autorizzati a funzionare a tempo indeterminato, aumenta il rischio di impatto negativo sulla batteria e sulle prestazioni del dispositivo/computer. Per mitigare questo rischio, il tuo browser eseguirà solo quei processi quando sa che è necessario, cioè in risposta a un evento.
Un caso d'uso per WebSockets è che il client stia ascoltando alcuni dati dal server. Per questo caso d'uso, l'alternativa di facile utilizzo del servizio all'uso di WebSockets consiste nell'utilizzare lo Push Messaging API e fare in modo che l'addetto all'assistenza risponda agli eventi push. Tieni presente che nell'attuale implementazione di Chrome, devi mostrare una notifica visibile all'utente quando si gestisce un evento push. Il caso d'uso "silenzioso" push non è supportato al momento.
Se invece di ascoltare i dati dal server, stavi usando WebSockets come un modo per inviare dati dal tuo client al tuo server, purtroppo non c'è un ottimo modo per farlo. Ad un certo punto in futuro, potrebbe esserci un modo per registrare il tuo addetto al servizio di essere svegliato tramite un evento periodico/temporale, a quel punto potresti usare fetch() per inviare dati al server, ma al momento non è supportato in alcuno i browser.
P.S .: Chrome (normalmente) non uccide un operatore di servizio mentre è aperta l'interfaccia DevTools, ma questo è solo per facilitare il debug e non è un comportamento su cui fare affidamento per un'applicazione reale.
È davvero una brutta notizia per me. Dal tuo punto di vista, rispetto a SharedWorker, ServiceWorker ha solo ** un'esistenza più lunga, ma una durata temporanea ** invece di una durata di vita più lunga. IMHO, dovrebbe essere attivo almeno fino a quando tutte le pagine dipendenti non vengono chiuse (come SharedWorker). Adoro ServiceWorker, ma il mio cuore è completamente rotto a causa di questo. – Lewis
ServiceWorker serve per gestire eventi che devono essere attivati al di fuori del contesto di una pagina. Non è per l'elaborazione in background, è a questo che serve SharedWorker. Se si tenta di utilizzarlo per l'elaborazione, è probabile che blocchi gli eventi di recupero che sono terribili per le prestazioni. Speriamo di abilitare SharedWorkers * all'interno di * ServiceWorkers, dal momento che sono per cose diverse. –
Per curiosità, perché non usi SharedWorkers per questo? –
@JaffaTheCake Solo perché ServiceWorker è abbastanza complesso per la mia piccola app offline. Ho usato l'approccio di SharedWorker + Appcache, ma sono passato a ServiceWorker a causa della * durata di vita più lunga *. Inoltre, SharedWorker ha [un bug] (http://stackoverflow.com/questions/28913545/shared-worker-is-teminated-on-reloading-page) sulla pagina di ricaricamento. – Lewis