客户端需要心跳的原因
对于客户端而言，使用 TCP 长连接来实现业务的最大驱动力在于：
在当前连接可用的情况下，每一次请求都只是简单的数据发送和接受，免去了 DNS 解析，
连接建立等时间，大大加快了请求的速度，同时也有利于接受服务器的实时消息。
但前提是连接可用。
NAT
大部分移动无线网络运营商都在链路一段时间没有数据通讯时，
会淘汰 NAT 表中的对应项，造成链路中断（NAT超时的更多描述见附录A）
NAT超时是影响TCP连接寿命的一个重要因素(尤其是国内)，
所以客户端自动测算NAT超时时间，来动态调整心跳间隔，是一个重要的优化点
为什么不用tcp的KeepAlive
KeepAlive 并不适用于检测双方存活的场景，
这种场景还得依赖于应用层的心跳。应用层心跳有着更大的灵活性，
可以控制检测时机，间隔和处理流程，甚至可以在心跳包上附带额外信息。
从这个角度而言，应用层的心跳的确是最佳实践。
什么是智能心跳？
智能心跳实际上就是动态的探测到最大的NAT超时时间，
然后选定合适的心跳间隔区间去发送心跳包，同时在网络状况发生变化的时候能够动态的
调整心跳间隔时间；如果心跳间隔不合适，例如心跳间隔过短，
那么可能导致频繁的唤醒手机发送心跳包，增加耗电，心跳间隔过长，
可能导致这条TCP连接已经无效但是无法及时的检测到，
只能等待下一个心跳包发送的时候才能感知到
alarm的对齐唤醒： 6.0时间对不上有延迟
jobservice 进程保活 为不是不支持 6.0杀的进程组，
保活是怎么做的
https://blog.csdn.net/xx326664162/article/details/51611625
https://blog.csdn.net/lhd201006/article/details/52702178
