ユーザーがタブを離れた後、または画面をオフにした後、ブラウザーがタイマーとWebSocketの切断をスロットルするタイミングを検出するにはどうすればよいですか？（JavaScript）

環境

タイマー（setTimeout、setInterval）とWebSocket接続を備えたプログレッシブWebアプリとして出荷されるゲームは、リアルタイムの通信を取得します。

何が起こっている

ユーザーがアプリにとどまっている限り、すべてが正常です。しかし、ユーザーが別のタブや別のアプリに移動したり、画面をオフにすると（モバイルの場合）、それは「地獄のような未知の世界」になります。

• WebSocketが「一時停止」または「オフ」になる場合とされない場合があります。
• タイマーはスロットルまたはデバウンスされているように見えます。

この動作はブラウザとプラットフォームに依存しているようで、特定のユーザーの動作にも依存しているようです。ブラウザーやOSには、バッテリーや計算を節約するための独自のライフサイクル/メカニズムがあると思います。

ユーザーが戻ったとき、アプリは不明な状態にあり、状態を適切に復元するのに苦労しています。

websocketに関しては、socket.ioとの自動再接続とreconnecting-websocketがありますが、すべてを解決するには十分ではありません。

答えを探しています

• これらに関するさまざまなブラウザの「ライフサイクル」は何ですか？これは文書化されていますか？彼らはいつオフにしてスロットルすることを決めますか？
• 彼らはウェブソケットに対して正確に何をしますか？ブラウザはそれらを切断するだけですか？
• 彼らはタイマーに対して正確に何をしますか？彼らはそれらを抑制したり、それらをデバウンスしたりしますか？
• JavaScriptの実行は一般にどうなりますか？一時停止/破棄/スロットル？
• 何かをオフにするときに、ブラウザのライフサイクルイベントにフックする方法はありますか？私が見つけることができる唯一のものは可視性APIかもしれません

• ソリューションをテストできるように、この動作を人工的に再現する方法はありますか？デスクトップでは特に難しいです。WebSocketをオフにすることはできず、Chromium開発者は2014（！）の問題を急いで支援しているようには見えません：接続スロットルを使用する場合、WebSocketは含まれません

• 上記に関係なく、この問題を検出/解決する実用的なクロスブラウザソリューションはありますか？（たとえば、経験から、デスクトップ上のFirefoxはChromeと比べて動作がまったく異なるようで、iPhoneはAndroidよりはるかに頻繁に切断されます）

関連リンク

• Safariは、ページがフォーカスされていないときに非アクティブのためにWebソケット接続をドロップします

正確にはわかりませんが、Service Workerを使用できます。私が知っている限りでは、タブが開かれていなくてもバックグラウンドで実行され、タブが閉じられると終了します。

ところで ブラウザのタブのライフサイクルは、ブラウザごとに異なるため、ブラウザごとに異なります。ブラウザーが他のもののためにより多くのメモリを必要とする場合、ブラウザーがタブをフリーズさせることができると私が見るところから。

こちらがChromeのドキュメントです。

onloadのように、ユーザーがタブを離れたり開いたりしたことを通知するイベントがあることを思い出しました。これらのイベントを使用して、再接続などを行うことができます。

アプリの設計方法について、さまざまなアドバイスをさせていただきます。私が理解していることから、あなたの意図は、ユーザーがブラウザーでアクティブでなくなったかどうかを理解するために、さらにロジックを追加することです。これには、そのロジックを実装するためのブラウザー固有の別の問題が伴います。それを念頭に置いて、代わりにサーバーとクライアントの両方でエラー処理を改善することに投資します。

エラーはブラウザ固有のものではありません。これらを処理することで、ブラウザーの変更に対してアプリの耐障害性と不可知性が高まり、最終的に変更される可能性があります。たとえば、タブを休止状態にする方法、ベンダーが将来実装する可能性のあるその他の機能などです。

これはサービスアーキテクチャで見つけることができるアイデアですが、同じパターンがすべてのWebアプリに当てはまります。あなたはDesign-for-Fail概念を探したいかもしれません：

複雑さのために、システムが依存しているシステムの一部にロバスト性を想定することは不可能です。代わりに、ITスタックベースの任意のレイヤーでシステムとアプリケーションを設計して、下位レベルでの障害の可能性を想定する必要があります。失敗のための設計では、すべての層でフォールトトレランスを考慮する必要があります。アプリケーション開発者はもはや機能について考えることに専念することはできません。

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