融云技术分享：融云安卓端IM产品的网络链路保活技术实践

本文来自融云技术团队原创分享，原文发布于“ 融云全球互联网通信云”公众号，原题《IM 即时通讯之链路保活》，即时通讯网收录时有部分改动。

1、引言

众所周知，IM 即时通讯是一项对即时性要求非常高的技术，而保障消息即时到达的首要条件就是链路存活。那么在复杂的网络环境和国内安卓手机被深度定制化的条件下，如何保障链路存活呢？本文详解了融云安卓端IM产品在基于 TCP 协议实现链路保活方面的实践总结。

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年前）》

集成第三方系统级推送之后，整个消息的收发流程可以参考下图：

这种系统级别的推送省电，省内存，到达率高。应用可以根据手机型号的不同，优先使用厂家系统级别的推送，再配合自身的保活机制，最大程度保障推送的到达率。