im即时通讯开发：移动端需要面对的问题

统一介绍下一个IM APP的方方面面，包括技术选型（包括通讯方式，网络连接方式，协议选择）和常见问题。

P2P还是服务器中转？

IM通讯方式无非两种选择：设备直连(P2P)和通过服务器中转。

1P2P方式

P2P多见于局域网内聊天工具，典型的应用有:飞鸽传书、天网Maze(你懂的)等。这类软件在启动后一般做两件事情：

    进行UDP广播:发送自己信息和接受同局域网内其他端信息；

    开启TCP监听:等待其他端进行连接。

详细的流程可以参考飞鸽传书源码。但是这种方式在有种种限制和不便:一方面它只适合在线的点对点消息传输，对离线，群组等业务支持不够。另一方面由于 NAT 的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下无法建立连接。

2服务器中转方式

几乎所有互联网IM产品都采用服务器中转这种方式进行消息传输，相对于P2P的方式，它有如下的优点:

    能够支持更多P2P无法支持或支持不好的业务，如离线消息，群组，聊天室服务；

    方便业务逻辑的拓展和新旧版本的兼容。

当然它也有自己的问题:服务器架构复杂，并发要求高。

该选择什么样的网络通讯技术？

IM主流网络通讯技术有两种:

    基于TCP的长连接；

    基于HTTP短连接PULL的方式。

后者常见于WEB IM系统(当然现在很多WEB IM都是基于WebSocket实现)，它的优点是实现简单，方便开发上手，问题是流量大，服务器负载较大，消息及时性无法很好地保证，对大规模的用户量支持不够，比较适合小型的IM系统,如小网站的客户系统。

基于TCP长连接则能够更好地支持大批量用户，问题是客户端和服务器的实现比较复杂。当然也还有一些变种，如下行使用MQTT进行服务器通知/消息的下发，上行使用HTTP短连接进行指令和消息的上传。这种方式能够保证下行消息/指令的及时性，但