IM 系统整体框架
![](http://www.ctiforum.com/uploadfile/2019/0410/20190410045443971.jpg)
如上图所示,为了保障链路存活,一套成熟的 IM 系统一般会包含消息链路和推送链路两条长连接通道。当有新消息到达时,消息服务首先会判断消息链路是否存活,如果消息链路处于存活状态,消息优先从消息链路下发到客户端,否则会被路由到推送服务器,由推送链路下发。
综上所述,链路保活涉及到消息链路和推送链路两条链路的保活策略。基于这两条链路使用场景的不同,保活策略上除了心跳机制是相同的,其它保活策略各有不同。下文将逐一解读。
链路保活的必要性
基于 TCP 的 Socket 连接建立之后,如果不做任何处理,这个连接会长时间存在并且可用吗?答案是否定的。原因有两点:
一、默认Socket 连接无法及时探测到链路的异常情况,即使将 Socket 的属性参数 KeepAlive 设置为 True 仍然无法及时获取到链路存活状态。这是因为 Socket 的连接状态是由一个状态机进行维护的,连接完毕后,双方都会处于建立状态。假如某台服务器因为某些原因导致负载超高,无法及时响应业务请求,这时 TCP 探测到的仍然是连接状态,而实际上此链路已经不可用了。
二、国内运营商的 NAT 超时机制会把一定时间内没有数据交互的连接断开,这个时间可能只有几分钟,远无法满足我们的长连接需求。
通用保活机制-心跳机制
基于以上原因,要维持 Socket 连接长时间存活,就需要实现自己的保活机制。最通用的一种保活机制就是心跳机制。即客户端每隔一段时间给服务器发送一个很小的数据包,根据能否收到服务器的响应来判断链路的可用性。为了节省流量,这个包一般非常小,甚至没有内容。
![](http://www.ctiforum.com/uploadfile/2019/0410/20190410045513752.jpg)
那么客户端如何实现定时发送心跳包呢?一般有两种方式:
一种是通过 Java 里的 Timer 来实现。最基本的步骤如下:
- 建立一个要执行的任务 TimerTask 。
- 创建一个 Timer 实例,通过 Timer 提供的 schedule() 方法,将 TimerTask 加入到定时器 Timer 中,设置每隔一段时间执行 TimerTask , 在 TimerTask 里发送心跳包。这种方式实现起来较简单,而且省电,不需要持有 WakeLock 。缺点也很明显,长时间在后台,进程被回收或者系统休眠后, Timer 机制随之失效。
另外一种方式是利用安卓系统的定时任务管理器 AlarmManager 循环执行发送心跳包的任务。这种方式不会因为系统休眠而失效,系统休眠后仍然可以通过 WakeLock 唤醒,执行心跳任务,因此相对 Timer 机制,这种方式比较费电,使用的时候一定要注意如下几点:
- 首先根据需求合理使用 AlarmManager 的闹钟参数。闹钟各参数的区别参考下表:
![](http://www.ctiforum.com/uploadfile/2019/0410/20190410045701840.jpg)
- 其次 AlarmManager 提供了 cancel() 方法,在设置新的定时任务前,通过 cancel() 方法取消系统里设置的同类型任务,避免设置冗余任务。
- 最后,安卓从 6.0 版本引入了 Doze 模式,并提供了新的闹钟设置方法 setExactAndAllowWhileIdle() ,通过该方法设置的闹钟时间,系统会智能调度,将各个应用设置的事务统一在一次唤醒中处理,以达到省电的目的。推荐在安卓 6.0 以上系统中,优先使用该方法。
消息链路保活机制
消息链路作为收发消息的主要通道,需要最大程度保障链路的可用性。在链路不可用或者异常断开时,能及时探测并启动重连等保障机制。基于以上特性,消息链路除了前面所说的心跳机制外,还另外维护了两套链路优化机制:复合连接机制和重连机制。
复合连接机制的基本步骤如下:
- 客户端连接导航服务器,导航服务器会下发应用对应的配置信息,其中包括连接服务器的地址列表。
- 客户端从第一个服务器地址尝试连接,并启动超时机制,如果连接失败或没有及时收到服务响应, 则继续尝试连接下一个直到成功连接,将成功连接的地址保存到本地,作为最优地址,后面连接时优先使用此地址。通过这种机制,能保障客户端优先选用最优链路,缩短连接时间。
![](http://www.ctiforum.com/uploadfile/2019/0410/20190410045728487.jpg)
重连机制,则是指业务层在检测到与服务器的连接断开后,尝试 N 次重新连接服务器,首次断开 1 秒后会重新连接,如果仍然连接不成功,会在 2 秒后(重连间隔时间为上次重连间隔时间乘 2 )尝试重新连接服务器,以此类推当尝试重连 N 次后,仍然连不上服务器将不再尝试重新连接,只有在网络情况发生变化或重新打开应用时才会再次尝试重连。
![](http://www.ctiforum.com/uploadfile/2019/0410/20190410045744721.jpg)
推送链路保活机制
推送链路作为消息到达的补充手段,要求尽可能延长在后台的存活时间。即使被杀后,仍然能被再次唤醒。 iOS 手机有 APNS 来达到以上效果,但安卓的官方推送系统 FCM 在国内基本不可用。那在国内安卓系统上如何保障推送到达呢?首先咱们需要先了解下安卓系统上进程管理的两大机制:
一种是 LMK 机制,英文是 Low Memory Killer , 基于 Linux 的内存管理机制衍生而来。主要是通过进程的 oom_adj 值来判定进程的重要程度,从而决定是否回收这些进程。 oom_adj 的值越低,代表重要度越高,比如 native 进程, framework 层启动的系统进程,优先级一般都为负数。其次是前台可见进程,系统也不会回收。然而可见进程退到后台后, oom_adj 的值会立即升高,在系统定时清理时被杀。
另外一种机制是安卓原生的权限管理机制( AppOps ),各大厂家在此基础上又进行了深度定制化,比如小米的安全中心,华为的手机管家等,都用来进行权限管理。该权限管理机制运行在安卓系统的框架层,上层各应用的进程如果想尝试重新启动,系统首先会去权限管理中心检查该进程有没有自启动权限,如果有,才准予启动。否则,从框架层直接限制系统的启动。
基于以上两种机制,推送链路的保活也可分为两大类:
一、进程保活。它的思路是根据 LMK 机制提高进程优先级,降低被杀的几率。主要有以下几种方法:
- 监听黑屏事件,启动 1 像素透明 Activity ,使应用进程转为可视进程,降低被杀概率。在屏幕亮时,关闭该 Activity 。
- 双服务守护。 A 服务以 startForeground() 形式启动,发送一个通知, B 服务同样以 startForeground() 形式启动,且发送和 A 相同 ID 的通知,然后在 B 服务里调用 stopForeground() 方法,取消通知。这样 A 服务就会以前台进程的形式存活,且不影响用户感知。
- 根据文件锁互斥原理,监视 Java 进程存活状态,若被杀, Linux 层成功持有文件,则通过 exec() 命令,打开一个纯 Linux 的可执行文件,开启一个 Daemon 进程, 该进程因为从 Linux 层启动,在安卓 5.0 之前,优先级会比较高,不会被杀。在安卓 5.0 之后,该方式不再有效。
二、进程拉活的策略和安卓系统的 AppOps 机制有关,一般有如下几种:
- 利用 Service 本身的 Sticky 属性,在 Service 的 onStartCommand() 中返回 START_STICKY ,这样当 Service 被杀掉后,系统会自动尝试重启。不过在国内定制化的系统上,这种方式能成功重启的几率很低,需要用户在权限管理中心打开自启动等权限,才能成功拉活。
- 也就是前面讲过的心跳机制,不过这里要求使用 AlarmManager 设置 ELAPSED_REALTIME_WAKEUP 属性的闹钟,在系统休眠后,才会正常接受到心跳事件,从而将进程拉活。
- 通过监听网络切换,用户行为等事件,拉起进程。
- 应用间互相拉活。比如系统里有好几个应用集成了同一个 SDK , 那么在用户启动其中某一个 App 的时候, SDK 会去扫描其它应用,把“兄弟姐妹” 拉活。这种方式对用户体验伤害非常大,会造成系统莫名其妙的耗电。
![](http://www.ctiforum.com/uploadfile/2019/0410/20190410045918327.jpg)
这种系统级别的推送省电,省内存,到达率高。应用可以根据手机型号的不同,优先使用厂家系统级别的推送,再配合自身的保活机制,最大程度保障推送的到达率。