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

上下文

一款以渐进式web应用程序形式发布的游戏，它具有计时器（

setTimeout

，

setInterval

）和websocket连接以获得实时通信

发生了什么事

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

• WebSocket可能会也可能不会变成“暂停”或“关闭”
• 计时器看起来像是被节流或减速了

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

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

关于WebSocket，我已经自动重新连接了，但这还不足以解决所有问题

寻找答案

• 关于这些，不同浏览器的“生命周期”是什么？这有文件记录吗？他们什么时候决定关掉油门
• 他们到底对WebSocket做了什么？浏览器只是断开它们
• 他们到底对计时器做了什么？他们会掐死它们或者让它们脱壳或者其他什么
• javascript执行通常会发生什么变化？暂停/销毁/限制
• 当浏览器要关闭时，有没有一种方法可以连接到某种浏览器生命周期事件中？我唯一能找到的可能就是
• 有没有一种方法可以人工复制这种行为来测试溶液？在桌面上尤其困难。WebSocket无法关闭，chromium开发人员似乎并不急于提供帮助

• 不管上述情况如何，是否有实用的跨浏览器解决方案来检测/解决此问题？（例如，从经验来看，桌面上的Firefox与Chrome的表现似乎完全不同，iPhone断开连接的频率远远高于Android）

相关链接

---

不太确定，但您可以使用服务人员。据我所知，即使您的选项卡未打开，它们也会在后台运行，如果您的选项卡关闭，它们将被终止
顺便说一句，每个浏览器上的浏览器选项卡的生命周期似乎都不同，因为每个浏览器处理它的方式都不同。据我所见，如果浏览器需要更多的内存来处理其他事情，它可以冻结选项卡
这是我的文件

---

我记得有一些事件，比如onload，会告诉您用户是否离开或重新打开了选项卡。您可以使用这些事件来重新连接等等。
关于如何设计您的应用程序，我会给出不同的建议。据我所知，您的意图是添加更多逻辑，以便了解用户是否不再在浏览器中活动。这带来了一个不同的问题，即浏览器特定的来实现该逻辑。考虑到这一点，我将转而投资于在服务器和客户机上更好地处理错误
错误不会是特定于浏览器的。处理这些问题将使你的应用程序更具弹性，更不受浏览器变化的影响，而浏览器变化最终可能会改变，比如说，它们休眠选项卡的方式，以及供应商将来可能实现的任何其他功能
这是一个可以在服务体系结构中找到的想法，但同样的模式适用于任何web应用程序。您可能需要寻找

失败设计

概念：
复杂性使得我们不可能假设所依赖的系统的健壮性。相反，需要在IT堆栈中的任何给定层设计系统和应用程序，以假设在较低级别出现故障的可能性。针对故障的设计需要考虑所有层的容错性。应用程序开发人员不再局限于考虑功能

---

这只是一个草稿。这是一个有趣的想法。很抱歉，我现在没有示例代码，但是如果你搜索服务人员，有大量的教程介绍如何设置他们。您只需要在连接到ws-server的地方放一个小代码，在从ws-server收到消息时放一个

console.log（）

。在chrome中，你可以打开服务人员的控制台，这样你就可以测试当你离开该选项卡时消息是否被修改。你在考虑什么样的“更好的错误处理”？