Android 进程常驻（2）----细数利用android系统机制的保活手段

这是一个轻量级的库，配置几行代码，就能够实如今android上实现进程常驻，也就是在系统强杀下，以及360获取root权限下，clean master获取root权限下都没法杀死进程

支持系统2.3到6.0

支持大部分设备，包括三星，华为，oppo，nexus，魅族等等

能够简单对开机广播进行保护

github地址：

https://github.com/Marswin/MarsDaemon

原理分析：

Android 进程常驻（0）----MarsDaemon使用说明

Android 进程常驻（1）----开篇

Android 进程常驻（2）----细数利用android系统机制的保活手段

Android 进程常驻（3）----native保活5.0如下方案推演过程以及代码详述

Android 进程常驻（4）----native保活5.0以上方案推演过程以及代码详述

Android 进程常驻（5）----开机广播的简单守护以及总结

正文：

年前就开篇了android进程常驻，可是一直杂事不断，也一直没有静下心来整理，只是把项目传到的github，有好多朋友会来问我其中实现原理，其实也是一点一点推演过来的。个人想法就是按照我当时的推演过程，按顺序写完这几篇博客，也算是对那一个月努力的一个交代。

上一篇讲了系统管理进程和强杀进程的过程原理，今天就开始想一下，在此基础上，如何实现保活，固然做为一个android开发，最早想到的确定是在framework层有没有什么机制能够利用实现保活，当时整理了如下几点（是对照本身当时写的ppt整理的，有些细节已经忘记）：

一、将Service设置为前台进程

二、在service的onstart方法里返回 STATR_STICK

三、添加Manifest文件属性值为android:persistent=“true”

四、覆写Service的onDestroy方法

五、添加广播监听android.intent.action.USER_PRESENT事件以及其余一些能够容许的事件

六、服务互相绑定

七、设置闹钟，定时唤醒

八、帐户同步，定时唤醒

九、native层保活






好的，而后咱们一个一个的来讲

一、将Service设置为前台进程。

本质是修改了Service所在进程的进程优先级，详情请参照 Android 进程常驻（1）----开篇。有了前台进程的优先级，在android系统清理内存的时候，他被杀死的优先级仅高于前台的activity，也就是正在和用户交互的页面，并且使用ddms杀进程他也能够本身启动起来。

可是，然，并，卵！

首先ddms杀进程和在系统设置的正在运行中杀进程自己就不具威胁，在系统设置的全部应用中选择强行中止，仍然能够强停掉，360，cm等软杀更是能垂手可得杀死他。并且他还有一个缺点，在api 17以上，设置了一个前台服务，他会以一个没法消除的notification的样式出如今用户的手机状态栏里，大大下降了用户体验。看源码

因此通常这么用

二、在service的onstart方法里返回 STATR_STICK

没多大用，放在常规应用里的service ok，但保活的话仍是差些。。。这里很少说了直接看源码注释

其余几个返回值分别表明了

START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后必定能重启。 

START_STICKY：系统就会从新建立这个服务而且调用onStartCommand()方法，可是它不会从新传递最后的Intent对象，这适用于不执行命令的媒体播放器（或相似的服务），它只是无限期的运行着并等待工做的到来。

START_NOT_STICKY：直到接受到新的Intent对象，才会被从新建立。这是最安全的，用来避免在不须要的时候运行你的服务。

START_REDELIVER_INTENT：系统就会从新建立了这个服务，而且用最后的Intent对象调。等待中的Intent对象会依次被发送。这适用于以下载文件。

三、添加Manifest文件属性值为android:persistent=“true”

若是你的应用能设置这个属性，能够全文跳过我这个系列全部文章。由于他真的能够杀不死，像系统的keyguard进程，media进程，且这些进程的adj都是负数，表明了前台activity黑屏了他们也不会死。可是这个属性须要系统shareuid，而后编译不过，由于须要系统签名，什么？你用系统签名？请忽略我所有

因此然并卵。

四、覆写Service的onDestroy方法

你会说这么low也行？为了把我知道的全部方式都列举出来，因此这里也说一下，在设置里面的正在运行，注意是正在运行里面，点击关闭，会走onDestroy回调方法，你在这里能够把本身启动起来。

可是仍然然并卵，设置里面的force close才是真正的劲敌，还有root了的360，cm这些boos才是咱们要解决的对象。

五、添加广播监听android.intent.action.USER_PRESENT事件以及其余一些能够容许的事件

