这个文章只是Android历史保活方案总结，没有什么特别的参考意义，Android 已经到10了，100%保活本身就已经不复存在，文章中所有的方案，都是有可能有用，毕竟4.4还有人用，至于要不用可以自己参考，毕竟当PM就是让你应用不死，你能不写代码吗？
保活通常分为2种方案，一种为提高进程优先级，防止被杀，另一种为进程被杀死拉活
1. 进程优先级
Android系统会尽可能的保持应用进程，但是当需要建立新的进程或者运行更重要的进程，便会回收优先级低一些的进程,这个就是lowmemorykiller的工作。而进程的优先级其实就是 /proc/pid/oom_adj
进程的优先级排序
- 前台进程（Foreground Process）
- 可见进程(Visible Process)
- 服务进程(Service Process)
- 后台进程(Background Process)
- 空进程(Empty Process)
前台进程
- 拥有 用户正在交互的 Activity(正处于 onResume中)
- 拥有 Service绑定到正处于 onResume的 Activity
- 拥有 Service 调用 startForeground 成为前台服务
- 拥有 Service 正在执行生命周期回调（onCreate、onStart、onDestroy）
- 拥有 BroadcastReceiver 正在执行 onReceive
可见进程
- 拥有 Activity 处于 onPause ，此时可见但是不可操作
- 拥有 Service 绑定到正处于 onPause的 Activity
服务进程
- 仅通过 startService 启动的 Service
后台进程
- 拥有 Activity 处于 onStop
空进程
- 不拥有任何活动的组件进程
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 利用系统官方的服务，或者三方服务
- 国外可以使用 Firebase 的云端推送
- 国内可以使用极光推送等服务
主要还是依靠，自己应用与其他应用使用相同SDK，然后相同的SDK里面内置了相互唤醒功能，具体保活的效果也是依赖三方SDK的能力
