在用户离开标签页或关闭屏幕后，如何检测浏览器何时阻止计时器和WebSocket断开连接？（javascript）

12

语境

运是一种进步的Web应用程序具有定时器（A比赛setTimeout，setInterval）和WebSocket连接来获得实时通信。

怎么了

只要用户停留在应用程序中，一切都很好。但是，当用户转到另一个选项卡或另一个应用程序或关闭屏幕（在移动设备的情况下）时，它变成了一个“可怕的未知世界”。

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

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

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

寻找答案

关于这些浏览器的不同浏览器的“生命周期”是什么？有记录吗？他们什么时候决定关闭并节流？
他们对websockets到底做了什么？浏览器只是断开它们的连接？
他们到底对计时器做什么？他们会抑制它们或使其反跳吗？
一般而言，javascript执行会怎样？暂停/破坏/节流？
有什么办法可以关闭某些浏览器生命周期事件？我唯一能找到的可能是可见性API
有没有一种方法可以人为地重现此行为以能够测试解决方案？在台式机上尤其困难。Websocket无法关闭，Chrome开发人员似乎并不急于解决2014年以来的问题（！）：使用连接限制时不包含 Websocket
不管以上哪种情况，是否都存在实用的跨浏览器解决方案来检测/解决此问题？（例如，根据经验，台式机上的Firefox的行为似乎与Chrome完全不同，iPhone断开连接的频率要比Android高得多）

相关链接

javascript websocket cross-browser progressive-web-apps

— 凯夫
source

1

这只是wicg.github.io/page-lifecycle的草案。

— norbertpy

7

不确定，但可以使用服务人员。据我所知，即使未打开选项卡，它们也会在后台运行；如果关闭选项卡，它们将被终止。

顺便说一句。在每种浏览器中，浏览器选项卡的生命周期似乎都不同，因为每种浏览器对它的处理方式都不相同。从我看到的结果来看，如果浏览器需要更多的内存来执行其他操作，则浏览器可以冻结选项卡。

这是Chrome的文档。

我记得有一些事件，例如onload，它告诉您用户是否离开或重新打开了选项卡。您可以使用这些事件重新连接等。

— 货币性
source

这是一个有趣的想法。您已经完成了一些共享代码吗？

— 凯夫

抱歉，我现在没有示例代码，但是如果您搜索服务人员，那么会有大量的教程来设置它们。唯一要做的就是在连接到ws服务器的地方放一个小代码，console.log()从ws服务器获取消息时放一个。在chrome中，您可以打开服务人员的控制台，以便可以在离开选项卡时测试消息是否已重新显示。

— Mointy

0

对于如何设计您的应用程序，我会给出不同的建议。据我了解，您的意图是添加更多逻辑，以便了解用户是否不再在浏览器中处于活动状态。这就带来了一个不同的问题，那就是实现该逻辑的浏览器特性。考虑到这一点，我将投资于在服务器和客户端中具有更好的错误处理能力。

错误不是特定于浏览器的。处理这些问题将使您的应用程序对浏览器的更改更具适应性和不可知性，例如，它们最终休眠时，它们休眠选项卡的方式可能会发生变化，而卖方将来可能会实现任何其他功能。

您可以在服务体系结构中找到这种想法，但是相同的模式适用于任何Web应用程序。您可能要寻找Design-for-Fail概念：

复杂性使得假设系统所依赖的部分具有鲁棒性是不可行的。相反，需要在基于IT堆栈的任何给定层上设计系统和应用程序，以承担较低级别的故障可能性。故障设计需要考虑所有层的容错能力。应用程序开发人员不再能够将自己局限于功能方面。

— 上午
source

您在考虑哪种“更好的错误处理”？

— 凯夫