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

JackJiang · 5 年前

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

1、引言

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

2、相关文章

3、IM 系统整体框架

如上图所示，为了保障链路存活，一套成熟的 IM 系统一般会包含消息链路和推送链路两条长连接通道。

当有新消息到达时，消息服务首先会判断消息链路是否存活，如果消息链路处于存活状态，消息优先从消息链路下发到客户端，否则会被路由到推送服务器，由推送链路下发。

综上所述：链路保活涉及到消息链路和推送链路两条链路的保活策略。基于这两条链路使用场景的不同，保活策略上除了心跳机制是相同的，其它保活策略各有不同。下面将逐一解读。

4、链路保活的必要性

基于 TCP 的 Socket 连接建立之后，如果不做任何处理，这个连接会长时间存在并且可用吗？答案是否定的。

原因有两点：

1）默认Socket 连接无法及时探测到链路的异常情况，即使将 Socket 的属性参数 KeepAlive 设置为 True 仍然无法及时获取到链路存活状态。这是因为 Socket 的连接状态是由一个状态机进行维护的，连接完毕后，双方都会处于建立状态。假如某台服务器因为某些原因导致负载超高，无法及时响应业务请求，这时 TCP 探测到的仍然是连接状态，而实际上此链路已经不可用了。

2）国内运营商的 NAT 超时机制会把一定时间内没有数据交互的连接断开，这个时间可能只有几分钟，远无法满足我们的长连接需求。

这方面更详细的技术文章，请见：《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》、《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》

5、通用保活机制-心跳机制

基于以上原因，要维持 Socket 连接长时间存活，就需要实现自己的保活机制。

最通用的一种保活机制就是心跳机制。即客户端每隔一段时间给服务器发送一个很小的数据包，根据能否收到服务器的响应来判断链路的可用性。为了节省流量，这个包一般非常小（通常是越小越好，比如网易云信的IM云产品中1字节心跳包是作为产品卖点进行宣传的），甚至没有内容。

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

那么客户端如何实现定时发送心跳包呢？一般有两种方式。

一种是通过 Java 里的 Timer 来实现。

最基本的步骤如下：

1）建立一个要执行的任务 TimerTask ；
2）创建一个 Timer 实例，通过 Timer 提供的 schedule() 方法，将 TimerTask 加入到定时器 Timer 中，设置每隔一段时间执行 TimerTask , 在 TimerTask 里发送心跳包。这种方式实现起来较简单，而且省电，不需要持有 WakeLock 。缺点也很明显，长时间在后台，进程被回收或者系统休眠后， Timer 机制随之失效。

另外一种方式是利用安卓系统的定时任务管理器 AlarmManager 循环执行发送心跳包的任务。

这种方式不会因为系统休眠而失效，系统休眠后仍然可以通过 WakeLock 唤醒，执行心跳任务。

因此相对 Timer 机制，这种方式比较费电，使用的时候一定要注意如下几点：

1）首先根据需求合理使用 AlarmManager 的闹钟参数。闹钟各参数的区别参考下表：

3.png (31.44 KB, 下载次数: 1344)

下载附件保存到相册

5 年前上传
2）其次 AlarmManager 提供了 cancel() 方法，在设置新的定时任务前，通过 cancel() 方法取消系统里设置的同类型任务，避免设置冗余任务。

最后，安卓从 6.0 版本引入了 Doze 模式，并提供了新的闹钟设置方法 setExactAndAllowWhileIdle() ，通过该方法设置的闹钟时间，系统会智能调度，将各个应用设置的事务统一在一次唤醒中处理，以达到省电的目的。推荐在安卓 6.0 以上系统中，优先使用该方法。

这方面更详细的技术文章，请见：

最新推荐：《Android保活从入门到放弃：乖乖引导用户加白名单吧(附7大机型加白示例)》（此文发布于2020年06月13日）。

6、消息链路保活机制

消息链路作为收发消息的主要通道，需要最大程度保障链路的可用性。在链路不可用或者异常断开时，能及时探测并启动重连等保障机制。

基于以上特性，消息链路除了前面所说的心跳机制外，还另外维护了两套链路优化机制：复合连接机制和重连机制。

复合连接机制的基本步骤如下：

1）客户端连接导航服务器，导航服务器会下发应用对应的配置信息，其中包括连接服务器的地址列表；
2）客户端从第一个服务器地址尝试连接，并启动超时机制，如果连接失败或没有及时收到服务响应, 则继续尝试连接下一个直到成功连接，将成功连接的地址保存到本地，作为最优地址，后面连接时优先使用此地址。通过这种机制，能保障客户端优先选用最优链路，缩短连接时间。

▲ 复合连接机制原理

重连机制：则是指业务层在检测到与服务器的连接断开后，尝试 N 次重新连接服务器，首次断开 1 秒后会重新连接，如果仍然连接不成功，会在 2 秒后（重连间隔时间为上次重连间隔时间乘 2 ）尝试重新连接服务器，以此类推当尝试重连 N 次后，仍然连不上服务器将不再尝试重新连接，只有在网络情况发生变化或重新打开应用时才会再次尝试重连。

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

▲ 重连机制原理

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 会去扫描其它应用，把“兄弟姐妹” 拉活。这种方式对用户体验伤害非常大，会造成系统莫名其妙的耗电。

以下保活“黑科技”的详细介绍文章，请详读：

随着安卓系统版本的迭代，对后台进程的启动管控越来越严。为了解决推送的问题，各手机厂家推出了自己的系统级推送服务。由厂家在 Framework 层统一维护一条推送通道，上层所有应用共同使用该推送链路，不需要再维护单独进程。当前支持系统级推送的厂家有：小米、华为、魅族、 vivo 、OPPO 。

鉴于Android系统对后台进程管控越来越严，保活“黑科技”已经不怎么灵了：

在后Android保活时代，请读读以下两篇文章：

集成第三方系统级推送之后，整个消息的收发流程可以参考下图：
融云技术分享：融云安卓端IM产品的网络链路保活技术实践_6.png

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

附录1：融云分享的其它文章

附录2：更多IM相关的技术文章汇总

2 楼: jevensonv · 5 年前

学习

本文目录

1、引言

2、相关文章

3、IM 系统整体框架

4、链路保活的必要性

5、通用保活机制-心跳机制

6、消息链路保活机制

7、推送链路保活机制

附录1：融云分享的其它文章

附录2：更多IM相关的技术文章汇总

本帖已收录至以下技术专辑

MobileIMSDK (v6.5精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

精华之王

白金版主

终身成就

即时通讯网

友情链接[友链交换]

关于

微信公众号new

本文目录

1、引言

2、相关文章

3、IM 系统整体框架

4、链路保活的必要性

5、通用保活机制-心跳机制

6、消息链路保活机制

7、推送链路保活机制

附录1：融云分享的其它文章

附录2：更多IM相关的技术文章汇总

本帖已收录至以下技术专辑

MobileIMSDK(v6.5精编版)

MobileIMSDK-Web(有偿开源)

RainbowAVnew(有偿开源)

RainbowChat(技术转让)

RainbowChat-Web(技术转让)

精华之王

白金版主

终身成就

即时通讯网

友情链接[友链交换]

关于

微信公众号new

MobileIMSDK (v6.5精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

即时通讯网　