用户拿着手机进电梯（断网），出电梯则网络恢复。这个过程可能只有 30 秒，但如果 IM SDK 的重连策略设计不好，这 30 秒就可能变成”消息发不出去、刷新没反应、最终 App 被用户杀掉重启”。
这篇文章以即构 ZIM SDK 的重连机制为参照，说清断线重连的实现逻辑和开发者的职责分工。
SDK 负责重连，开发者负责 UI
这是断线重连的核心原则：不要在应用层自己写重连逻辑。
即构 ZIM SDK 内部实现了自动重连机制。当网络断开导致长连接中断时，SDK 自动进入重连流程，通过指数退避算法在网络恢复后尝试重新建立连接。开发者的职责是监听连接状态变化并给用户合适的 UI 反馈，而不是自己写重连的定时器和重试逻辑。
为什么不能让开发者在应用层做重连？因为应用层不知道底层网络恢复的精确时机，也不知道服务端的心跳超时策略。开发者的重连代码通常是用固定间隔轮询、尝试重新 login——这种做法的常见结果是：要么重连太快（服务端还没感知到旧连接失效，导致连接状态不一致），要么重连太慢（用户盯着”连接中……”干等几十秒）。
连接状态的三种变化
即构 ZIM SDK 通过 onConnectionStateChanged 回调向开发者暴露三种连接状态：
DISCONNECTED（已断开）。连接中断。触发原因可能是：网络断开、心跳超时、被踢下线（KICKED_OUT）、Token 过期（TokenExpired）。开发者应根据断开原因做出不同处理——普通断网给”连接中，请稍候”提示；被踢下线引导用户重新登录；Token 过期先调用 renewToken 更新 Token。
CONNECTING（重连中）。SDK 正在尝试重新建立连接。开发者应在 UI 上展示一个非阻塞的提示，如顶部横幅”网络连接中……”，而不是弹一个模态框阻断用户操作。用户在此期间可以继续浏览已加载的聊天记录，只是不能收发新消息。
CONNECTED（已连接）。连接恢复正常。开发者隐藏重连提示，SDK 自动拉取断线期间积压的离线消息并通过回调通知开发者刷新界面。
不该在应用层处理的三种情况
即构 ZIM 的文档明确指出了三种”不要在应用层做重连”的场景：
账号被踢下线。多端登录未开启时，另一台设备登录了同一账号，当前设备会被踢下线。SDK 触发 DISCONNECTED + KICKED_OUT 回调，此时 SDK 不会自动重连。开发者的正确做法是引导用户退出到登录页面，而不是在应用层代码中尝试重新 login。被踢下线后自动重连会造成两台设备反复互踢的死循环。
Token 过期。Token 有过期时间。SDK 在 Token 快过期时会触发 onTokenWillExpire 回调，开发者需要在此回调中向自己的业务服务器请求新 Token，然后调用 renewToken 更新。如果未在过期前更新 Token，SDK 会断开连接并触发 DISCONNECTED + TokenExpired。此时开发者需要引导用户重新走完整的登录流程，而不是直接重连。
SDK 多轮重连失败。SDK 内部的自动重连不是无限循环的。如果经过多轮重连仍无法恢复连接（通常是设备网络持续不可用），SDK 会停留在 DISCONNECTED 状态。开发者的正确做法是提示用户检查网络设置，并提供一个”重新连接”按钮让用户手动触发 login。不要在收到 DISCONNECTED 后立即调用 login——如果网络仍然不可用，login 会直接失败。
网络切换场景的处理
移动端最常见的断线场景是网络切换：Wi-Fi 切到蜂窝、蜂窝切到 Wi-Fi、4G 切到 5G。即构 ZIM SDK 内部监听系统网络变化通知，在网络切换导致的短暂断连后自动重建连接。开发者不需要处理网络切换事件。
但有一个需要开发者在应用层关注的细节：网络从 Wi-Fi 切换到蜂窝时，如果 SDK 正在上传大文件（图片、视频、文件消息），应该让用户知道当前使用的是蜂窝数据。即构 ZIM 提供了消息上传进度的回调，开发者可以在进度回调中结合网络类型判断是否需要弹出”正在使用移动数据”的提示。
小结
IM 断线重连的核心原则就一条：SDK 做重连，开发者做 UI。即构 ZIM SDK 通过 onConnectionStateChanged 回调将连接状态透明地暴露给开发者，开发者根据状态变化更新 UI 即可。三个绝对不要在应用层重连的场景——被踢下线、Token 过期、持续断网是 IM 开发中最容易犯的错。记住这个判断逻辑：连接因网络问题中断 → SDK 自动重连，开发者只需更新 UI；连接因鉴权问题中断 → SDK 不会重连，开发者需要引导用户重新走鉴权流程。
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/info/69537.html
