引用：ccze 发表于 2022-08-04 12:32
首先感谢您如此详尽的回答

看您的分析也解答了我的疑问

嗯嗯 像这样的技术都是从移动端反哺到pc端，反而是降低了体验

引用：JackJiang 发表于 2022-08-04 12:01
花了3个多小时，fan墙查了很多资料。我把我的结论和目前掌握的信息分享一下。

►【问题现象】：

首先感谢您如此详尽的回答

看您的分析也解答了我的疑问

这是Chrome层面进行的配置，与页面代码无关

那下一步就要考虑其它方式来解决这个问题了

再次感谢您的回复

花了3个多小时，fan墙查了很多资料。我把我的结论和目前掌握的信息分享一下。

►【问题现象】：
当Chrome（以及Safari、Edge这类基于相同内核的浏览器中）中的选项卡Tab处于后台大约5分钟左右后，WebSocket会被Chrome定时阻断。

参考资料：

• 谷歌浏览器标签页长时间切换到后台后mqtt会自动断开连接解决方案
• Client WebSocket disconnects when browser is minimized or not in focus - Chrome
• Feature: Intensive throttling of Javascript timer wake ups
  

►【问题原因】：
原因是从Chrome86版以后，增加了一个叫“密集唤醒节流”（Intensive Wake Up Throttling）的功能（查了很多资料，Chrome对这个功能的叫法一直在变，可能谷歌也一直没找准它的最终定位和叫法），这个功能类似于Android手机里的节电、节流策略控制，目的就是为了省电等。

参考资料：

• 新版Chrome正在调整CPU使用率以延长电池寿命
• 谷歌Chrome浏览器杀后台功能升级：降低CPU、内存占用
  

►【尝试解决方法1】：（此方法无法使用，因为高版本，比如Chrome103里，并没有这个设置选项！）
参考资料：
谷歌浏览器标签页长时间切换到后台后mqtt会自动断开连接解决方案

►【尝试解决方法2】：（此方法Jack证实无效，因为Chrome103版本，没有跟参考资料里严格对应的选项！）
参考资料：
how to disable timer throttling on Google Chrome

我按资料里，找到了以下最接近的4个设置项进行了设置，仍然无法禁用节电模式：


►【尝试解决方法3】：（此方法Jack暂时无法证实，因为资料里是修改windows的注册表，而我用的是Mac系统！）
方法是修改注册表（我估计在新版Chrome中，因此特性已被定义了正式功能，所以是无法在“chrome://flags/”这样的实验性质选项里出现的）：

Windows Registry Editor Version 5.00

; Created by: Shawn Keene to add registry values as outlined in this support article:
; [url=https://community.niceincontact.com/s/article/MAX-Softphone-Fails-to-Receive-Contacts-Resulting-in-Refused-Calls]https://community.niceincontact. ... ng-in-Refused-Calls[/url]

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Edge]
"IntensiveWakeUpThrottlingEnabled"=dword:0

[HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome]
"IntensiveWakeUpThrottlingEnabled"=dword:0

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Edge]
"IntensiveWakeUpThrottlingEnabled"=dword:0

[HKEY_CURRENT_USER\Software\Policies\Google\Chrome]
"IntensiveWakeUpThrottlingEnabled"=dword:0

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Edge]
"WindowOcclusionEnabled"=dword:0

[HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome]
"WindowOcclusionEnabled"=dword:0

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Edge]
"WindowOcclusionEnabled"=dword:0

[HKEY_CURRENT_USER\Software\Policies\Google\Chrome]
"WindowOcclusionEnabled"=dword:0

参考资料：
Chrome 90 removed #intensive-wake-up-throttling Flag
Control the IntensiveWakeUpThrottling feature.
How to Enable or Disable Tab Freezing in Google Chrome

►【截止20220804日的结论】：
截止目前，可以证实，WebSocket处于后台于被Chrome断掉的原因，就是因为Chrome的节电模式导致的。
但此模式在Chrome中属于不希望被用户进行手动设置的功能，所以很难找到准确的设置选项进行禁用。
所以，暂时没有更好的方法禁用此模式，如果你有更好的建议和发现，可以通过回贴跟我讨论！非常感谢！

