不推荐直接裸用原生 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 在后台收消息。正确做法是:
使用 @ainative/react-sdk 为 React 应用添加 AI 聊天和积分。适用于 (1) 安装 @ainative/react-sdk,(2) 使用 useChat hook 实现聊天完成。
- 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
<p>更稳妥的是统一走 JSON 文本协议,把二进制转成 base64 字符串再 send,服务端解码——虽然体积增约 33%,但省去平台兼容判断,适合中小项目。</p>
<p>WebSocket 在 RN 里不是“连上就完事”的玩具,它的生命周期必须和服务端 session、App 前后台、用户登录态三者对齐;最容易被忽略的,是把重连逻辑写死在组件里——应该抽成全局单例,并和 Redux / Zustand 的 store 联动,否则多个页面同时监听会导致重复连接或状态错乱。</p>










