ios xmpp和mysql的联系_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收到的消息也要进行消息的排重，发送的消息要注意，要先入本地库，但是此条消息不一定发送成功，这里要加一个字段标记(例如发图片或语音消息比较慢时)。