Android 如何进行进程保活

每一个 Android 应用启动后至少对应一个进程，有的是多个进程，而且主流应用中多个

进程的应用比例较大

对于任何一个进程，我们都可以通过 adb shell ps|grep <package_name>的方式来查看

它的基本信息
Android 中的进程跟封建社会一样，分了三流九等，Android 系统把进程的划为了如下

几种（重要性从高到低），网上多位大神都详细总结过（备注：严格来说是划分了 6 种）。

场景：

1某个进程持有一个正在与用户交互的 Activity 并且该 Activity 正处于 resume 的

状态。

2某个进程持有一个 Service，并且该 Service 与用户正在交互的 Activity 绑定。

3某个进程持有一个 Service，并且该 Service 调用 startForeground()方法使之位于前台运行。

4某个进程持有一个 Service，并且该 Service 正在执行它的某个生命周期回调方法，比如 onCreate()、 onStart()或 onDestroy()。

5某个进程持有一个 BroadcastReceiver，并且该 BroadcastReceiver 正在执行其onReceive()方法。用户正在使用的程序，一般系统是不会杀死前台进程的，除非用户强制停止应用或者系统内存不足等极端情况会杀死。

场景：

1拥有不在前台、但仍对用户可见的 Activity（已调用 onPause()）。

2拥有绑定到可见（或前台）Activity 的 Service

用户正在使用，看得到，但是摸不着，没有覆盖到整个屏幕,只有屏幕的一部分可见进程

不包含任何前台组件，一般系统也是不会杀死可见进程的，除非要在资源吃紧的情况下，

要保持某个或多个前台进程存活

场景

1某个进程中运行着一个 Service 且该 Service 是通过 startService()启动的，与用户看见的界面没有直接关联。

在内存不足以维持所有前台进程和可见进程同时运行的情况下，服务进程会被杀死

场景：

在用户按了"back"或者"home"后,程序本身看不到了,但是其实还在运行的程序，

比如 Activity 调用了 onPause 方法系统可能随时终止它们，回收内存

场景：

某个进程不包含任何活跃的组件时该进程就会被置为空进程，完全没用,杀了它只有好处没坏处,第一个干它!

上面是进程的分类，进程是怎么被杀的呢？系统出于体验和性能上的考虑，app 在退到

后台时系统并不会真正的 kill 掉这个进程，而是将其缓存起来。打开的应用越多，后台缓存的进程也越多。在系统内存不足的情况下，系统开始依据自身的一套进程回收机制

来判断要 kill 掉哪些进程，以腾出内存来供给需要的 app, 这套杀进程回收内存的机制

就叫 Low Memory Killer。那这个不足怎么来规定呢，那就是内存阈值，我们可以使用

cat /sys/module/lowmemorykiller/parameters/minfree 来查看某个手机的内存阈值。
其实系统在进程回收跟内存回收类似也是有一套严格的策略，可以

自己去了解，大概是这个样子的，oom_adj 越大，占用物理内存越多会被最先 kill 掉，OK，那么现在对于进程如何保活这个问题就转化成，如何降低 oom_adj 的值，以及如

何使得我们应用占的内存最少。

据说这个是手 Q 的进程保活方案，基本思想，系统一般是不会杀死前台进程的。所以要

使得进程常驻，我们只需要在锁屏的时候在本进程开启一个 Activity，为了欺骗用户，

让这个 Activity 的大小是 1 像素，并且透明无切换动画，在开屏幕的时候，把这个 Activity

关闭掉，所以这个就需要监听系统锁屏广播，我试过了，的确好使，如下。
如果直接启动一个 Activity，当我们按下 back 键返回桌面的时候，oom_adj 的值是 8，

上面已经提到过，这个进程在资源不够的情况下是容易被回收的。现在造一个一个像素

的 Activity。
为了做的更隐藏，最好设置一下这个 Activity 的主题，当然也无所谓了
在屏幕关闭的时候把 LiveActivity 启动起来，在开屏的时候把 LiveActivity 关闭掉，所以

要监听系统锁屏广播，以接口的形式通知 MainActivity 启动或者关闭 LiveActivity。

现在 MainActivity 改成如下

按下 back 之后，进行锁屏，现在测试一下 oom_adj 的值
果然将进程的优先级提高了。

但是还有一个问题，内存也是一个考虑的因素，内存越多会被最先 kill 掉，所以把上面

的业务逻辑放到 Service 中，而 Service 是在另外一个 进程中，在 MainActivity 开启这

个服务就行了，这样这个进程就更加的轻量，
OK，通过上面的 *** 作，我们的应用就始终和前台进程是一样的优先级了，为了省电，

系统检测到锁屏事件后一段时间内会杀死后台进程，如果采取这种方案，就可以避免了

这个问题。但是还是有被杀掉的可能，所以我们还需要做双进程守护，关于双进程守护，

比较适合的就是 aidl 的那种方式，但是这个不是完全的靠谱，原理是 A 进程死的时候，

B 还在活着，B 可以将 A 进程拉起来，反之，B 进程死的时候，A 还活着，A 可以将 B

