移动端WebSocket需精细化管理：双向心跳（25–30秒）、页面隐藏时暂停或关闭连接、帧级埋点监控收发量与延迟、中低端设备降级为XHR polling，并用requestIdleCallback控节奏。
在移动端浏览器中使用 WebSocket，性能和电量消耗不是固定值，而是高度依赖连接管理方式、消息模式和设备状态。用得好能省电提效，用得随意反而比轮询更耗电。
连接稳定性直接影响电量
移动网络频繁切换（比如地铁里WiFi断开切4G），会导致WebSocket静默断连——页面没报错，但连接实际已失效。此时若未主动探测，客户端仍会持续发送心跳或等待响应，白白唤醒基带芯片。实测显示，一个未及时关闭的“假死连接”每分钟多耗电约0.3%～0.8%（基于Pixel 6与iPhone 13测试）。
- 必须实现双向心跳：不只是发ping，还要在规定时间内确认收到pong或应用层ack
- 心跳间隔建议25–30秒，略小于服务端idle_timeout（如Nginx设为30s，则客户端设28s）
- 监听visibilitychange事件，页面隐藏时暂停心跳、进入后台时主动close连接
消息收发节奏决定CPU与基带负载
高频小包（如每秒发10条
- 对非实时业务（如离线状态同步、日志上报），采用批量合并+延迟发送（如500ms窗口内攒批）
- 避免在requestAnimationFrame回调中高频send，防止主线程与网络调度互相拖慢
- 大消息（>16KB）考虑分片传输，并在服务端支持续传，减少单次重传开销
监控不能只看控制台，要埋点到帧级
浏览器Network面板看不到WebSocket帧内容，也无法统计真实收发字节数和延迟。不埋点就等于“盲开”，优化无从下手。
- 在onopen时记录performance.now()，计算握手耗时；每次send前用TextEncoder算字节数，onmessage中同样统计接收量
- 按业务类型打标（如"chat_msg"、"sync_state"），便于后续分析哪类消息最耗电
- 采样上报：5%随机采样，异步提交{type, size, delay, connId}等精简字段，避免主线程阻塞
低端机需主动降级策略
中低端Android设备（如内存≤3GB、CPU核心数≤4）对长连接更敏感。持续运行WebSocket可能引发ANR或被系统杀后台，尤其在锁屏后。
- 通过navigator.hardwareConcurrency判断设备能力，≤2时默认关闭WebSocket，降级为XHR polling（配合Service Worker缓存）
- 使用requestIdleCallback控制消息处理节奏，避免单次执行超16ms导致掉帧
- 页面hidden超过30秒，终止Worker中与WebSocket无关的预处理任务（如本地索引构建）
