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

Question

上下文

作为渐进式网络应用发布的游戏，具有计时器（setTimeout、setInterval）和 websocket 连接以实现实时通信。

发生了什么

只要用户留在应用程序中，一切都很好。但是当用户转到另一个标签页、另一个应用程序或关闭屏幕（如果是移动设备）时，它就变成了一个“地狱般的未知世界”。

• Websocket 可能会也可能不会“暂停”或“关闭”
• 定时器看起来像是被限制或去抖动。

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

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

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

寻找答案

• 不同浏览器的“生命周期”是什么？这有记录吗？他们什么时候决定关闭和节流？
• 他们究竟对 websocket 做了什么？浏览器只是断开连接？
• 他们究竟对定时器做了什么？它们会限制它们或消除它们的抖动或其他什么？
• javascript 执行一般会发生什么情况？暂停/销毁/限制？
• 当它要关闭某些浏览器生命周期事件时，有没有办法挂钩？我唯一能找到的可能是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，它会告诉您用户是离开还是重新打开了选项卡。您可以使用这些事件重新连接等。

Answer 2

我会就如何设计您的应用提供不同的建议。据我了解，您的意图是添加更多逻辑，以了解用户是否不再在浏览器中处于活动状态。这需要一个不同的问题，即 浏览器细节 来实现该逻辑。考虑到这一点，我会转而投资在服务器和客户端中拥有更好的错误处理。

错误不会是特定于浏览器的。处理这些将使您的应用更具弹性，并且不受浏览器更改的影响，最终可能会改变，比如说，他们休眠选项卡的方式，供应商将来可能实现的任何其他功能。

这是您可以在服务架构中找到的想法，但同样的模式适用于任何网络应用程序。您可能想查找Design-for-Fail 概念：

复杂性使得假设所依赖的系统部分具有鲁棒性是不可行的。相反，人们需要在 IT 堆栈中的任何给定层设计系统和应用程序，以假设较低级别发生故障的可能性。为失败而设计需要考虑所有层的容错性。应用程序开发人员不能再局限于考虑功能。

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