android 进程 keep live 探索

被杀原因总结

• LowMemoryKiller：这种情况是触发了系统进程管理机制，通过系统会参照当前系统资源情况和 oom_adj 值来回收进程，oom_adj 越大，越容易被杀死
• 第三方清理软件：杀死 oom_adj 值大于 4 的进程，如果拥有 root 权限，理论可杀死所有进程
• 厂商杀进程：可杀所有进程 如厂商的自带的系统管家，对使用者来说功能强大，但对开发者来说很头疼的
• Force-stop：可杀所有非系统进程

keep live 常见方法

• 厂商应用白名单或者系统 app
  富人玩的，这个不属于技术范畴（qq，微信）

• 链式启动
  百度，阿里，腾讯的全家桶应用的就是这个

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

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

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

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

• 应用中的双进程拉起
  这种方式就是传说中的使用 NDK 在底层 fork 出一个子进程，来实现与父进程之间的互拉。在 Android4.x 还是非常有效的，但是高版本的 Android 系统的系统回收策略已经改成进程组的形式了，如果系统要回收一个应用，必然会杀死同属于一个进程组的所有进程，因此最后导致双进程无法拉起。

• JopService
  对于 Android 5.0，JobSheduler 的唤醒是非常有效的；对于 Android 6.0，虽然谷歌引入了 Doze 模式，但通常很难真正进入 Doze 模式，所以 JobSheduler 的唤醒依然有效；对于 Android 7.0，JobSheduler 的唤醒会有一定的影响，我们可以在电池管理中给 APP 开绿色通道，防止手机 Doze 模式后阻止 APP 使用 JobSheduler 功能。注：如果遇到深度定制机型，这就要看运气了...

• 一像素 Activity
  当锁屏时候启动一个一像素界面，使应用置于前台，避免被杀，试过可行，但行为有些流氓，像一些锁屏点亮广告的原理就是基逾此的。如果开发者都这样，效果就要打折扣了。

参考实例 http://blog.csdn.net/andrexpert/article/details/53485360 vivox9 7.0 失效 魅族 mx3 5.0 可以用

参考实例 http://blog.csdn.net/AndrExpert/article/details/75174586 vivox9 7.0 失效 魅族 mx3 5.0 可以用
参考实例 http://blog.csdn.net/andrexpert/article/details/75045678 7.0 一像素 还是可行的
结论 ：一些传统的进程保活，如 双进程，jobservice 对于 7.0 系统来说很难过了，据说 8.0 更是困难（目前还没有测试 8.0 手机）

另一种思路 ： 走系统通道

• 引导用户将应用添加到白名单(辅助功能)
• 走系统通道，如小米推送，华为推送的后台保活走的都是系统通道，小米，华为的出货量还是比较客观的。这样要求 app 集成多个推送服务，很是麻烦。
• 综合前面用到的几种灰色保活手段，存活率提高了不少，但也总是有极个别的不行，但这也至少满足了 9 成的需求（android7.0 之下，8.0 基本上不可能，也许有些未公开的灰色手段）

总结：鉴于 android 的开源性，总有一些保活的黑科技在不断的挖掘出来，但同样由于此原因，也总有一些深度定制的手机无法应用此黑科技。但是满足多数需求还是没问题的！

参考 ## 揭秘 360 手机助手未经用户同意，自动开启辅助功能的“黑科技”
参考 Android 6.0 以上系统 APP 保活方法归纳