问题现象
WebSocket长连接在弱网环境下会面临一系列挑战，这些问题会直接影响应用的稳定性和用户体验。以下是主要问题：
- 连接稳定性问题：频繁断开重连；连接建立耗时过长、握手阶段失败率高。
- 数据传输问题：消息丢失或重复、消息顺序错乱、消息延迟显著增加。
- 心跳机制失效问题：误判存活连接为断开、心跳包丢失导致不必要的重连、心跳检测延迟增加。
- 资源消耗问题：设备电量消耗过快、内存占用持续增长、CPU使用率异常升高。
- 业务逻辑问题：消息状态不一致（如已读/未读状态错误）、业务操作重复执行、会话状态丢失。
- 用户体验问题：界面频繁显示"连接中"、消息发送失败率高、实时性无法保证。
背景知识
在弱网环境下优化WebSocket连接的重连效率和心跳机制是确保应用稳定性的关键。以下是一些有效的优化策略：
- 重连机制优化：
指数退避算法：初始重连延迟较短(如1秒)；每次重连失败后延迟时间指数增长(2s, 4s, 8s...)；设置最大延迟上限(如30秒)。
动态重连策略：根据网络质量动态调整重连间隔：检测到网络恢复时立即尝试重连；记录历史连接成功率调整策略。
渐进式重连：先尝试轻量级连接测试；成功后再建立完整WebSocket连接。
- 心跳机制优化：
自适应心跳间隔：初始心跳间隔(如25秒)；根据网络延迟动态调整(网络差时延长至60秒+)；使用TCP keepalive作为底层保障。
双重心跳检测：客户端主动发送ping；服务端定期发送pong；双向检测连接活性。
心跳超时策略：设置合理超时时间(如3倍心跳间隔)；连续多次超时再判定为断开。
解决方案
弱网通常意味着网络存在高延迟、高丢包率、连接不稳定等情况，这种情况下，需要保持WebSocket连接的可靠性，避免频繁断开，或者在断开后能够快速恢复。
websocket-manager.ets中主要实现为动态重连策略、指数退避算法、路由心跳：
- 动态重连策略：通过emitter获取监听到的网络状态，当网络状态为netAvailable时立即进行WebSocket连接。
- 指数退避算法：设置最大重连次数为5次，根据指数退避算法设置计时器时间，初始计时器为1秒。计时器等待时间结束后重新连接。
- 自适应心跳间隔：应用每隔25S进行一次心跳发送，当监听到服务端消息“pong”时网络连接正常，消息发送成功。
重连成功后还需恢复断连期间服务端已发送的消息，避免消息丢失。客户端和服务端需协商实现消息缓存与恢复机制：
- 每条消息携带唯一标志（如消息ID或时间戳）。
- 客户端记录已接收的最后一条消息的唯一标志，服务端缓存每个客户端连接过程中已发送的消息标志，并提供按标志重新请求的接口。
- 客户端重连成功后，携带最后接收的消息标志向服务端请求断连期间的消息。
- 客户端收到服务端返回的断连期间消息后进行正常处理。
常见FAQ
Q：WebSocket连接报错200常见原因有什么？
A：code=200，是常见错误，表示运行超时。可能为WebSocket请求头有字段配置的有误，不满足服务器要求，可以查看下是否参数配置缺失；也可能是WebSocket的客户端与服务端不在同一个局域网，导致运行超时。