息屏后websocket中断是系统省电机制所致，ios/android均会冻结网络且不通知；visibilitychange和setinterval在息屏下完全失效；需用ios的bgprocessingtask或android的foreground_service_special_use实现保活。
手机息屏后 WebSocket 中断，不是代码写错了，而是系统在“帮你省电”——iOS 和 Android 都会主动冻结网络连接，且不通知你。单纯靠 setInterval 发心跳、或监听 visibilitychange 做重连，在息屏场景下基本失效：JS 线程被挂起，定时器停摆，事件根本不会触发。
息屏后 JS 心跳完全失效，别再依赖 visibilitychange
很多 H5 项目用 document.addEventListener('visibilitychange', ...) 判断页面是否隐藏，再等几秒重连。这在「切后台」时有效，但对「息屏」无效：Android 息屏后 WebView 进程可能被降级，iOS 息屏后 WebKit 直接暂停 JS 执行，visibilitychange 根本不触发，setTimeout 和 setInterval 全部卡死。
- 实测发现：iPhone 息屏 10 秒内，
WebSocket.readyState仍为1（OPEN），但实际已无法收发数据；服务端在 30–60 秒后因无心跳主动断连 - 安卓部分机型（如小米、华为）息屏 5 秒内就回收 WebView 内存，JS 上下文丢失，
ws.onclose甚至不会回调 -
visibilitychange只反映页面可见性，不反映设备电源状态，息屏 ≠ 页面隐藏，二者触发条件完全不同
iOS 后台保活必须用 BGProcessingTask，不是 background fetch
想让 iOS 在息屏后还能重建 WebSocket，UIBackgroundModes 里只加 fetch 没用——它只允许每 15 分钟一次的低频拉取，且不保证网络可达。真正能用于连接保活的是 BGProcessingTask，但它有硬限制：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 必须在
Info.plist中声明BGTaskSchedulerPermittedIdentifiers，仅注册的 identifier 才能提交任务 - 每次执行上限约 30 秒（系统实际分配常不足 20 秒），超时会触发
task.expirationHandler，此时必须立即ws.close()并释放资源 - 不能在任务中长时间阻塞主线程，需用
URLSessionWebSocketTask异步操作，避免被系统强杀 - 首次调用
BGTaskScheduler.shared.submit(...)前，务必确认用户已授权后台刷新（UIApplication.backgroundRefreshStatus==.available）
Android 前台服务 + FOREGROUND_SERVICE_SPECIAL_USE 是唯一可靠路径
Android 12+（API 31）起，普通 foregroundServiceType="microphone" 已无法绕过息屏限制。必须申请特殊权限并声明对应类型：
- 在
AndroidManifest.xml中添加：<uses-permission android:name="android.permission.FOREGROUND_SERVICE_SPECIAL_USE" android:foregroundservicetype="connectedDevice|microphone"></uses-permission>
- 服务启动时，
startForeground()的foregroundServiceType必须与权限声明严格匹配，否则startForeground()抛SecurityException - 不要用
WakeLock：它已被厂商系统广泛屏蔽（MIUI/EMUI/HarmonyOS 默认禁用），且触发电池优化白名单弹窗，用户大概率拒绝 - WorkManager 或 JobIntentService 不适用：它们无法保证实时性，息屏后首次唤醒延迟常达 2–5 分钟，WebSocket 早被服务端踢出
重连逻辑必须区分「瞬时断连」和「息屏长中断」
息屏后的重连不是简单 ws.close(); new WebSocket(...) 就完事。服务端若未做连接复用设计，频繁新建连接会引发重连风暴，尤其在多设备同时息屏又亮屏时。
- 客户端应记录上次成功通信时间戳，亮屏后先检查间隔：若 > 90 秒，走完整重连流程（含鉴权、同步状态）；若
- 服务端需支持连接迁移：允许同一用户 Token 在新连接建立后，自动接管旧连接未确认的消息（如使用 Redis 存储 session state）
- 客户端重连前必须清空所有 pending message 缓冲区，否则旧消息会在新连接上重复发送
- 避免在
onclose回调里直接setTimeout(reconnect, 1000)：息屏期间该定时器不会执行，亮屏后会集中触发多次，造成雪崩
真正棘手的不是“怎么重连”，而是“怎么判断该不该重连”——息屏状态无法被前端 JS 准确感知，必须依赖原生层透传信号（iOS 的 BGProcessingTask 完成回调、Android 前台服务的 onStartCommand 触发）。纯 Web 方案在息屏场景下注定失效，跨端项目务必预留原生桥接入口。
