javascript - 如何在用户离开选项卡或关闭屏幕后检测浏览器何时限制计时器和 websockets 断开连接？ (javascript)

Question

上下文

一款作为渐进式 Web 应用程序发布的游戏，它具有计时器(setTimeout、setInterval)和 websocket 连接以获得实时通信。

发生了什么

只要用户留在应用程序中，一切都很好。但是当用户转到另一个选项卡、另一个应用程序或关闭屏幕(如果是移动设备)时，它就变成了一个“ hell 般的未知世界”。

Websocket 可能会或可能不会“暂停”或“关闭”

计时器看起来像是被限制或去抖动。

这种行为似乎取决于浏览器和平台，甚至可能取决于特定的用户行为。我猜浏览器和操作系统有自己的生命周期/机制来节省电池和/或计算。

当用户回来时，应用程序处于未知状态，我正在努力正确恢复状态。

关于 websockets 我有自动重新连接 socket.io和 reconnecting-websocket但这还不足以解决所有问题。

寻找答案

关于这些，不同浏览器的“生命周期”是什么？这有记录吗？他们什么时候决定关闭和节流？

他们对 websocket 到底做了什么？浏览器只是断开它们？

他们对计时器到底做了什么？他们限制它们或消除它们或其他什么？

一般来说，javascript 执行会发生什么？暂停/销毁/节流？

当它要关闭时，有没有办法 Hook 某种浏览器生命周期事件？我唯一能找到的可能是 visibility API

有没有办法人为地重现这种行为以便能够测试解决方案？在台式机上尤其困难。 Websockets 无法关闭，Chromium 开发人员似乎并不急于提供帮助 an issue from 2014(!): websockets not included when using connection throttling

不管以上，是否有一个实用的跨浏览器解决方案来检测/解决这个问题？ (例如，从经验来看，桌面版 Firefox 与 Chrome 的行为似乎完全不同，iPhone 断开连接的频率远高于 Android)

相关链接

Safari dropping web socket connection due to inactivity when page not in focus

Answer 1

不完全确定，但您可以使用服务人员。据我所知，即使您的标签未打开，它们也会在后台运行，并且如果您的标签关闭，它们也会终止。
顺便提一句。每个浏览器的浏览器选项卡的生命周期似乎都不同，因为每个浏览器处理它的方式不同。据我所知，如果浏览器需要更多内存来处理其他事情，它可以卡住标签。
这是来自 Chrome 的文档.
我记得有一些事件，比如 onload 会告诉你用户是离开还是重新打开了选项卡。您可以使用这些事件重新连接等。