移动IM开发技术选型(包括通讯方式, 网络连接方式, 协议选择) 和常见问题汇总。
1.通讯方式选择
IM 通讯方式无非两种选择: 设备直连 (P2P) 和通过服务器中转。
1.1 P2P
P2P 多见于局域网内聊天工具，典型的应用有: 飞鸽传书，飞秋等。这类软件在启动后一般做两件事情
进行 UDP 广播: 发送自己信息和接受同局域网内其他端信息开启 TCP 监听: 等待其他端进行连接详细的流程可以参考 飞鸽传书源码。但是这种方式有各种限制和不便: 一方面它只适合在线的点对点消息传输，对离线，群组等业务支持不够。另一方面由于 NAT 的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称 NAT) 下无法建立连接。
1.2 服务器中转
几乎所有互联网 IM 产品都采用服务器中转这种方式进行消息传输，相对于 P2P 的方式，它有如下的优点:
能够支持更多 P2P 无法支持或支持不好的业务，如离线消息，群组，聊天室服务方便业务逻辑的拓展和新旧版本的兼容当然它也有自己的问题: 服务器架构复杂，并发要求高。
2.网络连接方式IM 主流网络连接方式有两种:
基于 TCP 的长连接基于 HTTP 短连接 PULL 的方式后者常见于 WEB IM 系统(当然现在很多 WEB IM 都是基于 WebSocket 实现)，它的优点是实现简单，方便开发上手，问题是流量大，服务器负载较大，消息及时性无法很好地保证，对大规模的用户量支持不够，比较适合小型的 IM 系统, 如小网站的客户系统。
基于 TCP 长连接则能够更好地支持大批量用户，问题是客户端和服务器的实现比较复杂。当然也还有一些变种，如下行使用 MQTT 进行服务器通知 / 消息的下发，上行使用 HTTP 短连接进行指令和消息的上传。这种方式能够保证下行消息 / 指令的及时性，但是在弱网络下上行慢的问题还是比较严重。早期的来往就是基于这种方式。
3.协议选择IM 协议选择原则一般是: 易于拓展，方便覆盖各种业务逻辑，同时又比较节约流量。后一点的需求在移动端 IM 上尤其重要。
常见的协议有:
XMPPSIPMQTT私有协议XMPP 协议的优点在于: 协议开源，可拓展性强，在各个端 (包括服务器) 有各种语言的实现，开发者接入方便。但是缺点也是不少: XML 有太多冗余信息，流量大，实际使用时有大量天坑。
SIP 协议多用于 VOIP 相关的模块，是一种文本协议，由于我并没有实际用过，所以不做评论，但从它是文本协议这一点几乎可以断定它的流量不会小。
MQTT 的优点是协议简单，流量少，但是它并不是一个专门为 IM 设计的协议，多使用于推送。
而市面上几乎所有主流 IM APP 都是是使用私有协议，一个被良好设计的私有协议一般有如下优点: 高效，节约流量(一般使用二进制协议)，安全性高，难以破解。缺点则是在开发初期没有现有样列可以参考，对于设计者的要求比较高。
一个好的协议需要满足如下条件: 高效，简洁，可读性好，节约流量，易于拓展，同时又能够匹配当前团队的技术堆栈。基于如上原则，我们可以推出: 如果团队小，团队技术在 IM 上积累不够可以考虑使用 XMPP 或者 MQTT+HTTP 短连接的实现。反之可以考虑自己设计和实现私有协议。
4.私有协议的设计4.1序列化选择
移动互联网相对于有线网络最大特点是: 带宽低，延迟高，丢包率高和稳定性差，流量费用高。所以在私有协议的序列化上一般使用二进制协议，而不是文本协议。常见的二进制序列化库有 protobuf 和MessagePack，当然你也可以自己实现自己的二进制协议序列化和反序列的过程，比如蘑菇街的TeamTalk。但是前面二者无论是可拓展性还是可读性都完爆 TeamTalk(TeamTalk 连 Variant 都不支持，一个 int 传输时固定占用 4 个字节)，所以大部分情况下还是不推荐自己去实现二进制协议的序列化和反序列化过程。
4.2 协议格式设计
基于 TCP 的应用层协议一般都分为包头和包体(如 HTTP)，IM 协议也不例外。包头一般用于表示每个请求 / 反馈的公共部分，如包长，请求类型，返回码等。 而包头则填充不同请求 / 反馈对应的信息。
一个最简单的包头可以定义为
struct PackHeader
{
int32_t length_; // 包长度
int32_t serial_; // 包序列号
int32_t command_; // 包请求类型
int32_t code_; // 返回码
};
以心跳包为例，假设当前的 serial 为 1，心跳包的 command 为 10，那么使用 MessagePack 做序列化时: length=4，serial=1，command=10，code=0，每个字段各占一个字节，包体为空，仅需要 4 个字节。
当然这是最简单的一个例子，面对真正的业务逻辑时，包体里面会需要塞入更多地信息，这个需要开发根据自己的业务逻辑总结公共部分, 如为了兼容加入的协议版本号, 为了负载均衡加入的模块 id 等。
5.其他问题上面就是一个 IM 系统大致的选型过程: 通讯方式，连接方式，协议选择，协议设计。但是实际开发过程中还有大量的问题需要处理。
5.1协议加密
为了保证协议不容易被破解，市面上几乎所有主流 IM 都会对协议进行加密传输。常见的流程和 HTTPS 加密相似: 建立连接后，客户端和服务器进行进行协商，最终客户端获得一个当前 Session 秘钥，后续的数据传输都通过这个秘钥进行加解密。一般出于效率的考虑都会采用流式加密，如 RC4。而前期协商过程则推荐使用 RSA 等非对称加密以增加破解难度。
5.2快速连接(登录)
对 iOS APP 而言，因为没有真后台的存在，APP 每次启动基本都需要一次重连登录(短时间内切换除外)，所以如何快速重连重登就非常重要。常见的优化思路如下:
本地缓存服务器 IP 并定期刷新。移动网络调优可以参考《iOS 移动网络调优那些事》。合并部分请求。如加密和登录操作可以合并为同一个操作，这样就可以减少一次不必要的网络请求来回的时间。简化登录后的同步请求，部分同步请求可以推迟到 UI 操作时进行，如群成员信息刷新。5.3连接保持
一般 APP 实现连接保持的方式无非是采用应用层的心跳，通过心跳包的超时和其他条件 (网络切换) 来执行重连操作。那么问题来了: 为什么要使用应用层心跳和如何设计应用层心跳。
众所周知 TCP 协议是有 KEEPALIVE 这个设置选项，设置为 KEEPALIVE 后，客户端每隔 N 秒 (默认是 7200s) 会向服务器发送一个发送心跳包。但实际操作中我们更多的时是使用应用层心跳。原因如下:
KEEPALIVE 对服务器负载压力比较大(服务器大大是这么说的…)socks 代理对 KEEPALIVE 并不支持部分复杂情况下 KEEPALIVE 会失效，如路由器挂掉，网线 (移动端没有网线…) 直接被拔除移动端在实际操作时为了节约流量和电量一般会在心跳包上做一些小优化
精简心跳包，保证一个心跳包大小在 10 字节之内心跳包只在空闲时发送根据 APP 前后台状态调整心跳包间隔 (主要是安卓)5.4消息可达
在移动网络下，丢包，网络重连等情况非常之多，为了保证消息的可达，一般需要做消息回执和重发机制。参考易信，每条消息会最多会有 3 次重发，超时时间为 15 秒，同时在发送之前会检测当前连接状态，如果当前连接并没有正确建立，缓存消息且定时检查(每隔 2 秒检查一次，检查 15 次)。所以一条消息在最差的情况下会有 2 分钟左右的重试时间，以保证消息的可达。
因为重发的存在，接受端偶尔会收到重复消息，这种情况下就需要接收端进行去重。通用的做法是每条消息都带上自己唯一的 message id(一般是 uuid)。
5.5文件上传优化
IM 消息 (包括 SNS 模块) 内包含大量的文件上传的需求，如何优化文件的上传就成了一个比较大的主题。常见有下面这些优化思路:
将上传流程提前: 音频提供边录边传。朋友圈的图片进行预上传，选择图片后用户一般会进行文本输入，在这段时间内后台就可以默默将选好的图片进行上传。提供闪电上传的方式: 服务器根据 MD5 进行文件去重。优化和上传服务器的连接(参考快速连接)，提供连接重用的功能。文件分块上传: 因为移动网络丢包严重，将文件分块上传可以使得一个分组包含合理数量的 TCP 包，使得重试概率下降，重试代价变小，更容易上传到服务器。在分包的前提下支持上传的 pipeline ，避免不必要的网络等待时间。支持断点续传