Android应用的保活方案以及另类出路，你了解几个

---

前言

我们在做Android应用的时候都知道，必须要有一套好的保活方案，这样应用的push到达率高，应用的活跃度也就很高，我们平时也可以发现很多应用我们明明已经关闭了，但是还是可以接收到push消息，或者ps查看进程还是存在的。当然现在已经有很多方案在做这件事了，但是有一个问题就是像微信中及时接受消息的应用如果系统把他强杀之后接收不到消息，用户也是要疯掉的，所以系统厂商会给出一个白名单有一些应用是不会强杀的。一

一、常见保活方案

**1、监听广播：**监听全局的静态广播，比如时间更新的广播、开机广播、解锁屏、网络状态、解锁加锁亮屏暗屏（3.1版本），高版本需要应用开机后运行一次才能监听这些系统广播，目前此方案失效。可以更换思路，做APP启动后的保活（监听广播启动保活的前台服务）

**2、定时器、JobScheduler：**假如应用被系统杀死，那么定时器则失效，此方案失效。JobService在5.0,5.1,6.0作用很大，7.0时候有一定影响（可以在电源管理中给APP授权）

**3、双进程（NDK方式Fork子进程）、双Service守护：**高版本已失效，5.0起系统回收策略改成进程组。双Service方案也改成了应用被杀，任何后台Service无法正常状态运行

**4、提高Service优先级：**只能一定程度上缓解Service被立马回收

二、保活

• 1、AIDL方式单进程、双进程方式保活Service
• 2、降低oom_adj的值：常驻通知栏（可通过启动另外一个服务关闭Notification，不对oom_adj值有影响）、使用”1像素“的Activity覆盖在getWindow()的view上、循环播放无声音频（黑科技，7.0下杀不掉）
• 3、监听锁屏广播：使Activity始终保持前台
• 4、使用自定义锁屏界面：覆盖了系统锁屏界面。
• 5、通过android:process属性来为Service创建一个进程
• 6、跳转到系统白名单界面让用户自己添加app进入白名单

三、保活的另类出路

我们知道现在很多应用都想开启自启动权限，这样应用就可以保活很久了了，不过只要有了自启动权限之后应用首先是不会杀死，然后也可以重启，真的是完完全全的保活了，那么其实权限这个事情我们肯定是做不了了，所以我们可以想其他的方案，比如我们可以引导用户去开启，这个就要看产品怎么去很好的引导用户了，比如有一个提示说：开启自启动可以更好的使用本应用此类消息。这样有了自启动权限之后可以做很多事情了，但是不是所有的用户都愿意去开启的，那么我们怎么让我们的应用保活呢，难道真的没办法了吗？办法其实还是有的：

当我们点击系统菜单键出现系统多任务界面，然后点击清空内存，其实系统这时候会获取当前正在运行的程序，并且获取他们的页面截图用于展示，而对于正在当前运行的程序是不会强制杀死的，也就是TopActivity的程序是不会杀死的。那么我们是否可以利用这一点来做呢？首先我们可以监听系统的多任务菜单键，这个就是动态监听系统一个广播即可，然后我们监听到之后就立马启动我们自己的一个保活Activity这里就叫做一像素Activity，但是这个Activity需要具备以下三点。

**第一点：**因为一像素对于肉眼来看几乎可以忽略，所以需要在这个Activity中设置大小：

**第二点：**不能让这个Activity出现在多任务中，不然会被用户发现就恶心了，这里可以在xml中设置一个属性即可：

**第三点：**启动这个Activity速度要非常快，也就是要赶在系统获取正在运行的Task之前启动起来，不然就无效了，所以按照正常的系统启动Activity流程会很慢的，这里用反射启Activity，这个技术在大家可以去网上查查，这里不多说了，这样启动的话保证在10ms之内完成，这样就可以赶在系统获取Task之前了：

**第四点：**在启动之后要在一定时间内把一像素Activity关闭，不然最顶端的一像素Activity会夺取屏幕的触控焦点，用户点击清空内存就无效了，用户会癫狂的：

有了这四点，这个一像素Activity就可以让我们的应用保活了：

当然这个可能有手机适配问题，大家可以看代码进行项目的适配，这种方式还有一个最大的好处就是，我们知道Android8.0之后系统不允许应用在后台静默启动一个服务了，如果要启动服务就要告诉用户，让用户可以看到，不然就报错，大家可以自行搜索相关内容。

其实这对于用户来说是好事，这样对设备有好处，不然后台启动了一大堆服务在跑，耗电耗性能。如果用了这个一像素保活方案的话那么我们没有启动一个服务，也就不会有这种限制了，同时也让我们的应用保活了。

四、保活方案总结

好了到这里我们就把保活方案介绍完了，下面就来总结一下保活方案吧：

第一、首先是网上有很多各种保活方案主要是监听广播等，而现在很多应用采用了MarsDaemon框架方案，这个框架的确还是有用的，对于某些指定手机。

第二、同时现在有一个叫做保活互助联盟，比如支付宝，微信，头条等都在里面，只要用户手机中安装了联盟成员的应用，只有有一个成员的应用活着就会把其他已经被杀死的联盟成员应用都唤醒起来。而我们知道像微信这类即时通讯工具一遍很多手机厂商都会加上白名单也就是不会强杀的，那么如果我们通过反编译微信找到他内部一个不需要权限广播，微信不死我们监听他的某个广播就可以起来了，前提是你能找到这个广播。

第三、上面也说了，不管是哪种保活方案，最终的归途都是不好的，因为谷歌慢慢的优化系统对于后台启动服务的操作是不赞同的，所以后面随着系统升级很多保活方案几乎都要挂了，而本文介绍的另类处理方式的一像素保活方案可以暂时解决这样的问题。