iOS XMPP 使用过程中的优化和IM数据库会话刷新需注意的逻辑

这里就不介绍xmppframework在iOS中如何使用和如何封装了，其实不难，就是新建一个类专门管理xmpp相关的事件和接收回调就ok了，这篇文章说说基本的工作完成后，一些可以优化的细节问题还有会话刷新的逻辑的一些思考。

一、XMPP 在聊天室很多时joinRoom过程中出现卡顿的问题

因为基本聊天逻辑都已经实现了，回过头来就要处理之前埋下的坑。发现了一个问题，下面是两种操作流程出现的不同情况：
第一种操作流程：
1、切换到互动模块时，XMPP开始连接，开始join这个账号所有的room；
2、点击具体某个会话，会使用AFN去发起一个请求（为何发请求下面会解释），只有在1过程结束之后，这个请求的回调才会返回数据。
另一种操作流程：
1、从通知栏点击某个会话的通知消息进入具体某个会话，这时候会使用AFN发起一个请求；
2、xmpp joinroom的操作会在1过程结束之后。
这时候就产生了一个疑问，这两个为什么会影响呢，答案肯定是奔着队列或线程那里想去，因为上面的现象符合先进先出的原则：
点进AFN的源代码一步步进去查看，发现了一个问题

 dispatch_async(self.completionQueue ?: dispatch_get_main_queue(), ^{
                failure(nil, serializationError);
            });

如果self.completionQueue 我们没设置的话，默认使用dispatch_get_main_queue()，难道XMPP也是默认使用了main_queue,但之前看了一个文章（http://blog.csdn.net/a8221379/article/details/37767325），在初始化的时候使用了自己创建的一个串行队列，然后通过断点调试发现了一个问题，

image.png

初始化房间的时候跳到的main_queue了，这就有问题了，所以全局搜下了这个方法 initWithRoomStorage:用了这个初始化方法地方的全部替换成下面的方法：

// workingQueue 一个自建的串行队列
 XMPPRoom *room = [[XMPPRoom alloc] initWithRoomStorage:self jid:roomJID dispatchQueue:workingQueue];
 [room addDelegate:self delegateQueue:workingQueue];

断点结果如下：

image.png

这个坑就差不多这么解决了

二、通过XMPP的- (void)xmppStream:(XMPPStream *)sender didReceiveError:(DDXMLElement *)error来做IM的账号异地异机登录警告

- (void)xmppStream:(XMPPStream *)sender didReceiveError:(DDXMLElement *)error
{
    NSLog(@"Error receive: %@",error);
    
    NSString *elementName = [error name];
    
    if ([elementName isEqualToString:@"stream:error"] || [elementName isEqualToString:@"error"])
    {
        NSXMLElement *conflict = [error elementForName:@"conflict" xmlns:@"urn:ietf:params:xml:ns:xmpp-streams"];
        if (conflict)
        {
            [[NSNotificationCenter defaultCenter] postNotificationName:UserConflictNotification object:self];
        }
    }
}

这里要注意，想要触发这个回调我们需要在设置xmpp的jid的时候只要resource一样，那么服务端在收到相同的resource登录的时候就会发消息触发这个回调，

 xmppStream.myJID = [XMPPJID jidWithString:[NSString stringWithFormat:@"%@@%@",userid,domain] resource:@"这里是你要设置的resource"];// @"[iOS]iPhone"
    xmppStream.hostName = domain;

三、接下来谈谈IM的会话加载逻辑

为什么要考虑这个逻辑，别人发一条消息我们收到一条消息展示不就好了，骚年，想的太简单了～这里不详讲什么3次握手，协议，还有消息的从用户A到用户B的几个过程中哪个步骤会出现问题，想了解的可以通过这个网站（http://www.52im.net）看看，网站版主很热情，有什么IM的问题都可以发帖提问，很多人都会人情解答

这里我就讲讲我在使用过程中出现和解决问题的方法思路，有什么更好的方法也希望大家指教，毕竟小弟搬砖水平。

1、首先说说数据存储，我这边使用了coredata，也看到网上很多人使用FMDB来封装的，都有坏处好处，这里也没都使用了，不好说优劣，不过最近看到微信开源了他们的移动端数据库WCDB（http://www.52im.net/thread-932-1-1.html），看着有点眼馋，感兴趣可以看看，这里主要是写好一个逻辑，就是数据库数据发生变化，要能够实时通知UI刷新，但这个不是我要讨论的重点；
2、我们重点是：在聊天过程中，怎么做到移动端的消息不重不丢，这里就要把XMPP和Http结合起来使用，通过消息的ID来排重和保证不丢，这里就重点说说这一块的逻辑；

(1)、打开会话先加载本地的20条数据展示（无则空）
(2)、打开会话，调用接口获取本会话最新的20条数据，筛选对比插入数据库(排重)，更新UI
(3)、下拉查看当前界面数据的之前数据，（若本地无规定的连续性ID或者特定的preMessageID就进行网络请求，否则不显示）
(4)、通过preMessageID（本条消息的上一条消息的Id）或者定义消息ID的连续性，通过连续性规则（确保消息不会丢失）
(5)、IM消息直接插入数据库(通过http取消息不通过时间，通过具体的消息id)

下面说说上面几点的考虑：
(1)是为了用户体验，如果之前此会话本地已经有了一些数据，可以先展示出来，不至于聊过还是一片空白；
(2)是通过http接口请求直接获取会话的最新几十条数据来展示，为接下来的逻辑做好铺垫；
(3)(4)下拉获取历史数据，通过消息id（messageId）和消息的前一条消息id（preMessageId）两个字段对比决定是否网络请求历史数据，保证消息不丢；
(5)通过XMPP收发的消息直接存入数据库，这里要注意，通过XMPP收到的消息也要进行消息的排重，发送的消息要注意，要先入本地库，但是此条消息不一定发送成功，这里要加一个字段标记（例如发图片或语音消息比较慢时）。