React Native如何实现应用被杀死/关闭时保持socket连接不中断

不管是iOS还是安卓系统，用户主动杀死应用后，系统会直接强制回收应用所属的所有进程、断开所有进程持有的网络连接，不存在合规、稳定的方案能让App在被杀后继续维持自己的Socket长连接。你看到的WhatsApp等应用杀进程后还能收消息，根本不是靠保活Socket实现的，走的是系统级推送通道，别在Socket保活上浪费时间。

安卓端 #

• 海外场景直接接入FCM推送，这是谷歌官方的系统级推送服务，进程常驻在系统服务层，和你的App是否存活无关，哪怕App被杀死，FCM也能收到服务端下发的消息、弹出系统通知。
• 国内场景必须逐个接入华为、小米、OPPO、vivo、魅族等主流手机厂商的官方推送SDK，这些推送服务是集成在厂商系统里的，同样不依赖你的App进程存活，是目前国内安卓环境下唯一能稳定做到杀进程后收消息的方案。
• 别尝试所谓的进程保活方案：包括双进程守护、前台服务藏通知、JobScheduler轮询拉活之类的野路子，在安卓12及以上版本基本都会被系统直接拦截，还会触发应用商店的流氓软件检测，根本没法大规模商用。如果只需要做非实时的离线消息同步，可以用WorkManager配置加急任务，在系统分配的时间窗口内短暂拉起App拉取消息，但触发时机完全由系统调度，做不到实时性。

iOS端 #

• iOS端系统权限管控极严，App被杀后没有任何执行代码、维持网络连接的权限，唯一合规的收消息通道就是苹果官方的APNs推送，没有其他选项。
• APNs支持两类推送：普通通知推送直接在系统栏弹出提醒；静默推送可以在收到消息时短暂拉起App进程，做消息本地存储、角标更新这类预处理，但静默推送有严格的频次限制，不能用来做高频实时消息传输。

你完全不需要让Socket在App被杀后常驻，只要做两套消息通道的切换就能达到和WhatsApp一致的体验：

• 当App处于前台、或者切后台未被杀死时，保持你原有的WebSocket长连接，用长连接收消息保证低延迟；
• 服务端检测到设备的长连接断开时，自动将后续新消息通过对应设备的系统推送通道下发，用户点击推送通知拉起App后，再通过长连接拉取离线期间的全量消息，和本地数据做对齐即可，用户感知不到通道切换的差异。
• 注意推送载荷不要传输敏感的消息正文，只带消息ID、发送人ID这类非敏感标识即可，等App拉起后再凭标识拉取完整消息内容，避免隐私泄露。

内容的提问来源于stack exchange，提问作者Javid A.