不推荐直接裸用原生 WebSocket——Android后台可能杀线程致断连无通知，iOS后台不触发onmessage，且无重连与心跳机制；应封装带状态管理、指数退避重连、心跳保活、前后台同步及消息兜底的连接层。
React Native 里用原生 WebSocket 实现实时通讯，不推荐直接裸用——它在 Android 上会因进程休眠断连、iOS 后台不触发 onmessage、且没有重连和心跳保活机制。真正能落地的方案，是封装一层带状态管理与自动恢复的连接层。
为什么不能直接 new WebSocket(...) 就完事
裸 WebSocket 在 RN 中有三个硬伤：
- Android 应用切后台后，系统可能直接 kill 掉 JS 线程，
onclose不一定触发，也收不到服务端踢下线通知 - iOS 后台时
WebSocket连接虽保持，但onmessage回调不会执行，消息积压到前台才批量吐出，体验卡顿 - 网络抖动（比如地铁进隧道）导致短暂断连时，原生 API 不自动重试，需手动监听
onclose并setTimeout重连，容易陷入无限重连或漏重连
用 react-native-websocket 还是自己封装
react-native-websocket 是个过时库，最后更新在 2019 年，不兼容 RN 0.64+ 的 Hermes 引擎，且内部没做心跳检测；更稳妥的做法是基于原生 WebSocket 自己写一个轻量连接管理器，核心只做四件事：
- 连接建立后启动定时
ping（发{"type":"ping"}），服务端必须回{"type":"pong"} -
onclose触发时，按指数退避（1s → 2s → 4s → 8s）尝试重连，最大重试 5 次后进入 manual-reconnect 状态 - 所有
send()调用前检查readyState === WebSocket.OPEN，否则缓存到队列，等重连成功后 flush - 暴露
useWebSocketHook，让组件可订阅status（connecting / open / closing / closed）和message
如何处理前后台切换导致的消息丢失
RN 没有可靠的“后台消息通道”，所以不能依赖 WebSocket 在后台收消息。正确做法是：
- App 进入后台时（监听
AppState.addEventListener('change', ...)），主动调用websocket.close()，并清空本地未确认消息队列 - App 切回前台时，不立即重连，而是先发一次 HTTP 请求到你的信令服务（如
/api/v1/session/last-seq），获取服务端最新消息序列号 - 重连成功后，立刻发
{"type":"sync","seq":12345}，服务端只推送该 seq 之后的增量消息 - 对关键业务消息（如支付结果、客服响应），服务端必须落库 + 支持按 client_id 查询历史，前端主动拉取兜底
发送二进制数据（如图片 base64 或 protobuf）要注意什么
原生 WebSocket 的 send() 方法对二进制支持不一致：iOS 只接受 ArrayBuffer，Android 部分版本要求 Blob；而 base64 字符串一律要转成 Uint8Array 再封装：
const base64ToUint8Array = (b64) => {
const raw = atob(b64);
const array = new Uint8Array(raw.length);
for (let i = 0; i < raw.length; i++) {
array[i] = raw.charCodeAt(i);
}
return array;
};
// 发送前确保 ws.readyState === WebSocket.OPEN
if (ws.readyState === WebSocket.OPEN) {
ws.send(base64ToUint8Array(imageBase64));
}
更稳妥的是统一走 JSON 文本协议，把二进制转成 base64 字符串再 send，服务端解码——虽然体积增约 33%，但省去平台兼容判断，适合中小项目。
WebSocket 在 RN 里不是“连上就完事”的玩具，它的生命周期必须和服务端 session、App 前后台、用户登录态三者对齐；最容易被忽略的，是把重连逻辑写死在组件里——应该抽成全局单例，并和 Redux / Zustand 的 store 联动，否则多个页面同时监听会导致重复连接或状态错乱。
