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

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

1、将Service设置为前台进程

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

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

4、覆写Service的onDestroy方法

5、添加广播监听android.intent.action.USER_PRESENT事件以及其他一些可以允许的事件

6、服务互相绑定

7、设置闹钟，定时唤醒

8、账户同步，定时唤醒

9、native层保活






好的，然后我们一个一个的来说

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

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

但是，然，并，卵！

首先ddms杀进程和在系统设置的正在运行中杀进程本身就不具威胁，在系统设置的所有应用中选择强行停止，仍然可以强停掉，360，cm等软杀更是能轻而易举杀死他。而且他还有一个缺点，在api 17以上，设置了一个前台服务，他会以一个无法消除的notification的样式出现在用户的手机状态栏里，大大降低了用户体验。看源码

所以一般这么用

2、在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对象会依次被发送。这适用于如下载文件。

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

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

所以然并卵。

4、覆写Service的onDestroy方法

你会说这么low也行？为了把我知道的所有方式都列举出来，所以这里也说一下，在设置里面的正在运行，注意是正在运行里面，点击关闭，会走onDestroy回调方法，你在这里可以把自己启动起来。

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

5、添加广播监听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

6、服务互相绑定

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

7、设置闹钟，定时唤醒

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

但是，

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

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

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

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

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

 

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

8、账户同步，定时唤醒

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

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

使用方法也很简单：

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

还不行！！！

他的局限性在于：

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

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

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

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


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

9、native层保活

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

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