“最淡的墨水胜过最强的记忆”
因为公司一直在赶项目，也有段时间没有更新过文章了。闲下来想了还是写点东西来做个总结（顺便当备忘录 = =）。
虽然现在用户的移动社交基本还处于 QQ、微信 的垄断时代，但 IM 功能现在已经逐渐成为应用的标配。下面会大致说下我自己觉得比较重要的地方以及后续文章的大纲。
IM 协议的选择
这一块儿我觉得是开发者在进行开发前要慎重考虑的问题。不过相关的内容其实网上已经有不少优质的文章，在这里我就提供几个链接不多做赘述。
《移动 IM 学习笔记》- Ruby客户端
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》- Segmentfault
首先说明下我们公司选择的协议是 XMPP （不然也不会有这篇及之后的文章 = =）。
理由很简单：
- 开源、免费，可以用于商用，公司可以省去一部分开支（排除了使用第三方 SDK ）
- 公司团队不大并且项目进度抓的时间紧（排除自己实现协议）
- XMPP 协议存在时间已经很长，网上的资料比较齐全
虽然我所在的公司最终决定使用 XMPP 协议（后面都简称 XMPP ），但依然不得不说在实际使用上有不少的坑要填。所以我提两点建议：
- 如果读者所在公司准备开发的 App 不是聊天密集型，并且公司有条件或者读者口才比较好能说服领导的话，建议还是选择第三方 SDK
- 公司团队技术相对成熟，准备开发的 App 也是聊天密集型的，建议使用私有协议
如果你决定听从我的建议，那么恭喜你不用入坑并且可以关掉窗口去查询对应的资料了，因为后面的内容都是基于使用 XMPP 展开的。
XMPP 的使用场景
大部分的协议在设计之初都会有一个预想的使用场景，然后开发人员根据这个预想的场景去制定一系列的规则。对于协议的使用者来说如果你的需求正好符合这个协议的预想场景，那么使用起来将会得心应手，反之就会处处掣肘。
那么对于 XMPP 协议来说，简单分为俩部分：单人聊天 和 多人聊天。
（具体代码在之后的文章中贴出，这篇文章只做讨论）
单人聊天
单人聊天的场景比较简单，在社交软件泛滥的今天可能连没有学习过 IT 的大叔大妈们都能列出个一二三。
下面我就列举部分XMPP 能够快速实现单人聊天的功能：
- 用户登录、注册
- 好友添加、删除及分组
- 个人名片（昵称、头像、住址等等）
- 好友状态检测及通知（在线、离线）
- 文件传输（照片、音频）
多人聊天
多人聊天相比起单人聊天就要复杂的多了，不过总的来说还是能归为俩种模式：会议模式 和 群组模式。
会议模式 和 群组模式 最大的区别在于人员的流动性
- 会议模式 下的 群 称之为 房间 更为恰当，用户作为使用者的角色并不会一直存在房间中，这与我们平常意义上的群组是不同的。典型的使用案例：YY 、直播聊天室。
- 群组模式 就不多做解释了，典型使用案例：QQ 群 、微信群聊
XMPP 就是根据 会议模式 的使用场景去设计的，所以如果读者的 App 是准备使用 XMPP 开发群组功能的话就要做好准备填坑了，当我们的总结写到开发群聊功能的时候也会举出一些我遇到的坑以及填坑的办法。
下面列举部分 XMPP 能够快速实现多人聊天的功能：
- 单人聊天的所有功能
- 单人聊天转多人聊天（需服务器支持）
- 聊天室创建、销毁
- 聊天室信息编辑
- 房客多级权限
- 房客管理（禁言、邀请、删除等）
- 房客状态变动通知（入群、离群、权限变更）
XMPP 服务器与客户端通信实质
XMPP 服务器与客户端通信的实质就是一串串 XML 代码块不断传递解析的过程。一串 XML 相当于日常开发中的 接口 + 请求参数（如下图）。
那么对于客户端的开发者来说你要做的事情就明显了：
- 去官网查询对应功能模块的标准
XML格式 - 按照标准格式组装
XML串发送给服务器 - 接受服务器返回结果并按格式解析
这一段的内容我觉得比较重要的原因是 iOS 端的 XMPPFrameWork 并没实现所有协议中的功能，在实际使用过程中我们需要自己去实现对应协议的内容（当然没有实现的功能并不算多）。但幸运的是 XMPPFrameWork 框架把 XML 组装和解析的方法封装的非常灵活，我们可以很轻松的去实现。
