接收消息
您可通过设置消息监听器拦截 SDK 接收的消息,并进行相应的业务操作。
监听消息接收
设置消息接收监听
您可以通过 addReceiveMessageDelegate 方法设置多个消息接收代理。所有接收到的消息都会在此 RCIMClientReceiveMessageDelegate 协议的代理方法中回调。
- 您需要将代理设置的时机放在调用 IMLib SDK 连接接口之前,初始化 IMLib SDK 之后,保证与融云服务端建立 IM 连接后的第一时间获取到离线的消息。
- 建议将代理设置给单例对象,保证整个 App 生命周期内代理的设置都是有效的。
[[RCCoreClient sharedCoreClient] addReceiveMessageDelegate:self];
实现消息接收代理方法
RCIMClientReceiveMessageDelegate 可用于处理接收实时消息或离线消息。该协议提供两个代理方法,监听消息处理只需要在其中一个代理方法内实现。SDK 会通过此方法接收包含单聊、群聊、聊天室、系统类型的所有消息。
方法一提供了还剩余的未接收的消息数 nLeft
参数。您可以根据 nLeft
的数量来优化您的 App 体验和性能,比如收到大量消息时等待 nLeft
为 0 再刷新 UI。
/*!
接收消息的回调方法
@param message 当前接收到的消息
@param nLeft 还剩余的未接收的消息数,left≥0
@param object 消息监听设置的 key 值
*/
- (void)onReceived:(RCMessage *)message left:(int)nLeft object:(id)object;
方法二额外暴露了 offline
和 hasPackage
参数。您可以根据 nLeft
、offline
、hasPackage
选择合适的时机刷新 UI。
/**
接收消息的回调方法
@param message 当前接收到的消息
@param nLeft 还剩余的未接收的消息数,left≥0
@param object 消息监听设置的 key 值
@param offline 是否是离线消息
@param hasPackage SDK 拉取服务器的消息以包(package)的形式批量拉取,有 package 存在就意味着远端服务器还有消息尚未被 SDK
拉取
*/
- (void)onReceived:(RCMessage *)message
left:(int)nLeft
object:(id)object
offline:(BOOL)offline
hasPackage:(BOOL)hasPackage;
参数 | 类型 | 说明 |
---|---|---|
message | RCMessage | 接收的消息对象。 |
nLeft | int | 当客户端连接成功后,服务端会将所有离线消息?以消息包(Package)的形式下发给客户端,每个 Package 中最多含 200 条消息。客户端会解析 Package 中的消息,逐条上抛并通知应用。nLeft 为当前正在解析的消息包(Package)中还剩余的消息条数。 |
offline | boolean | 当前消息是否离线消息。 |
hasPackage | boolean | 是否在服务端还存在未下发的消息包(Package)。 |
同时满足以下条件,表示离线消息已收取完毕:
hasPackage
为NO
:表示当前正在解析最后一包消息。nLeft
为 0:表示最后一个消息包中最后一条消息已接收完毕。
离线消息接收完成回调
从 5.2.3 版本开始,每次连接成功后,离线消息收取完毕时会触发 RCIMClientReceiveMessageDelegate 中的以下回调方法。如果没有离线消息,连接成功后会立即触发。
/*!
离线消息接收完成
*/
- (void)onOfflineMessageSyncCompleted;
SDK 支持移除监听器。为了避免内存泄露,请在不需要监听时将监听器移除。
[[RCCoreClient sharedCoreClient] removeReceiveMessageDelegate:self];
消息接收状态
receivedStatusInfo
属性说明:
状态 | 描述 |
---|---|
isRead | 是否已读。当前设备或其他设备上已读后,该状态值会变为已读。如果消息在当前设备上被阅读,该状态会变为已读。SDK 5.6.8 版本开始,只要在其他设备上阅读过该消息,当前设备的该状态值会也变为已读。 |
isListened | 是否已被收听,仅用于语音消息。 |
isDownloaded | 是否已被下载,仅适用于媒体消息。 |
isRetrieved | 该消息是否已被同时在线或之前登录的其他设备接收。只要其他设备先收到该消息,该状态值都会变为已接收。 |
接收消息处理建议
- 如果接收消息量比较小,建议当
nLeft == 0
时刷新 UI,即消息是分批进行刷新。 - 如果接收消息量比较大,建议当
hasPackage == NO && nLeft == 0
(即所有的远端消息已经全部接收)时整体刷新一次。 - 如果接收消息量较大,还可以考虑使用 iOS 函数节流(throttle) 方式,即在一定时间段内,丢弃掉其它触发,就做一次执行。大致思路是接收大量消息的时候起定时器,固定时间刷新一次,等条件满足
hasPackage == NO && nLeft == 0
时关闭定时器再刷新一次。
下面分按消息数量大小分两种情况讨论以上方案。
-
消息数量小:假设远端服务器有 200 条消息需要客户端接收,接收总过程耗时 0.1 秒。
- 方案 1:刷新 UI 次数为 200/200 = 1 次,即 0.1 秒钟之内刷新了 1 次。
- 方案 2:刷新 UI 次数为 1 次,不管多少消息只有全部刷新一次,即 0.1 秒之内刷新了 1 次。
- 方案 3:假设设置的是 0.1 秒固定刷新,那么次数为 0.1/0.1 + 1 = 2 次,即 0.1 秒之内刷新了 2 次。
-
消息数量大:假设远端服务器有 1 万条消息需要客户端接收,接收总过程耗时 1 秒。
- 方案 1:刷新 UI 次数为 10000/200 = 50 次,即 1 秒钟之内刷新了 50 次
- 方案 2:刷新 UI 次数为 1 次,不管多少消息只有全部刷新一次,即 1 秒之内刷新了 1 次
- 方案 3:假设设置的是 0.5 秒固定刷新,那么次数为 1/0.5 + 1 = 3 次,即 1 秒之内刷新了 3 次。
整体来说方案 1、2 的开发难度小,方案 3 的开发难度大。您需要根据接收消息数量大小的实际情况,选择合适的方案,上述方案都需要您自行实现。
禁用消息排重机制
消息排重机制会在 SDK 接收单聊、群聊、系统消息、聊天室时自动去除内容重复消息。当 App 本地存在大量消息,SDK 默认的排重机制可能会因性能问题导致收消息卡顿。因此在接收消息发生卡顿问题时,可尝试关闭 SDK 的排重机制。