拉起来。所以双进程守护的前提是，系统杀进程只能一个个的去杀，如果一次性杀两个，

这种方法也是不 OK 的。

事实上

那么我们先来看看 Android50 以下的源码，ActivityManagerService 是如何关闭在应用

退出后清理内存的
在应用退出后，ActivityManagerService 不仅把主进程给杀死，另外把主进程所属的进

程组一并杀死，这样一来，由于子进程和主进程在同一进程组，子进程在做的事情，也

就停止了。所以在 Android50 以后的手机应用在进程被杀死后，要采用其他方案。

这种大部分人都了解，据说这个微信也用过的进程保活方案，移步微信 Android 客户端

后台保活经验分享，这方案实际利用了 Android 前台 service 的漏洞。

原理如下

对于 API level < 18 ：调用 startForeground(ID， new Notification())，发送空的

Notification ，图标则不会显示。

对于 API level >= 18：在需要提优先级的 service A 启动一个 InnerService，两个服务

同时 startForeground，且绑定同样的 ID。Stop 掉 InnerService ，这样通知栏图标即

被移除。

public class KeepLiveService extends Service{

public static final int NOTIFICATION_ID=0x11; 

public KeepLiveService() {

}

@Override

public IBinder onBind(Intent intent){

throw new UnsupportedOperationException("Not yet implemented");

 }

 @Override 

public void onCreate() {

 superonCreate(); //API 18 以下，直 接发 送 Notification 并 将 其 置 为 前 台

if(BuildVERSIONSDK_INT<BuildVERSION_CODESJELLY_BEAN_MR2){

startForeground(NOTIFICATION_ID,new Notification()); 

} else { //API 18 以上，发送 Notification 并将其置为前台后，启动 InnerService

NotificationBuilder builder=new NotificationBuilder(this);

buildersetSmallIcon(Rmipmapic_launcher);

startForeground(NOTIFICATION_ID, builderbuild());

 startService(new Intent(this, InnerServiceclass));

 }

 }

 public class InnerService extends Service{

 @Override public IBinder onBind(Intent intent) {

 return null;

 } 

@Override public void onCreate() {

 superonCreate(); //发送与 KeepLiveService中 ID 相同的 Notification，然后将其取消并取消自己的前台显示

 NotificationBuilder builder = new NotificationBuilder(this);

buildersetSmallIcon(Rmipmapic_launcher);startForeground(NOTIFICATION_ID,

builderbuild());

new Handler()postDelayed(new Runnable() { 

@Override public void run() { 

stopForeground(true);

 NotificationManager manager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);

managercancel(NOTIFICATION_ID); 

stopSelf();

 }

 },

100);

 }

 }

 }

在没有采取前台服务之前，启动应用，oom_adj 值是 0，按下返回键之后，变成 9（不

同 ROM 可能不一样）

相互唤醒的意思就是，假如你手机里装了支付宝、淘宝、天猫、UC 等阿里系的 app，

那么你打开任意一个阿里系的 app 后，有可能就顺便把其他阿里系的 app 给唤醒了。

这个完全有可能的。此外，开机，网络切换、拍照、拍视频时候，利用系统产生的广播

也能唤醒 app，不过 Android N 已经将这三种广播取消了。

如果应用想保活，要是 QQ，微信愿意救你也行，有多少手机上没有 QQ，微信呢？或

者像友盟，信鸽这种推送 SDK，也存在唤醒 app 的功能。

拉活方法

JobSheduler是作为进程死后复活的一种手段，

native进程方式最大缺点是费电，Native

进程费电的原因是感知主进程是否存活有两种实现方式，在 Native 进程中通过死循环

或定时器，轮训判断主进程是否存活，当主进程不存活时进行拉活。其次 50 以上系统

不支持。 但是 JobSheduler 可以替代在 Android50 以上 native 进程方式，这种方式即

使用户强制关闭，也能被拉起来，亲测可行。

JobSheduler@TargetApi(BuildVERSION_CODESLOLLIPOP) 

public class MyJobService extends JobService {

 @Override

 public void onCreate() {

 superonCreate();

 startJobSheduler();

 }

public void startJobSheduler() { 

try {

 JobInfoBuilder builder = new JobInfoBuilder(1,new ComponentName(getPackageName(), MyJobServiceclassgetName()));

buildersetPeriodic(5); buildersetPersisted(true); JobScheduler jobScheduler =(JobScheduler)

thisgetSystemService(ContextJOB_SCHEDULER_SERVICE);

jobSchedulerschedule(builderbuild());

}

catch

(Exception ex)

{ exprintStackTrace(); } }

 @Override 

public boolean onStartJob(JobParameters jobParameters) {

 return false; 

} @Override public boolean onStopJob(JobParameters jobParameters) { 

return false; 

}

 }

这个是系统自带的，onStartCommand 方法必须具有一个整形的返回值，这个整形的返

回值用来告诉系统在服务启动完毕后，如果被 Kill，系统将如何 *** 作，这种方案虽然可

