在用戶離開選項卡或關閉屏幕后，如何檢測瀏覽器何時限制計時器和 websockets 斷開連接？ （javascript）

Question

語境

作為漸進式 Web 應用程序提供的游戲，它具有計時器（ setTimeout 、 setInterval ）和 websocket 連接以獲得實時通信。

怎么了

只要用戶留在應用程序中，一切都很好。 但是當用戶轉到另一個選項卡、另一個應用程序或關閉屏幕（在移動設備的情況下）時，它就變成了一個“地獄般的未知世界”。

• Websockets 可能會也可能不會“暫停”或“關閉”
• 計時器看起來像是受到了限制或去抖動。

這種行為似乎取決於瀏覽器和平台，甚至可能取決於特定的用戶行為。 我猜瀏覽器和操作系統有自己的生命周期/機制來節省電池和/或計算。

當用戶回來時，應用程序處於未知狀態，我正在努力正確恢復狀態。

關於 websockets 我有與socket.io和reconnecting-websocket 的自動重新連接，但這還不足以解決所有問題。

尋找答案

• 不同瀏覽器的“生命周期”是什么？ 這是記錄在案嗎？ 他們什么時候決定關閉和油門？
• 他們對 websockets 做了什么？ 瀏覽器只是斷開它們？
• 他們究竟對計時器做了什么？ 他們扼殺他們或消除他們或其他什么？
• javascript 執行一般會發生什么？ 暫停/銷毀/節流？
• 當它要關閉時，有沒有辦法掛鈎某種瀏覽器生命周期事件？ 我唯一能找到的可能是可見性 API

• 有沒有辦法人為地重現這種行為以測試解決方案？ 在桌面上尤其困難。 Websockets 無法關閉，並且 Chrome 開發人員似乎並不急於解決 2014 年的問題（！）：使用連接限制時不包括 websockets

• 不管上述情況，是否有實用的跨瀏覽器解決方案來檢測/解決此問題？ （例如，根據經驗，與 Chrome 相比，桌面版 Firefox 的行為似乎完全不同，iPhone 斷開連接的頻率遠高於 Android）

相關鏈接

• Safari 在頁面未聚焦時由於不活動而丟棄 Web 套接字連接

Answer 1

不完全確定，但您可以使用服務工作者。 據我所知，即使您的選項卡沒有打開，它們也會在后台運行，如果您的選項卡關閉，它們就會被終止。

順便提一句。 瀏覽器標簽的生命周期似乎在每個瀏覽器上都不同，因為每個瀏覽器處理它的方式都不一樣。 從我看來，如果瀏覽器需要更多內存來處理其他事情，它可以凍結選項卡。

這是來自Chrome的文檔。

我記得有一些事件，比如 onload 會告訴你用戶是否已經離開或重新打開了選項卡。 您可以使用這些事件重新連接等。

Answer 2

我會就如何設計您的應用程序提供不同的建議。 據我了解，您的意圖是添加更多邏輯以了解用戶是否不再在瀏覽器中處於活動狀態。 這帶來了一個不同的問題，即實現該邏輯的瀏覽器細節。 考慮到這一點，我會改為投資在服務器和客戶端都有更好的錯誤處理。

錯誤不會特定於瀏覽器。 處理這些將使您的應用程序對瀏覽器更改更具彈性和不可知性，這最終可能會改變，比如說，他們休眠選項卡的方式，供應商將來可能實現的任何其他功能。

這是您可以在服務架構中找到的想法，但相同的模式適用於任何 Web 應用程序。 您可能想要尋找“ Design-for-Fail概念：

復雜性使得假設一個人依賴的系統部分具有魯棒性是不可行的。 相反，人們需要在基於 IT 堆棧的任何給定層設計系統和應用程序，以假設較低級別出現故障的可能性。 為失敗而設計需要考慮所有層的容錯能力。 應用程序開發人員不能再局限於考慮功能。

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