移动端IM实现方案
-
第三方平台
比如环信，融云，leancloud，容联云、网易云信等等。直接使用sdk就可以实现了，最简单最直接，而且稳定性已经不错了，连UI界面都带有了，可以自行修改，缺点是要收费。
-
spark+smack+openfire
安卓使用asmack，测试使用spark，服务器使用openfire。
asmack可以说是smack的Android平台的支持版提供xmpp协议的实现，就是一些api。
spark就是一个可以用来在pc相互同信的客户端。
openfire部署也比较简单，next，next就差不多了。
-
使用第三方推送的sdk
利用推送的及时性来做im也是可以的
-
socket长连接
因为网络优化和稳定性原因，达不到商用级别
-
基于xmpp自己实现
通常IM采取的协议有xmpp、mqtt、protobuf等数据通信私有协议。
XMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的发展性。
XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。
命令要么用2进制的形式发送（比如QQ），要么用纯文本指令加空格加参数加换行符的方式发送（比如MSN）。而XMPP传输的即时通讯指令的逻辑与以往相仿，只是协议的形式变成了XML格式的纯文本。
移动端IM客户端的坑
-
流量
采取哪种协议、图片缩略图、附件的压缩三点决定了流量的大小。
-
耗电
(1)流量越小，耗电越低。
(2)心跳策略，减少心跳次数，耗电量就会降低。 -
心跳时长：
wifi，2G，3G，4G，移动、电信、联通,不同网络，不同运行商，NAT失效时间不一样，因此心跳的时间也就不一样。
-
网络连接：
cmnet和cmwap下连接处理机制。
-
网络不稳定：
移动端最大的特点就是网络不稳定，在不稳定的网络状态下，如何保证消息以最快的速度到达？如何避免重联风暴？这些既需要从整体架构考虑，也需要在移动端采取巧妙的策略加以避免。
移动端IM架构设计的坑
-
连接器的设计
连接器主要用来管理客户端的长连接。目前最好的连接器单台8G8核的服务器可以做到70万—100万的连接，而某些开发者只能做到4000左右的连接，相差好几个数量级。这里的奥妙在哪里呢？
-
中间件的设计
是否采用通讯中间件？通讯中间件的好处有哪些？如果不采用中间件，连接器和逻辑服务器的连接关系如何管理呢？
-
逻辑服务器
逻辑服务器通常简单一点，主要是根据业务逻辑进行最小粒度的划分即可。但是即便如此，还是有很多的开发者把看似相关实则不相关的逻辑放在一起，如把鉴权和message服务器放在一起。
-
状态服务器
状态服务器主要管理用户在线、离线的相关状态，需要采取中心节点的方案，否则状态就会不同步。这里主要需要考虑状态服务器所对应的数据存储机制，如何进行写操作，如何进行读操作？以便最大的提高状态服务器的处理能力和响应速度。
-
数据库的设计
数据库的设计是最难的，也是做大的瓶颈。因为无论对于sql（关系型）数据库还是nosql（非关系型）数据库，都有读写处理的极限，那就需要考虑数据库如何分区（根据什么原则、什么操作、哪些用户访问哪个节点上的数据库）。同时又需要考虑每个原子操作（如登陆）需要读哪些库，写哪些库。只有这些指标明确了，你才能在假设有100万并发用户，100万条并发消息的情况下，准确评估服务端需要多少台服务器，如何部署。
-
其他
还有设备推送的处理，何种机制能够保证不丢消息，离线消息如何处理，等等。这些都是必备而又非常复杂的功能点和技术要求，都需要采取正确的架构和策略才能实现。