这个有必要说一下，这个广播相信可能有的朋友不是很清楚，这是一个android解锁的广播事件。

注意：

1.这不是SCREEN_ON\SCREEN_OFF广播，,这不是SCREEN_ON\SCREEN_OFF广播，这不是SCREEN_ON\SCREEN_OFF广播。

2.这是一个能够静态注册的广播，这是一个能够静态注册的广播，这是一个能够静态注册的广播。

因此在manifest里面注册以后不须要任何前提，理论上用户每次开屏解锁都会触发咱们的onReceive事件，在这里咱们能够检查进程服务是否在，不在就拉起来。

可是，这个事件只有解锁才有，若是用户的没有设置锁屏，那么这个事件就是没有的，并且咱们的目标是保证进程一直存活，而不是尽量多的活起来。因此这个看成一个补充的手段也不错，另外全部那些能够静态注册的广播均可以这样搞，前提是你不怕用户看到你申请了好多权限，固然这个USER_PRESENT事件是不须要权限的。

如下是几个常见能够静态注册的广播，另外android7取消了wifi的静态广播注册，没有证明

android.intent.action.USER_PRESENT
android.net.conn.CONNECTIVITY_CHANGE
android.intent.action.MEDIA_MOUNTED
android.intent.action.MEDIA_UNMOUNTED
android.net.wifi.RSSI_CHANGED
android.net.wifi.STATE_CHANGE
android.net.wifi.WIFI_STATE_CHANGED

六、服务互相绑定

这个是android里面一个特性，跨进程bind一个service以后，若是被bind的service挂掉，bind他的service会把他拉起来。依然然并卵，具体为何之后再说。

七、设置闹钟，定时唤醒

市面上了解到的大部分应用是用这种保活方式，使用系统闹钟定时发通知过来唤醒进程。

可是，

且先不说高频的唤醒和手机厂商对于wakelock的控制上形成的耗电问题。单单保活效果上就很难过关，force close直接杀掉，没有挣扎的机会，360、cm更是随便杀。说下alarm的几个参数

AlarmManager.RTC，硬件闹钟，不唤醒手机（也多是其它设备）休眠；当手机休眠时不发射闹钟。

AlarmManager.RTC_WAKEUP，硬件闹钟，当闹钟发躰时唤醒手机休眠；

AlarmManager.ELAPSED_REALTIME，真实时间流逝闹钟，不唤醒手机休眠；当手机休眠时不发射闹钟。

AlarmManager.ELAPSED_REALTIME_WAKEUP，真实时间流逝闹钟，当闹钟发躰时唤醒手机休眠；

 

嗯，RTC闹钟和ELAPSED_REALTIME最大的差异就是前者能够经过修改手机时间触发闹钟事件，后者要经过真实时间的流逝，即便在休眠状态，时间也会被计算。

八、帐户同步，定时唤醒

这个估计也是好多人不知道一点，android系统里有一个帐户系统，设置一个本身的帐户，android会按期唤醒帐户更新服务，咱们能够本身设定同步的事件间隔。且发起更新的是系统，不会受到任何限制。看下效果，晚上下班到次日早晨，开着cm后台自动清理

 log上来看唤醒时间一直正常，且在睡眠中是不会产生唤醒的。

使用方法也很简单：

那么，这就是咱们想要的？

还不行！！！

他的局限性在于：

第一，用户会在系统设置的帐户列表里面看到一个不认识的帐户；

第二，同步的事件间隔是有限制的，最短1分钟，见源码，若是小雨60秒，置为60秒。并且各类国产机怎么改的源码咱们未可知，是否是都能用仍然未可知；

第三，很致命，某些手机好比note3须要手动设置帐户，你如何骗你的用户给你手动设置帐户完了以后不卸载你；

第四，也很致命，必须联网！google提供这个组件是让你同步帐户信息，不联网你同步个鬼，咱们要保活，能够不联网不作事，可是不能不联网就死


可是，把他放在最后，仍然是一个很好的保活补充手段

九、native层保活

终于要到正文了。下一篇开启native保活的篇章，首先上一个github上别人的native保活方案，也是绝大多数公司采用的native方案，笔者所在公司亦是北京知名互联网公司，以前也采起的相似方案，可是，其实只是开了一个native进程按期发intent而已，缺陷是：只能简单保活，360、cm碾压其无压力，但仍有可借鉴之处，下一篇分析，而后开始个人native之旅

https://github.com/Coolerfall/Android-AppDaemon