共计 7445 个字符，预计需要花费 19 分钟才能阅读完成。
本文来自融云技术团队原创分享，原文发布于“融云全球互联网通信云”公众号，原题《IM 即时通讯之链路保活》，即时通讯网收录时有部分改动。
1、引言
众所周知，IM 即时通讯是一项对即时性要求非常高的技术，而保障消息即时到达的首要条件就是链路存活。那么在复杂的网络环境和国内安卓手机被深度定制化的条件下，如何保障链路存活呢？本文详解了融云安卓端 IM 产品在基于 TCP 协议实现链路保活方面的实践总结。
学习交流：
- 即时通讯 / 推送技术开发交流 5 群：215477170 [推荐]
- 移动端 IM 开发入门文章：《新手入门一篇就够：从零开发移动端 IM》
（本文同步发布于：http://www.52im.net/thread-27…）
2、相关文章
《为何基于 TCP 协议的移动端 IM 仍然需要心跳保活机制？》
《微信团队原创分享：Android 版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android 版微信后台保活实战分享(网络保活篇)》
《移动端 IM 实践：实现 Android 版微信的智能心跳机制》
《移动端 IM 实践：WhatsApp、Line、微信的心跳策略分析》
《Android P 正式版即将到来：后台应用保活、消息推送的真正噩梦》
《全面盘点当前 Android 后台保活方案的真实运行效果（截止 2019 年前）》
《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》
《融云技术分享：融云安卓端 IM 产品的网络链路保活技术实践》
3、IM 系统整体框架
如上图所示，为了保障链路存活，一套成熟的 IM 系统一般会包含消息链路和推送链路两条长连接通道。
当有新消息到达时，消息服务首先会判断消息链路是否存活，如果消息链路处于存活状态，消息优先从消息链路下发到客户端，否则会被路由到推送服务器，由推送链路下发。
综上所述：链路保活涉及到消息链路和推送链路两条链路的保活策略。基于这两条链路使用场景的不同，保活策略上除了心跳机制是相同的，其它保活策略各有不同。下面将逐一解读。
4、链路保活的必要性
基于 TCP 的 Socket 连接建立之后，如果不做任何处理，这个连接会长时间存在并且可用吗？答案是否定的。
原因有两点：
1）默认 Socket 连接无法及时探测到链路的异常情况，即使将 Socket 的属性参数 KeepAlive 设置为 True 仍然无法及时获取到链路存活状态。这是因为 Socket 的连接状态是由一个状态机进行维护的，连接完毕后，双方都会处于建立状态。假如某台服务器因为某些原因导致负载超高，无法及时响应业务请求，这时 TCP 探测到的仍然是连接状态，而实际上此链路已经不可用了。
2）国内运营商的 NAT 超时机制会把一定时间内没有数据交互的连接断开，这个时间可能只有几分钟，远无法满足我们的长连接需求。
这方面更详细的技术文章，请见：《为何基于 TCP 协议的移动端 IM 仍然需要心跳保活机制？》、《微信团队原创分享：Android 版微信后台保活实战分享(网络保活篇)》
5、通用保活机制 - 心跳机制
基于以上原因，要维持 Socket 连接长时间存活，就需要实现自己的保活机制。
最通用的一种保活机制就是心跳机制。即客户端每隔一段时间给服务器发送一个很小的数据包，根据能否收到服务器的响应来判断链路的可用性。为了节省流量，这个包一般非常小（通常是越小越好，比如网易云信的 IM 云产品中 1 字节心跳包是作为产品卖点进行宣传的），甚至没有内容。
那么客户端如何实现定时发送心跳包呢？一般有两种方式。
一种是通过 Java 里的 Timer 来实现。
最基本的步骤如下：
1）建立一个要执行的任务 TimerTask；
2）创建一个 Timer 实例，通过 Timer 提供的 schedule() 方法，将 TimerTask 加入到定时器 Timer 中，设置每隔一段时间执行 TimerTask , 在 TimerTask 里发送心跳包。这种方式实现起来较简单，而且省电，不需要持有 WakeLock。缺点也很明显，长时间在后台，进程被回收或者系统休眠后，Timer 机制随之失效。
另外一种方式是利用安卓系统的定时任务管理器 AlarmManager 循环执行发送心跳包的任务。
这种方式不会因为系统休眠而失效，系统休眠后仍然可以通过 WakeLock 唤醒，执行心跳任务。
因此相对 Timer 机制，这种方式比较费电，使用的时候一定要注意如下几点：
1）首先根据需求合理使用 AlarmManager 的闹钟参数。闹钟各参数的区别参考下表：
2）其次 AlarmManager 提供了 cancel() 方法，在设置新的定时任务前，通过 cancel() 方法取消系统里设置的同类型任务，避免设置冗余任务。
最后，安卓从 6.0 版本引入了 Doze 模式，并提供了新的闹钟设置方法 setExactAndAllowWhileIdle()，通过该方法设置的闹钟时间，系统会智能调度，将各个应用设置的事务统一在一次唤醒中处理，以达到省电的目的。推荐在安卓 6.0 以上系统中，优先使用该方法。
这方面更详细的技术文章，请见：
《应用保活终极总结(一)：Android6.0 以下的双进程守护保活实践》
《应用保活终极总结(二)：Android6.0 及以上的保活实践(进程防杀篇)》
《应用保活终极总结(三)：Android6.0 及以上的保活实践(被杀复活篇)》
《Android 进程保活详解：一篇文章解决你的所有疑问》
《Android P 正式版即将到来：后台应用保活、消息推送的真正噩梦》
《全面盘点当前 Android 后台保活方案的真实运行效果（截止 2019 年前）》
6、消息链路保活机制
消息链路作为收发消息的主要通道，需要最大程度保障链路的可用性。在链路不可用或者异常断开时，能及时探测并启动重连等保障机制。
基于以上特性，消息链路除了前面所说的心跳机制外，还另外维护了两套链路优化机制：复合连接机制和重连机制。
复合连接机制的基本步骤如下：
1）客户端连接导航服务器，导航服务器会下发应用对应的配置信息，其中包括连接服务器的地址列表；
2）客户端从第一个服务器地址尝试连接，并启动超时机制，如果连接失败或没有及时收到服务响应, 则继续尝试连接下一个直到成功连接，将成功连接的地址保存到本地，作为最优地址，后面连接时优先使用此地址。通过这种机制，能保障客户端优先选用最优链路，缩短连接时间。
▲ 复合连接机制原理
重连机制：则是指业务层在检测到与服务器的连接断开后，尝试 N 次重新连接服务器，首次断开 1 秒后会重新连接，如果仍然连接不成功，会在 2 秒后（重连间隔时间为上次重连间隔时间乘 2）尝试重新连接服务器，以此类推当尝试重连 N 次后，仍然连不上服务器将不再尝试重新连接，只有在网络情况发生变化或重新打开应用时才会再次尝试重连。
▲ 重连机制原理
7、推送链路保活机制
推送链路作为消息到达的补充手段，要求尽可能延长在后台的存活时间。即使被杀后，仍然能被再次唤醒。iOS 手机有 APNS 来达到以上效果（详见《了解 iOS 消息推送一文就够：史上最全 iOS Push 技术详解》），但安卓的官方推送系统 FCM 在国内基本不可用。那在国内安卓系统上如何保障推送到达呢？
首先咱们需要先了解下安卓系统上进程管理的两大机制：
1）一种是 LMK 机制，英文是 Low Memory Killer , 基于 Linux 的内存管理机制衍生而来。主要是通过进程的 oom_adj 值来判定进程的重要程度，从而决定是否回收这些进程。oom_adj 的值越低，代表重要度越高，比如 native 进程，framework 层启动的系统进程，优先级一般都为负数。其次是前台可见进程，系统也不会回收。然而可见进程退到后台后，oom_adj 的值会立即升高，在系统定时清理时被杀；
2）另外一种机制是安卓原生的权限管理机制（AppOps），各大厂家在此基础上又进行了深度定制化，比如小米的安全中心，华为的手机管家等，都用来进行权限管理。该权限管理机制运行在安卓系统的框架层，上层各应用的进程如果想尝试重新启动，系统首先会去权限管理中心检查该进程有没有自启动权限，如果有，才准予启动。否则，从框架层直接限制系统的启动。
基于以上两种机制，推送链路的保活也可分为两大类。
第一类：进程保活：
它的思路是根据 LMK 机制提高进程优先级，降低被杀的几率。
主要有以下几种方法：
1.1）监听黑屏事件，启动 1 像素透明 Activity：使应用进程转为可视进程，降低被杀概率。在屏幕亮时，关闭该 Activity。
1.2）双服务守护：A 服务以 startForeground() 形式启动，发送一个通知，B 服务同样以 startForeground() 形式启动，且发送和 A 相同 ID 的通知，然后在 B 服务里调用 stopForeground() 方法，取消通知。这样 A 服务就会以前台进程的形式存活，且不影响用户感知。
1.3）根据文件锁互斥原理，监视 Java 进程存活状态：若被杀，Linux 层成功持有文件，则通过 exec() 命令，打开一个纯 Linux 的可执行文件，开启一个 Daemon 进程, 该进程因为从 Linux 层启动，在安卓 5.0 之前，优先级会比较高，不会被杀。在安卓 5.0 之后，该方式不再有效。
第二类：进程拉活的策略和安卓系统的 AppOps 机制有关：
一般有如下几种：
1）利用 Service 本身的 Sticky 属性，在 Service 的 onStartCommand() 中返回 START_STICKY，这样当 Service 被杀掉后，系统会自动尝试重启。不过在国内定制化的系统上，这种方式能成功重启的几率很低，需要用户在权限管理中心打开自启动等权限，才能成功拉活；
2）也就是前面讲过的心跳机制，不过这里要求使用 AlarmManager 设置 ELAPSED_REALTIME_WAKEUP 属性的闹钟，在系统休眠后，才会正常接受到心跳事件，从而将进程拉活；
3）通过监听网络切换，用户行为等事件，拉起进程；
4）应用间互相拉活。比如系统里有好几个应用集成了同一个 SDK , 那么在用户启动其中某一个 App 的时候，SDK 会去扫描其它应用，把“兄弟姐妹”拉活。这种方式对用户体验伤害非常大，会造成系统莫名其妙的耗电。
以下保活“黑科技”的详细介绍文章，请详读：
《应用保活终极总结(一)：Android6.0 以下的双进程守护保活实践》
《应用保活终极总结(二)：Android6.0 及以上的保活实践(进程防杀篇)》
《应用保活终极总结(三)：Android6.0 及以上的保活实践(被杀复活篇)》
随着安卓系统版本的迭代，对后台进程的启动管控越来越严。为了解决推送的问题，各手机厂家推出了自己的系统级推送服务。由厂家在 Framework 层统一维护一条推送通道，上层所有应用共同使用该推送链路，不需要再维护单独进程。当前支持系统级推送的厂家有：小米、华为、魅族、vivo、OPPO。
鉴于 Android 系统对后台进程管控越来越严，保活“黑科技”已经不怎么灵了：
《Android P 正式版即将到来：后台应用保活、消息推送的真正噩梦》
《全面盘点当前 Android 后台保活方案的真实运行效果（截止 2019 年前）》
集成第三方系统级推送之后，整个消息的收发流程可以参考下图：
这种系统级别的推送省电，省内存，到达率高。应用可以根据手机型号的不同，优先使用厂家系统级别的推送，再配合自身的保活机制，最大程度保障推送的到达率。
附录：更多 IM 相关的技术文章汇总
[1] IM 开发相关的热门技术问题综合文章：
《新手入门一篇就够：从零开发移动端 IM》
《移动端 IM 开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端 IM 开发者必读(二)：史上最全移动弱网络优化方法总结》
《从客户端的角度来谈谈移动端 IM 的消息可靠性和送达机制》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《小白必读：闲话 HTTP 短连接中的 Session 和 Token》
《IM 开发基础知识补课：正确理解前置 HTTP SSO 单点登陆接口的原理》
《移动端 IM 中大规模群消息的推送如何保证效率、实时性？》
《移动端 IM 开发需要面对的技术问题》
《开发 IM 是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM 消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM 消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证 IM 实时消息的“时序性”与“一致性”？》
《一个低成本确保 IM 消息时序的方法探讨》
《IM 单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM 群聊消息如此复杂，如何保证不丢不重？》
《谈谈移动端 IM 开发中登录请求的优化》
《移动端 IM 登录时拉取数据如何作到省流量？》
《浅谈移动端 IM 的多点登陆和消息漫游原理》
《完全自已开发的 IM 该如何设计“失败重试”机制？》
《通俗易懂：基于集群的移动端 IM 接入层负载均衡方案分享》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
[2] 一些网络编程基础资料：
《TCP/IP 详解 – 第 11 章·UDP：用户数据报协议》
《TCP/IP 详解 – 第 17 章·TCP：传输控制协议》
《TCP/IP 详解 – 第 18 章·TCP 连接的建立与终止》
《TCP/IP 详解 – 第 21 章·TCP 的超时与重传》
《技术往事：改变世界的 TCP/IP 协议（珍贵多图、手机慎点）》
《通俗易懂 - 深入理解 TCP 协议（上）：理论基础》
《通俗易懂 - 深入理解 TCP 协议（下）：RTT、滑动窗口、拥塞处理》
《高性能网络编程(一)：单台服务器并发 TCP 连接数到底可以有多少》
《高性能网络编程(二)：上一个 10 年，著名的 C10K 并发连接问题》
《高性能网络编程(三)：下一个 10 年，是时候考虑 C10M 并发问题了》
《高性能网络编程(四)：从 C10K 到 C10M 高性能网络应用的理论探索》
《高性能网络编程(五)：一文读懂高性能网络编程中的 I / O 模型》
《高性能网络编程(六)：一文读懂高性能网络编程中的线程模型》
《不为人知的网络编程(一)：浅析 TCP 协议中的疑难杂症(上篇)》
《不为人知的网络编程(二)：浅析 TCP 协议中的疑难杂症(下篇)》
《不为人知的网络编程(三)：关闭 TCP 连接时为什么会 TIME_WAIT、CLOSE_WAIT》
《不为人知的网络编程(四)：深入研究分析 TCP 的异常关闭》
《不为人知的网络编程(五)：UDP 的连接性和负载均衡》
《不为人知的网络编程(六)：深入地理解 UDP 协议并用好它》
《不为人知的网络编程(七)：如何让不可靠的 UDP 变的可靠？》
《不为人知的网络编程(八)：从数据传输层深度解密 HTTP》
《不为人知的网络编程(九)：理论联系实际，全方位深入理解 DNS》
《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》
《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》
《网络编程懒人入门(三)：快速理解 TCP 协议一篇就够》
《网络编程懒人入门(四)：快速理解 TCP 和 UDP 的差异》
《网络编程懒人入门(五)：快速理解为什么说 UDP 有时比 TCP 更有优势》
《网络编程懒人入门(六)：史上最通俗的集线器、交换机、路由器功能原理入门》
《网络编程懒人入门(七)：深入浅出，全面理解 HTTP 协议》
《网络编程懒人入门(八)：手把手教你写基于 TCP 的 Socket 长连接》
《网络编程懒人入门(九)：通俗讲解，有了 IP 地址，为何还要用 MAC 地址？》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《移动端 IM 开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端 IM 开发者必读(二)：史上最全移动弱网络优化方法总结》
《从 HTTP/0.9 到 HTTP/2：一文读懂 HTTP 协议的历史演变和设计思路》
《脑残式网络编程入门(一)：跟着动画来学 TCP 三次握手和四次挥手》
《脑残式网络编程入门(二)：我们在读写 Socket 时，究竟在读写什么？》
《脑残式网络编程入门(三)：HTTP 协议必知必会的一些知识》
《脑残式网络编程入门(四)：快速理解 HTTP/ 2 的服务器推送(Server Push)》
《脑残式网络编程入门(五)：每天都在用的 Ping 命令，它到底是什么？》
《脑残式网络编程入门(六)：什么是公网 IP 和内网 IP？NAT 转换又是什么鬼？》
更多同类文章 ……
[3] 有关推送技术方面的文章：
《iOS 的推送服务 APNs 详解：设计思路、技术原理及缺陷等》
《信鸽团队原创：一起走过 iOS10 上消息推送 (APNS) 的坑》
《Android 端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识 MQTT 通信协议》
《一个基于 MQTT 通信协议的完整 Android 推送 Demo》
《IBM 技术经理访谈：MQTT 协议的制定历程、发展现状等》
《求教 android 消息推送：GCM、XMPP、MQTT 三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈 iOS 和 Android 后台实时消息推送的原理和区别》
《绝对干货：基于 Netty 实现海量接入的推送服务技术要点》
《移动端 IM 实践：谷歌消息推送服务 (GCM) 研究（来自微信）》
《为何微信、QQ 这样的 IM 工具不使用 GCM 服务推送消息？》
《极光推送系统大规模高并发架构的技术实践分享》
《从 HTTP 到 MQTT：一个基于位置服务的 APP 数据通信实践概述》
《魅族 2500 万长连接的实时消息推送架构的技术实践分享》
《专访魅族架构师：海量长连接的实时消息推送系统的心得体会》
《深入的聊聊 Android 消息推送这件小事》
《基于 WebSocket 实现 Hybrid 移动应用的消息推送实践(含代码示例)》
《一个基于长连接的安全可扩展的订阅 / 推送服务实现思路》
《实践分享：如何构建一套高可用的移动端消息推送系统？》
《Go 语言构建千万级在线的高并发消息推送系统实践(来自 360 公司)》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《百万在线的美拍直播弹幕系统的实时推送技术实践之路》
《京东京麦商家开放平台的消息推送架构演进之路》
《了解 iOS 消息推送一文就够：史上最全 iOS Push 技术详解》
《基于 APNs 最新 HTTP/ 2 接口实现 iOS 的高性能消息推送(服务端篇)》
《解密“达达 - 京东到家”的订单即时派发技术原理和实践》
《技术干货：从零开始，教你设计一个百万级的消息推送系统》
（本文同步发布于：http://www.52im.net/thread-27…）
