IM心跳机制
通常来说IM 一般有联众心跳机制 QoS keep alive
引入心跳机制的目的是保活， 服务器与客户端存在一个联系，
keep Alive
为了TCP或UDP通讯的socket保活而进行的定时向服务端发送keep alive包的机制
一般的keep alive 心跳作用至少有两种：
- 解决UDP或TCP 端口老化问题(UDP更短)
- 告诉服务器我还活着（极端情况下，当客户端因程序崩溃等情况而非常退出时，心跳就显得特别重要，尤其在使用UDP这样的“无连接”协议的情况下）。
QOS
消息应答机制，且无论是UDP协议还是TCP协议。应答机制通常是在消息接收者收到消息的同时，马上发送应答包，发送方只需根据这个应答包来决定对方是否真的是否“收到”消息，这就让丢包（当然丢包的情况有很多种可能，UDP协议自身的特殊性只是其中一种）的判定变的简单。
再来讲讲重传机制： 这个重传机制，跟你说的心跳是差不多的，但是用“心跳”可能容易跟Keep alive机制混淆，所以叫定时线程，可能更准确。它的工作原理是，定期检查已发送队列，当包的生存期已过，就表示这个包从未收到应答包，也就认为着它没有被接收方“收到”，那么自动触发重传机制。
当然，应答和重传机制在MobileIMSDK或者其它IM框架里，实际的实现都比我上面描述的要复杂和强大，我只是为了向你简单地描述原理而已。
优化重连机制：
针对心跳的优化：
- 精简心跳包
减少心跳次数
在聊天过程中，不需要发送心跳包，(一般采用定时器发送，这种会有大量的浪费)
在使用过程中， 心跳包是不需要的， 在空闲时间才开启心跳机制，(如何保证在空闲时间才会去开启心跳机制)重连冷却 在网络环境差的情况下， 会一直进行重连， 如果连接不上，会一直进行重连的，(死循环式连接)
可以采用 2 次方级重连， 第一次连接失败 2秒后重连，连接失败， 4 秒后重连 。。。。