Context
一款作为渐进式网络应用程序发布的游戏，具有计时器（setTimeout, setInterval）和 websocket 连接以获得实时通信。
怎么了
只要用户留在应用程序中，一切都很好。但是，当用户转到另一个选项卡、另一个应用程序或关闭屏幕（如果是移动设备）时，它就变成了“地狱般的未知世界”。
- Websocket 可能会也可能不会“暂停”或“关闭”
- 计时器看起来像是受到限制或反跳。
这种行为似乎取决于浏览器和平台，甚至可能取决于特定的用户行为。我猜浏览器和操作系统有自己的生命周期/机制来节省电池和/或计算。
当用户回来时，应用程序处于未知状态，我正在努力正确恢复状态。
关于 websockets 我有自动重新连接套接字.io https://socket.io/ and 重新连接-websocket https://github.com/pladaria/reconnecting-websocket但这还不足以解决所有问题。
寻找答案
- 不同浏览器的“生命周期”是什么？这有记录吗？他们什么时候决定关闭并节流？
- 他们对 websocket 到底做了什么？浏览器只是断开它们？
- 他们对计时器到底做了什么？他们限制它们或使它们反跳还是其他什么？
- javascript 执行一般会发生什么？暂停/销毁/限制？
- 当浏览器要关闭某些东西时，有没有办法挂钩某种浏览器生命周期事件？我唯一能找到的可能是可见性API https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API
有没有办法人为地重现这种行为以便能够测试解决方案？在桌面上尤其困难。 Websocket 无法关闭，并且 chromium 开发人员似乎并不急于提供帮助2014 年的一个问题（！）：使用连接限制时不包括 websockets https://bugs.chromium.org/p/chromium/issues/detail?id=423246
不管上述情况，是否有一个实用的跨浏览器解决方案来检测/解决这个问题？ （例如，根据经验，桌面版 Firefox 的行为似乎与 Chrome 完全不同，iPhone 比 Android 更频繁地断开连接）
相关链接
- 当页面未处于焦点时，Safari 由于不活动而断开 Web 套接字连接 https://github.com/socketio/socket.io/issues/2924
不太确定，但你可以使用服务人员。据我所知，即使您的选项卡未打开，它们也会在后台运行，如果您的选项卡关闭，它们也会终止。
顺便提一句。每个浏览器上的浏览器选项卡的生命周期似乎都不同，因为每个浏览器处理它的方式都不同。据我所知，如果浏览器需要更多内存来处理其他事情，它可以冻结选项卡。
这是来自的文档Chrome https://developers.google.com/web/updates/2018/07/page-lifecycle-api.
我记得有一些事件（例如 onload）会告诉您用户是否离开或重新打开了选项卡。您可以使用这些事件来重新连接等。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
