Wie kann man erkennen, wenn der Browser die Trennung von Timern und Websockets drosselt, nachdem ein Benutzer einen Tab verlassen oder den Bildschirm ausgeschaltet hat? (Javascript)

Kontext

Ein Spiel, das als progressive Web-App ausgeliefert wird und über Timer ( setTimeout, setInterval) und Websocket-Verbindungen verfügt, um Echtzeitkommunikation zu erhalten.

Was ist los

Alles ist in Ordnung, solange der Benutzer in der App bleibt. Wenn der Benutzer jedoch zu einem anderen Tab oder einer anderen App wechselt oder den Bildschirm ausschaltet (im Falle eines Mobilgeräts), wird dies zu einer "höllisch unbekannten Welt".

• Websockets können "angehalten" oder "ausgeschaltet" werden oder nicht.
• Timer sehen aus, als würden sie gedrosselt oder entprellt.

Dieses Verhalten scheint von Browsern und Plattformen abzuhängen und möglicherweise sogar vom jeweiligen Benutzerverhalten. Ich denke, Browser und Betriebssystem haben ihren eigenen Lebenszyklus / ihre eigenen Mechanismen, um Batterie und / oder Berechnung zu sparen.

Wenn der Benutzer zurückkommt, befindet sich die App in einem unbekannten Zustand und ich habe Probleme, den Zustand ordnungsgemäß wiederherzustellen.

In Bezug auf WebSockets Ich habe Auto-Wiederverbindung mit socket.io und wieder anschließen-websocket aber es ist nicht genug , um alles zu lösen.

Nach Antworten suchen

• Was sind die "Lebenszyklen" der verschiedenen Browser in Bezug auf diese? Ist das dokumentiert? Wann entscheiden sie sich auszuschalten und zu drosseln?
• Was machen sie genau mit Websockets? Browser trennen sie einfach?
• Was machen sie genau mit Timern? Sie drosseln sie oder entprellen sie oder etwas anderes?
• Was passiert mit der Ausführung von Javascript im Allgemeinen? Angehalten / zerstört / gedrosselt?
• Gibt es eine Möglichkeit, sich in eine Art Browser-Lebenszyklusereignis einzubinden, wenn es die Dinge ausschaltet? Das einzige, was ich finden konnte, war möglicherweise die Sichtbarkeits-API

• Gibt es eine Möglichkeit, dieses Verhalten künstlich zu reproduzieren, um Lösungen testen zu können? Es ist besonders schwer auf dem Desktop. Websockets können nicht deaktiviert werden, und Chromentwickler scheinen es nicht eilig zu haben, ein Problem aus dem Jahr 2014 (!) Zu beheben: Websockets sind bei Verwendung der Verbindungsdrosselung nicht enthalten

• Gibt es unabhängig davon eine pragmatische browserübergreifende Lösung, um dieses Problem zu erkennen / zu lösen? (Zum Beispiel scheint sich Firefox auf dem Desktop aus Erfahrung völlig anders zu verhalten als Chrome, und ein iPhone trennt die Verbindung weitaus häufiger als ein Android-Gerät.)

verwandte Links

• Safari beendet die Web-Socket-Verbindung aufgrund von Inaktivität, wenn die Seite nicht scharfgestellt ist

Nicht ganz sicher, aber Sie könnten Servicemitarbeiter einsetzen. Soweit ich weiß, werden sie im Hintergrund ausgeführt, auch wenn Ihre Registerkarte nicht geöffnet ist, und werden beendet, wenn Ihre Registerkarte geschlossen wird.

Übrigens. Die Lebenszyklen von Browser-Registerkarten scheinen bei jedem Browser unterschiedlich zu sein, da jeder Browser anders damit umgeht. Soweit ich weiß, kann der Browser Tabs einfrieren, wenn der Browser mehr Speicher für andere Dinge benötigt.

Hier sind die Dokumente von Chrome .

Ich erinnerte mich, dass es einige Ereignisse gibt, wie z. B. Onload, die Ihnen mitteilen, ob ein Benutzer die Registerkarte verlassen oder erneut geöffnet hat. Sie können dieses Ereignis verwenden, um die Verbindung usw. wiederherzustellen.

Ich würde verschiedene Ratschläge bezüglich der Gestaltung Ihrer App geben. Soweit ich weiß, möchten Sie mehr Logik hinzufügen, um zu verstehen, ob der Benutzer nicht mehr im Browser aktiv ist. Dies bringt ein anderes Problem mit sich, nämlich die Browserspezifikationen zur Implementierung dieser Logik. In diesem Sinne würde ich stattdessen in eine bessere Fehlerbehandlung sowohl auf dem Server als auch auf dem Client investieren .

Fehler sind nicht browserspezifisch. Durch die Handhabung dieser Funktionen wird Ihre App widerstandsfähiger und agnostischer gegenüber Browseränderungen, die sich möglicherweise ändern, beispielsweise die Art und Weise, in der sie einen Tab in den Ruhezustand versetzen, sowie alle anderen Funktionen, die ein Anbieter möglicherweise in Zukunft implementiert.

Dies ist eine Idee, die Sie in der Dienstarchitektur finden können, aber das gleiche Muster gilt für jede Web-App. Vielleicht möchten Sie nach Design-for-FailKonzepten suchen :

Komplexität macht es unmöglich, Robustheit seitens der Systeme anzunehmen, auf die man sich verlässt. Stattdessen müssen Systeme und Anwendungen auf einer bestimmten Ebene im IT-Stack entworfen werden, um die Möglichkeit eines Ausfalls auf niedrigeren Ebenen anzunehmen. Design-for-Fail erfordert das Nachdenken über Fehlertoleranz auf allen Ebenen. Anwendungsentwickler können sich nicht mehr darauf beschränken, über Funktionalität nachzudenken.

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