以，但是在某些情况 or 某些定制 ROM 上可能失效，我认为可以多做一种保保守方案。
1START_STICKY

如果系统在 onStartCommand 返回后被销毁，系统将会重新创建服务并依次调用

onCreate 和 onStartCommand（注意：根据测试 Android233 以下版本只会调用

onCreate 根本不会调用 onStartCommand，Android40 可以办到），这种相当于服务

又重新启动恢复到之前的状态了）。

2START_NOT_STICKY

如果系统在 onStartCommand 返回后被销毁，如果返回该值，则在执行完

onStartCommand 方法后如果 Service 被杀掉系统将不会重启该服务

3START_REDELIVER_INTENT

START_STICKY 的兼容版本，不同的是其不保证服务被杀后一定能重启。

4相比与粘性服务与系统服务捆绑更厉害一点，这个来自爱哥的研究，这里说的系统服务

很好理解，比如 NotificationListenerService，NotificationListenerService 就是一个监听

通知的服务，只要手机收到了通知，NotificationListenerService 都能监听到，即时用户

把进程杀死，也能重启，所以说要是把这个服务放到我们的进程之中，那么就可以呵呵

了
所以你的应用要是有消息推送的话，那么可以用这种方式去欺骗用户。

最近针对我们项目中app经常收不到推送的问题作了一些处理，增加app的保活管理。我们知道当安卓进程退到后台之后，很容易被系统杀死，这个时候推送消息一般都是收不到的。我也观察了一些比较主流的app,像同花顺，钉钉，甚至是支付宝我都很少在后台收到过消息，尤其是支付宝计步功能老是不准，很有可能就是这种问题导致的

当然没有百分之百可以实现保活的解决方案，即便是从ndk层面去进行，但至少我们要尽一些努力，我采用的是双进程守护+1像素Activity的实现方式

开启两个service，分别在两个进程中运行，启动一个service时，通过aidl的方式将它和另一个service绑定在一起，当其中一个service被杀掉的时候，另一个service中重新将它启动

service1启动绑定service2

service1和service2的链接断开时，说明service2被杀死，这时重新绑定

service2绑定service1的逻辑同上

这样一来，基本上在一定程度上可以保证app常驻内存了，保险起见，我们再加一层保护，创建两个JobService
分别位于上边两个进程中（安卓50以上适用），开启一个轮巡任务不断的检查service存活情况，如果不在了，启动它，注意JobService需要权限

监听系统锁屏消息，在屏幕锁定的时候开启一个Activity，这个Activity只有一个像素大小，当屏幕开启的时候再关闭这个Activity，达到app一直位于前台进程的目的，提高进程的优先级，降低系统杀死app的概率,在这个Activity启动时设置app只有一个像素大小，既可以减少占用空间，也可以防止开锁屏期间被用户发现这个奇怪的页面

在AndroidManifest中配置

GuardService1

GuardService2

JobWakeUpService1

JobWakeUpService2

DaemonActivity

AndroidManifest配置

增加一个管理类GuardAppManager一键启动和关闭

开启守护

关闭守护

JobScheduler 主要用于在未来某个时间下满足一定条件时触发执行某项任务的情况，涉及的条件可以是网络、电量、时间等，例如执行特定的网络、是否只在充电时执行任务等。

JobScheduler类负责将应用需要执行的任务发送给框架，以备对该应用Job的调度，是一个系统服务，可以通过如下方式获取：

JobInfo是传递给JobScheduler类的数据容器，它封装了针对调用应用程序调度任务所需的各种约束，也可以认为一个JobInfo对象对应一个任务，JobInfo对象通过JobInfoBuilder创建。它将作为参数传递给JobScheduler：

JobInfoBuilder是JobInfo的一个内部类，用来创建JobInfo的Builder类。

JobService是JobScheduler最终回调的端点，JobScheduler将会回调该类中的onStartJob()开始执行异步任务。它是一个继承于JobService的抽象类，做为系统回调执行任务内容的终端，JobScheduler框架将通过bindService()方式来启动该服务。因此，用户必须在应用程序中创建一个JobService的子类，并实现其onStartJob()等回调方法，以及在AndroidManifestxml中对它授予如下权限：

注意在AndroidManifestxml中添加权限

当任务开始时会执行onStartJob(JobParameters params)方法，如果返回值是false，则系统认为这个方法返回时，任务已经执行完毕。如果返回值是true，那么系统认为这个任务正要被执行，执行任务的重担就落在了你的肩上。当任务执行完毕时你需要调用jobFinished(JobParameters params, boolean needsRescheduled)来通知系统。

当系统接收到一个取消请求时，系统会调用onStopJob(JobParameters params)方法取消正在等待执行的任务。很重要的一点是如果onStartJob(JobParameters params)返回false，那么系统假定在接收到一个取消请求时已经没有正在运行的任务。换句话说，onStopJob(JobParameters params)在这种情况下不会被调用。

需要注意的是这个Job Service运行在主线程，这意味着你需要使用子线程，handler，或者一个异步任务来运行耗时的 *** 作以防止阻塞主线程。

Google官方的Sample： >