Android 保活措施

这个文章只是Android历史保活方案总结，没有什么特别的参考意义，Android 已经到10了，100%保活自己就已经不复存在，文章中全部的方案，都是有可能有用，毕竟4.4还有人用，至于要不用能够本身参考，毕竟当PM就是让你应用不死，你能不写代码吗？

保活一般分为2种方案，一种为提升进程优先级，防止被杀，另外一种为进程被杀死拉活

1. 进程优先级

Android系统会尽量的保持应用进程，可是当须要创建新的进程或者运行更重要的进程，便会回收优先级低一些的进程,这个就是lowmemorykiller的工做。而进程的优先级其实就是 /proc/pid/oom_adj

进程的优先级排序

1. 前台进程（Foreground Process）
2. 可见进程(Visible Process)
3. 服务进程(Service Process)
4. 后台进程(Background Process)
5. 空进程(Empty Process)

前台进程

1. 拥有 用户正在交互的 Activity(正处于 onResume中)
2. 拥有 Service绑定到正处于 onResume的 Activity
3. 拥有 Service 调用 startForeground 成为前台服务
4. 拥有 Service 正在执行生命周期回调（onCreate、onStart、onDestroy）
5. 拥有 BroadcastReceiver 正在执行 onReceive

可见进程

1. 拥有 Activity 处于 onPause ，此时可见可是不可操做
2. 拥有 Service 绑定到正处于 onPause的 Activity

服务进程

1. 仅经过 startService 启动的 Service

后台进程

1. 拥有 Activity 处于 onStop

空进程

1. 不拥有任何活动的组件进程

2. 回收策略

从Zygote fork出来的进程都会被储存在 ActivityManagerService.mLruProcesses 列表中，由ActivityManagerService进行统一管理。ActivityManagerService会根据进程状态去更新进程所对应的 oom_adj 的值，当内存达到必定的阈值会触发清理 oom_adj 高的进程。

参考博客

3. 保活方案

3.1 提升进程优先级

3.1.1 利用Activity

1像素Activy，监控手机解锁屏事件，解锁时将Activity销毁，锁屏时启动，而且要无感知，在RecentTask里移除

3.1.2 前台服务+Notification

Service 经过 startForegroundService 启动 ，低版本时能够经过特殊方式对 Notification 进行隐藏，高版本没法规避，此方案为经过需求正向解决

3.1.3 引导用户打开电池管理，容许应用后台运行

目前市面上的手机，或多或少都有对进程管理有优化，可能会有容许应用后台容许的功能，可是每款手机的入口均不相同，并且相同厂商的不一样版本也会不一样

具体作法，找到手机的电池管理或者系统的后台管理，针对不一样的手机作文字书面的提醒，提醒用户开启此功能，暴力一点能够想办法拿到此Activity的具体类名 包名等信息，进行反射调用。

此方案通常应用不要使用，工做量巨大，并且仅仅针对提醒类应用使用，好比吃药提醒，起床闹钟，这些对保活要求很是高的应用才适合

3.2 进程死后拉活

3.2.1 监听系统静态广播

低版本时，静态广播能够唤醒应用进程，因此监听系统广播，例如开机，锁屏，解锁等能够作到，可是高版本不能经过静态广播监听系统广播了

3.2.2 监听三方静态广播

与上个方案相似，都是运用静态广播能够拉活应用为基础，只是发送方不是系统，并且三方应用。因此此方案可行，可是很不稳定，海外和国内用户群体不一样，手机使用的APK也会不一样，并且须要大量反编译三方应用，投成本也很高

3.2.3 利用系统Service机制拉活

Service 的 onStartCommand 返回值，当返回值为 START_STICKY 和 START_REDELIVER_INTENT 时，服务会自动重启，可是 Service 在短期内被杀死5次，则再也不拉起

3.2.4 利用 JobScheduler

JobScheduler 为Android 5.0以后引入的，本质是系统定时任务，若是进程被杀，任务仍然会被执行，在7.0后 JobScheduler 添加了限制，最低间隔为15分钟。可是仍是有几率出现存在进程死亡后，不触发的状况。

3.2.5 利用 AlarmManager

本质上也是经过设置定时任务，若是进程被杀，任务也仍然会被执行，此时就能够拉活进程。Doze模式会影响 AlarmManager 不被触发，此时要用setAlarmClock来设置。一样有几率出现存在进程死亡后，不触发的状况。

并且Android 9.0的谷歌原生手机，多了一个功能，就是显示手机下一个的闹钟时间是几点，若是用到了这种保活方式，用户也注意到了这个功能，那么闹钟上的时间会暴露有应用在明目张胆的保活

3.2.6 利用帐号同步机制

Android 系统的帐号同步机制会按期同步帐号进行，该方案目的在于利用同步机制进行进程的拉活。添加帐号和设置同步周期的代码便可，谷歌商店会查这种保活方案，后果不知，建议慎用

代码参考连接

3.2.7 利用Native进程拉活

利用 Linux 中的 fork 机制建立 Native 进程，在 Native 进程中监控主进程的存活，当主进程挂掉后，在 Native 进程中当即对主进程进行拉活。

感知主进程死亡：在主进程中建立一个监控文件，而且在主进程中持有文件锁。在拉活进程启动后申请文件锁将会被堵塞，一旦能够成功获取到锁，说明主进程挂掉，便可进行拉活。

拉活主进程：经过 Native 进程拉活主进程的部分代码以下，即经过 am 命令进行拉活。经过指定“–include-stopped-packages”参数来拉活主进程处于 forestop 状态的状况。

可是 Android5.0 以上手机 会依次杀死全部进程，也会将 Native 进程杀死

3.2.8 利用双进程拉活

启动两个Service A和B，处于不一样进程，而后在A的 onStartCommand 中绑定 B，B也在A的 onStartCommand 中绑定A，经过 ServiceConnection 的回调 onServiceDisconnected ，当绑定断开时，说明另外一个进程死亡，因而从新启动死亡的进程（Service），6.0以后保活效果也开始有限，与Natvie进程遇到的问题类似，只有在依次杀死进程的间隔中，有概率拉活

3.3 其余拉活方式

3.3.1 利用系统官方的服务，或者三方服务

1. 国外可使用 Firebase 的云端推送
2. 国内可使用极光推送等服务

主要仍是依靠，本身应用与其余应用使用相同SDK，而后相同的SDK里面内置了相互唤醒功能，具体保活的效果也是依赖三方SDK的能力