Come rilevare quando il browser limita i timer e la disconnessione dei websocket dopo che un utente lascia una scheda o spegne lo schermo? (Javascript)

Contesto

Un gioco distribuito come un'app Web progressiva con timer ( setTimeout, setInterval) e connessioni Web per ottenere comunicazioni in tempo reale.

Che cosa sta succedendo

Va tutto bene finché l'utente rimane nell'app. Ma quando l'utente passa a un'altra scheda o un'altra app o spegne lo schermo (nel caso di dispositivi mobili), diventa un "mondo infernale sconosciuto".

• I websocket possono o meno diventare "in pausa" o "disattivati"
• I timer sembrano essere strozzati o rimbalzati.

Questo comportamento sembra dipendere dai browser e dalla piattaforma e, forse, dipende anche dal comportamento particolare dell'utente. Suppongo che i browser e il sistema operativo dispongano di un proprio ciclo di vita / meccanismi per risparmiare batteria e / o calcolo.

Quando l'utente torna, l'app si trova in uno stato sconosciuto e faccio fatica a ripristinare correttamente lo stato.

Per quanto riguarda i websocket, ho una riconnessione automatica con socket.io e riconnessione-websocket, ma non è sufficiente per risolvere tutto.

In cerca di risposte

• Quali sono i "cicli di vita" dei diversi browser in merito? Questo è documentato? Quando decidono di spegnere e accelerare?
• Cosa fanno esattamente ai websocket? I browser li disconnettono e basta?
• Cosa fanno esattamente ai timer? Li rallentano o li rimbalzano o qualcos'altro?
• Cosa succede all'esecuzione di JavaScript in generale? In pausa / distrutto / strozzato?
• C'è un modo per agganciarsi a una sorta di evento del ciclo di vita del browser quando spegnerà le cose? L'unica cosa che ho potuto trovare potrebbe essere l' API di visibilità

• C'è un modo per riprodurre artificialmente questo comportamento per poter testare le soluzioni? È particolarmente difficile sul desktop. I websocket non possono essere disattivati ​​e gli sviluppatori di cromo non sembrano avere fretta di risolvere un problema dal 2014 (!): I websocket non sono inclusi quando si utilizza la limitazione della connessione

• Indipendentemente da quanto sopra, esiste una soluzione pragmatica tra browser per rilevare / risolvere questo problema? (ad esempio, per esperienza, Firefox sul desktop sembra comportarsi in modo completamente diverso rispetto a Chrome e un iPhone si disconnetterà molto più spesso di un Android)

Link correlati

• Safari interrompe la connessione al socket Web a causa dell'inattività quando la pagina non è attiva

Non esattamente sicuro, ma potresti usare i lavoratori dell'assistenza. Per quanto ne so, vengono eseguiti in background anche se la scheda non è aperta e vengono terminati se la scheda si chiude.

Btw. i cicli di vita delle schede del browser sembrano essere diversi su ogni browser, poiché ogni browser lo gestisce in modo diverso. Da quello che vedo che il browser può bloccare le schede se il browser ha bisogno di più memoria per altre cose.

Ecco i documenti di Chrome .

Ho ricordato che ci sono alcuni eventi, come onload che ti dicono se un utente ha lasciato o riaperto la scheda. È possibile utilizzare questi eventi per riconnettersi ecc.

Darei diversi consigli su come progettare la tua app. Da quello che capisco la tua intenzione è quella di aggiungere più logica per capire se l'utente non è più attivo nel browser. Ciò comporta un problema diverso, che è specifico del browser per implementare quella logica. Con questo in mente, investirei invece in una migliore gestione degli errori , sia nel server che nel client.

Gli errori non saranno specifici del browser. La gestione di questi renderà la tua app più resiliente e agnostica alle modifiche del browser, che potrebbero eventualmente cambiare, diciamo, il modo in cui ibernano una scheda, qualsiasi altra funzionalità che un fornitore potrebbe implementare in futuro.

Questa è un'idea che puoi trovare nell'architettura dei servizi, ma lo stesso modello si applica a qualsiasi app web. Potresti voler cercare Design-for-Failconcetti:

La complessità rende impossibile assumere la solidità da parte dei sistemi su cui si fa affidamento. Al contrario, è necessario progettare sistemi e applicazioni in qualsiasi dato livello dello stack IT in base per ipotizzare la possibilità di guasti a livelli inferiori. Design-for-fail richiede di pensare alla tolleranza agli errori a tutti i livelli. Gli sviluppatori di applicazioni non possono più limitarsi a pensare alla funzionalità.

https://www.oreilly.com/library/view/designing-delivery/9781491903742/ch04.html