im即时通讯开发之双进程守护保活实践

在Android 4.4及以后的系统中，应用能否常驻内存，一直以来都是相当头疼的事情，尤其移动端IM、消息推送这类应用，为了保证“全时在线”的概念，真是费尽了心思。

虽然APP常驻内存对于用户来说比较”恶心”，但是在诸如IM和消息推送这类场景来说，APP的常驻内存却尤其重要，而且很多时候用户也会要求APP能够保证长久运行。

因为Android机型太多太杂，以及各厂商定制ROOM的差异，Android应用保活没有一劳永逸和万能的方法。

 

常见的Android应用保活方法

1）监听广播方式：

通过监听一些全局的静态广播，比如开机广播、解锁屏广播、网络状态广播等，来启动应用的后台服务。目前，在高版本的Android系统中已经失效，因为高版本的Android系统规定应用必须在系统开机后运行一次才能监听这些系统广播，一般而言，应用被系统杀死后，基本无法接收系统广播。

2）提高Service的优先级：

以前提高Service优先级方法很多，比如onStartCommand返回START_STICKY使系统内存足够的时候Service能够自动启动、弹出通知、配置service的优先级等，这些方式只能在一定程度上缓解service被立马回收，但只要用户一键清理或者系统回收照样无效。

3）全局定时器：

还有一种方法就是在设置一种全局定时器，定时检测启动后台服务，但这种方法目前也已经无效，因为应用只要被系统杀死，全局定时器最后也只成了摆设。

4）应用中的双service拉起：

经过测试，只要当前应用被杀，任何后台service都无法运行，也无法自行启动。

5）