不过，经过连续24个小时的实验证实，FireFox火狐这样的浏览器里并没有这种特性，也就是它不会在后台时定时断掉WebSocket！

引用：ccze 发表于 2022-08-04 10:45
谢谢您的解答

这个链接我看到了，按文章里查看，chrome 103没有M89这个配置项，估计是改名字了，或者删 ...

我这没找到这个配置选项，谷歌对这个选项的管理在不同版本可能完全不一样，也有可能就不希望用户自已来更改。

总之，这种限制就像android手机一样，是整个浏览器和系统的行为的话，那怕是只能忍了，或者找到配置选项强行改，但不同的版本这个选项可能又不一样，或者官方对它的定位一直不够准确、一直变化，所以要让用户手动改，可能也不容易

谢谢您的解答

这个链接我看到了，按文章里查看，chrome 103没有M89这个配置项，估计是改名字了，或者删除了

这几个关键词搜chrome配置项，也没找到，请问您找到相关配置项了吗？

引用：ccze 发表于 2022-08-03 21:50
一、环境：
1）jdk
oracle jdk 1.8.0_191-b12

我安装你的版本，模拟了你的环境，我大致找到原因了：因为Chrome自86版后，启用了一个省电的策略（具体你可以先看一下这个链接），会阻止不处于前台的选项卡的包括websocket在内的网络，具体明天上班了我再详细核实一下后再跟你详聊，你也可以研究一下

一、环境：
1）jdk
oracle jdk 1.8.0_191-b12
2）浏览器；
chrome 103.0.5060.134
3）操作系统（服务端和浏览器端的系统）
服务端和浏览器的操作系统，都是同一台电脑  win10 21H2

二、网络说明：
网络无特别环境，server demo本机启动，浏览器端本机浏览器访问

三、部署说明：
最后两张截图是启动的您给我的demo，在本机做的测试

四、断连复现的要点：
1.浏览器打开demo页面；
2.开启开发者工具；
3.切换到其它标签页等待10-20分钟以上；
4.返回本页面，就会发现NetWork一直断线重连；
5.打开demo页面，一直停留在本页面，不会出现断连情况；

比如我这边的情况，从登陆（晚上9点14分），到截图的时候（晚是9点28分），将近15分钟的时间内，一次也没掉线。
所以，作为对比，你几十秒就掉一次线，显然不正常，你收集一下你的测试信息，按我上个回复里的线索收集一下，我帮你诊断诊断。

以下截图是我的测试情况：

登陆时的log时间：


截图时的log时间：

引用：ccze 发表于 2022-08-03 18:34
请问您在本地运行 h5的demo 和 服务端的demo，不会出现这种情况吗？

后面两张图，是我在本地使用您发的  ...

你这个log上掉线太频繁了，几十秒就掉一次，很不正常，我一直没碰到过这种情况。

你的：
1）jdk（指的是MobileIMSDK服务端的运行环境）；
2）浏览器；
3）操作系统（服务端和浏览器端的系统）

分别是什么版本，你统计一下，我来看看会是什么情况。

另外，你的网络有什么特别的地方吗，比如有vpn？、有翻墙？

还有，你浏览器和服务端分别运行的什么环境下？比如服务器是运行在阿里云？浏览器是运行在公司wifi？

请问您在本地运行 h5的demo 和 服务端的demo，不会出现这种情况吗？

后面两张图，是我在本地使用您发的 h5demo 和 服务端demo ，也会出现相同的问题

我看懂你的问题描述了。

代码里客户端使用的是标准的浏览器端websocket api，服务端也是很通用的netty的websocket服务，一般来说不至于。

要排除这个问题，你能否在你的相同浏览和网络下，用netty官方提供的标准Demo：websocket demo，比如让它定时5秒收发消息，看看它在同样的浏览器版本和网络下会不会也断开，如果标准的netty官方demo不断开，那么MobileIMSDK的这个h5的sdk在你同样的网络和浏览器版本下也应该现象一致，否则那就有可能是h5 sdk本身的兼容问题，如果是这样，我就再跟你深入按浏览器进行追查调试，否则就再找的别的可能性来诊断了。

这个问题，你保持联络，有情况随时回复我，我跟你一起分析