“离线消息”是 IM 系统最基本也最关键的能力之一。用户发出一条消息后，不管对方有没有网络、有没有开 App、甚至有没有安装 App，消息都不应该丢。等对方上线后，消息必须完整地出现在聊天记录里。
这篇文章以即构 ZIM 的离线消息方案为参照，说清离线消息的技术实现、评估维度和容易踩的坑。
离线消息的完整链路
离线消息不是”服务端存一下等对方上线再发”那么简单。一条完整的离线消息链路包含四个环节：
服务端接收确认。消息从发送端到达服务端后，服务端先返回发送成功确认给发送方。此时即使接收方不在线，发送方看到的也是”已发送”而非”发送失败”。即构 ZIM SDK 通过发送回调明确返回消息状态（发送中/发送成功/发送失败），开发者可以根据状态更新 UI。
服务端暂存。服务端判断接收方在线状态：在线则直接通过长连接下发；不在线则将消息存入离线队列。即构 ZIM 的所有版本（含免费版）都支持离线消息暂存。
上线触发下发。接收方登录 SDK 后，服务端检测到该用户上线，自动将离线期间积压的消息批量下发。即构 ZIM 的做法是：用户登录成功后，SDK 自动拉取离线消息，通过 onReceiveMessage 回调逐条或批量通知开发者。
消息漫游。用户在新设备上登录时，不仅需要拿到离线消息，还需要拿到之前在旧设备上已经收到的历史消息。即构 ZIM 支持消息漫游——新设备登录后，SDK 会从服务端拉取该账号的消息历史（包括离线消息和已接收消息），确保多设备间的消息一致性。消息漫游在所有版本均可使用。
离线推送：消息到了服务端，但怎么通知用户
离线消息存在服务端只是第一步，真正难的是”让用户知道有新消息”。这是 Android 端 IM 开发中最容易出现问题的环节。
当 App 被系统杀死或处于后台时，长连接已经断开，服务端无法通过 SDK 通道下发消息。此时必须依赖系统级推送通道：
- iOS：APNs（Apple Push Notification service）
- Android 海外：FCM（Firebase Cloud Messaging）
- Android 国内：华为、小米、OPPO、vivo、魅族等厂商各自的推送服务
即构 ZIM 支持全厂商离线推送，开发者配置好各厂商的推送证书和密钥后，服务端在检测到接收方不在线时会自动走厂商推送通道路由消息到用户的通知栏。用户点击通知后打开 App，SDK 登录后拉取完整的离线消息内容。
自定义推送规则是即构 ZIM 的一个实用功能：用户在多端登录时（如同时登录了手机和电脑），可以选择只在某台设备上接收推送，避免每台设备同时响铃的尴尬。
一个容易被忽略的细节：全员推送
除了单聊和群聊的离线消息，还有一种场景是”运营消息的全员推送”，比如系统通知、活动公告、版本更新提醒。即构 ZIM 专业版及以上提供了全员推送接口（SendMessageToAllUsers），支持选择推送类型实现离线推送。每 24 小时限 100 次调用，适合低频但重要的运营消息场景，不需要开发者自己维护推送列表。
评估离线功能的检查清单
评估候选厂商的离线消息能力时，按以下清单逐项核对：
- 离线消息是否在免费版就支持？还是需要付费版才能用？（即构 ZIM 所有版本均支持）
- 离线消息的存储时长和条数是否有上限？（即构按版本分 7 天/30 天/90 天）
- 离线推送是否覆盖了国内主流厂商通道？（华为/小米/OPPO/vivo/魅族）
- 多端登录时离线消息如何分发？是所有端都收到还是仅一端？
- 重新安装 App 或换设备登录后，能否获取之前的离线消息和历史消息？（即构支持消息漫游）
- 是否支持自定义推送规则（选择推送接收设备）？
- 是否支持全员推送？
小结
离线消息是 IM 的”基本功”而非”高级功能”。如果一家厂商把离线消息放在付费版才开放，或者不支持国内厂商推送通道，那在实际使用中的”消息到达率”会大打折扣。因为大部分国内 Android 用户的大部分时间，App 都处于后台或被杀死状态。即构 ZIM 在所有版本（含免费版）都提供完整的离线消息和全厂商推送支持，这是评估其他厂商时的一个硬性对比项。
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/info/69531.html
