本文介绍的方案都是无需用户主动开启权限的。如果需要用户主动开启权限或者加白名单之类的话保活的意义就不大了，毕竟用户不大可能主动原因让app一直在后台运行
常规的方案
OnePixelActivity
1，监听SCREEN_OFF启动一个像素的Activity，灭屏的时候用户看不到这个界面，目的降低App的oom_dj值。
2，务必监听SCREEN_ON的时候关闭一个像素activity 要不然就会出现用户打开手机点击屏幕没反应。用户会抓狂的
前台服务
启动一个前台服务在状态栏有个通知。目的降低App的oom_dj值
Accout同步
利用账号同步服务拉起应用。并不能阻止force-stop干掉进程
用法参考:https://cloud.tencent.com/developer/article/2248389
无声音乐
app内置一个没有声音的音频到res/raw/下面，然后通过mediaplayer一直循环播放 目的是一键清理不会清理。效果可以但是并不能阻止force-stop干掉进程
监听系统广播
监听一堆系统发出的广播。目的是可以拉活应用。实测基本没啥用
防止休眠和断网
灭屏的情况下防止app休眠和断网 (实测有些效果但是并不能保活)
try {
var powerManager =
context.getSystemService(Context.POWER_SERVICE) as? PowerManager
val wakeLock =
powerManager?.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "WakeLock")
wakeLock?.acquire()
val wifiLock =
context.applicationContext.getSystemService(Context.WIFI_SERVICE) as? WifiManager
var wifiInfo = wifiLock?.createWifiLock(
WifiManager.WIFI_MODE_FULL_HIGH_PERF,
"MyWifiLockTag"
)
wifiInfo?.acquire()
} catch (e: Exception) {
}
workmanager jobservice
这两个可以开启轮询的定时任务。实测对保活效果不明显
Alarmmanager
开启精确的轮询任务，比较耗电 实测保活效果一般 休眠后任务会被挂起
利用Native进程拉活
持有不同进程的文件锁 如果某个进程被kill在jni里面出发Instrumentation拉活应用(9.0以下部分机型有效)
利用系统Service机制拉活
将 Service 设置为 START_STICKY，利用系统机制在 Service 挂掉后自动拉活 (几乎没啥用)
双service
启动两个service且互相绑定 其中一个进程挂了另外一个可以强行拉活(8.0以后几乎没用)
通过接入push
实测firebase 的push的确是能拉活进程 但是应用被force-stop后就无能为力了。可以接入热门应用常用的push 这样其他应用被打开后有机会把你的应用也拉活
可以通过app之间相互拉活
这个不用介绍了把
在最近任务中隐藏app
可以减少用户注定杀死app的机会
android:excludeFromRecents="true"
非常规策略
为了防止被滥用 暂不开源