简单回顾下:在之前的保活第一篇中,主要介绍了设置模块关于保活的一些作用;在第二篇中,主要介绍了在关闭activity和系统退出的时候,系统是如何反应的,我们能否利用这些机制创造出更多的保活条件;
这篇主要介绍下在4.0~8.0系统当中,我们可以利用的保活方案
1: 由第一篇可知,如果设备允许后台程序的数量变多,或者允许保留后台程序,那么service是不是就可以存活更长时间?
答案: 否;
2:常规方案:普通service修改onstartcommand,onDestroy等
低版本效果还可以,在5.0以上版本存活起来就比较短了
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
return START_STICKY;
}
@Override
public void onDestroy() {
// TODO Auto-generated method stub
super.onDestroy();
gcEnv();
}
private void gcEnv() {
Intent serviceTo = new Intent();
serviceTo.setClass(this, MyService.class);
this.startService(serviceTo);
}
3:双service,即我们常说的利用android framework层notification的一个漏洞,提高service的优先级;一个service展示一个通知,另一个service将那个通知隐藏;
低版本里面是可以的,但是google很快也修复了这个漏洞
4: 守护进程保活,即native方式保活;即通过JNI的方式在底层hork一个进程
这个方案兼容性不高,效果不好
5: 使用jobservice的方式
随着android版本的更新,google越来越推荐使用jobservice的方式来进行后台运行,jobservice我测试过,保活效果并没有多么好,而且也没法做到低版本兼容;
6: 开启一个像素的activity,并监听Home键,当拦截到点击Home键的时候,展示一个像素的activity,这样提高组件的优先级,同时需要注意设置activity的task的亲和性,这样点击back键才会像正常launcher那样
7:后台播放一段空白的音频或者视频
这种方式耗电量会增加很多
8: 通过系统闹钟的方式,每隔固定时间就启动service
private void runService() {
Intent intent = new Intent(this, MyService.class);
PendingIntent mAlarmPIent = PendingIntent.getService(this, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
// long firstTime = System.currentTimeMillis();
// firstTime表示第1次运行时要等待的时间,也就是执行延迟时间,单位是毫秒。
long firstTime = SystemClock.elapsedRealtime() + INTERVAL_THREE_DAYS;
AlarmManager mAlarmManager = (AlarmManager) this.getSystemService(Context.ALARM_SERVICE);
if (mAlarmManager == null) {
return;
}
mAlarmManager.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, INTERVAL_THREE_DAYS, mAlarmPIent);
}
9:另外在三星的设备中,在其packageinstaller上开启自动运行功能,service存活时间明显增强
综述:为了更好的做到service保活,我们的方案是
一: 如果手机版本低于5.0,我们采用的方案是
方案2 + 方案3 + 方案6 + 方案8
二: 如果手机版本高于等于5.0,我们直接抛弃其他方案,只使用jobservice
其实如果不是核心应用必要,我们不需要再后台保持长时间存活的service,如果真有这样的需求,最好的方法还是添加白名单