探讨Android6.0及以上系统APP常驻内存(保活)实现-复活篇
(转载请声明出处:http://blog.csdn/andrexpert/article/details/75174586)
APP保活系列(最高支持到Android 7.0)
(1) 探讨一种新型的双进程守护应用保活方法
(2) 探讨Android6.0及以上系统APP常驻内存(保活)实现-争宠篇
(3) 探讨Android6.0及以上系统APP常驻内存(保活)实现-复活篇
APP常驻内存(保活),又旧事重提,距离上一次的研究亦有半年有余。最近,用户反馈说多进程守护方案在华为Mate8(7.0)保活效果不是很好,有时候还是不能及时收到消息,于是,又带着怀疑的眼光,重新找回原来的代码进行测试,顺便分析了市场上主流运动类APP保活方法(微信、手Q就算了,富人家的孩子,不具代表性),同时也对系统对内存中APP的管理规则进行了进一步探索。本文便是对最近一周的探索、学习、测试的总结之一,以备将来不时之需。
一、APP复活核心思想归纳
随着AlarmManager唤醒、native进程拉起等方式的失效,APP常驻内存的时代将不复存在,尤其是当APP进程被杀死后,基本很难将其拉起。从用户的角度来讲,这是一种很好的发展,而这一切应该归功于谷歌和各大厂商不断追求良好的用户体验;从开发者的角度来说,尤其是即时通信类应用,这将是毁灭性打击。如果用户使用你的聊天软件,但在使用过程中总是不能及时收到对方的消息,那将是一种什么样的体验,因此,厂商"白名单"便应运而生了。正是因为如此,本文探讨的相关方案不可能保证在任何时候,或者任何机型能够唤醒,一切都是相对存在的。
接下来,我们先了解下哪些情况下进程会被杀死:
1. LowMemoryKiller:这种情况是触发了系统进程管理机制,通过系统会参照当前系统资源情况和oom_adj值来回收进程,oom_adj越大,越容易被杀死;
2. 第三方清理软件:杀死oom_adj值大于4的进程,如果拥有root权限,理论可杀死所有进程;
3. 厂商杀进程:可杀所有进程
4. Force-stop:可杀所有非系统进程
二、APP复活方案探讨
1. 使用JobScheduler
JobScheduler是谷歌在Android 5.0引入的一个能够执行某项任务的API,它允许APP在将来达到一定条件时执行指定的任务。通常情况下,即使APP被强制停止,预定的任务仍然会被执行。JobScheduler工作原理:
首先在一个实现了JobService的子类的onStartJob方法中执行这项任务,使用JobInfo的Builder方法来设定条件并和实现了JobService的子类的组件名绑定,然后调用系统服务JobScheduler的schedule方法。这样,即便在执行任务之前应用程序进程被杀,也不会导致任务不会执行,因为系统服务JobScheduler会使用bindServiceAsUser的方法把实现了JobService的子类服务启动起来,并执行它的onStartJob方法
(1) AliveJobService.java
/**JobService,支持5.0以上forcestop依然有效
*
* Created by jianddongguo on 2017/7/10.
*/
@TargetApi(21)
public class AliveJobService extends JobService {
private final static String TAG = "KeepAliveService";
// 告知编译器,这个变量不能被优化
private volatile static Service mKeepAliveService = null;
public static boolean isJobServiceAlive(){
return mKeepAliveService != null;
}
private static final int MESSAGE_ID_TASK = 0x01;
private Handler mHandler = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
// 具体任务逻辑
if(SystemUtils.isAPPALive(getApplicationContext(), Contants.PACKAGE_NAME)){
Toast.makeText(getApplicationContext(), "APP活着的", Toast.LENGTH_SHORT)
.show();
}else{
Intent intent = new Intent(getApplicationContext(), SportsActivity.class);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Toast.makeText(getApplicationContext(), "APP被杀死,重启...", Toast.LENGTH_SHORT)
.show();
}
// 通知系统任务执行结束
jobFinished( (JobParameters) msg.obj, false );
return true;
}
});
@Override
public boolean onStartJob(JobParameters params) {
if(Contants.DEBUG)
Log.d(TAG,"KeepAliveService----->JobService服务被启动...");
探讨Android6.0及以上系统APP常驻内存(保活)实现-复活篇
(转载请声明出处:http://blog.csdn/andrexpert/article/details/75174586)
APP保活系列(最高支持到Android 7.0)
(1) 探讨一种新型的双进程守护应用保活方法
(2) 探讨Android6.0及以上系统APP常驻内存(保活)实现-争宠篇
(3) 探讨Android6.0及以上系统APP常驻内存(保活)实现-复活篇
APP常驻内存(保活),又旧事重提,距离上一次的研究亦有半年有余。最近,用户反馈说多进程守护方案在华为Mate8(7.0)保活效果不是很好,有时候还是不能及时收到消息,于是,又带着怀疑的眼光,重新找回原来的代码进行测试,顺便分析了市场上主流运动类APP保活方法(微信、手Q就算了,富人家的孩子,不具代表性),同时也对系统对内存中APP的管理规则进行了进一步探索。本文便是对最近一周的探索、学习、测试的总结之一,以备将来不时之需。
一、APP复活核心思想归纳
随着AlarmManager唤醒、native进程拉起等方式的失效,APP常驻内存的时代将不复存在,尤其是当APP进程被杀死后,基本很难将其拉起。从用户的角度来讲,这是一种很好的发展,而这一切应该归功于谷歌和各大厂商不断追求良好的用户体验;从开发者的角度来说,尤其是即时通信类应用,这将是毁灭性打击。如果用户使用你的聊天软件,但在使用过程中总是不能及时收到对方的消息,那将是一种什么样的体验,因此,厂商"白名单"便应运而生了。正是因为如此,本文探讨的相关方案不可能保证在任何时候,或者任何机型能够唤醒,一切都是相对存在的。
接下来,我们先了解下哪些情况下进程会被杀死:
1. LowMemoryKiller:这种情况是触发了系统进程管理机制,通过系统会参照当前系统资源情况和oom_adj值来回收进程,oom_adj越大,越容易被杀死;
2. 第三方清理软件:杀死oom_adj值大于4的进程,如果拥有root权限,理论可杀死所有进程;
3. 厂商杀进程:可杀所有进程
4. Force-stop:可杀所有非系统进程
二、APP复活方案探讨
1. 使用JobScheduler
JobScheduler是谷歌在Android 5.0引入的一个能够执行某项任务的API,它允许APP在将来达到一定条件时执行指定的任务。通常情况下,即使APP被强制停止,预定的任务仍然会被执行。JobScheduler工作原理:
首先在一个实现了JobService的子类的onStartJob方法中执行这项任务,使用JobInfo的Builder方法来设定条件并和实现了JobService的子类的组件名绑定,然后调用系统服务JobScheduler的schedule方法。这样,即便在执行任务之前应用程序进程被杀,也不会导致任务不会执行,因为系统服务JobScheduler会使用bindServiceAsUser的方法把实现了JobService的子类服务启动起来,并执行它的onStartJob方法
(1) AliveJobService.java
/**JobService,支持5.0以上forcestop依然有效
*
* Created by jianddongguo on 2017/7/10.
*/
@TargetApi(21)
public class AliveJobService extends JobService {
private final static String TAG = "KeepAliveService";
// 告知编译器,这个变量不能被优化
private volatile static Service mKeepAliveService = null;
public static boolean isJobServiceAlive(){
return mKeepAliveService != null;
}
private static final int MESSAGE_ID_TASK = 0x01;
private Handler mHandler = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
// 具体任务逻辑
if(SystemUtils.isAPPALive(getApplicationContext(), Contants.PACKAGE_NAME)){
Toast.makeText(getApplicationContext(), "APP活着的", Toast.LENGTH_SHORT)
.show();
}else{
Intent intent = new Intent(getApplicationContext(), SportsActivity.class);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Toast.makeText(getApplicationContext(), "APP被杀死,重启...", Toast.LENGTH_SHORT)
.show();
}
// 通知系统任务执行结束
jobFinished( (JobParameters) msg.obj, false );
return true;
}
});
@Override
public boolean onStartJob(JobParameters params) {
if(Contants.DEBUG)
Log.d(TAG,"KeepAliveService----->JobService服务被启动...");