android进程保活,android10进程保活

Android中的保活机制

Android中的保活是一个永不过时的话题，因为每一个APP都希望能在后台不停的运行去搜集用户数据，在Android 系统处于较低版本的时候（目前最新版本为12，较低版本指的是8以下），很多APP借助于系统层面的漏洞研发出了各种保活的方法，但是随着Android 版本的不断更新，过往的保活方法渐渐失效，Android中的保活成为了一个越来越难办到的事情，但是我认为这是一个好事，如非这样你永远不知道你的手机后台到底有多少APP背着你干了多少事情。当然，系统的事情不是我们能掌控的了的。那么，我们先来看看以前为了保活都有哪些手段。

手段一：在Service的onStartCommand方法中返回****START_STICKY****（****亲测无效****）

在Service的onStartCommand方法中返回键有下面几种可供选择：

（1）START_STICKY：如果Service所在的进程，在执行了onStartCommand方法后，被清理了，那么这个Service会被保留在已开始的状态，但是不保留传入的Intent，随后系统会尝试重新创建此Service。

（2）START_NOT_STICKY：如果Service所在的进程，在执行了onStartCommand方法后，被清理了，则系统不会重新启动此Service。

（3）START_REDELIVER_INTENT：如果Service所在的进程，在执行了onStartCommand方法后，被清理了，则结果和START_STICKY一样，也会重新创建此Service并调用onStartCommand方法。不同之处在于，如果是返回的是START_REDELIVER_INTENT ，则重新创建Service时onStartCommand方法会传入之前的intent。

手段二：在清单文件里面设置优先级****（****亲测无效****）

手段三：在Service即将销毁的时候重新启动****（****亲测无效****）

手段四：借助AIDL使用双进程保活****（****亲测无效****）

首先创建一个AIDL文件

创建本地服务

创建远程服务：

最后在清单文件声明：

手段五：1像素的Activity让应用在熄屏后保活****（****亲测无效****）

具体怎么实现可以参照这篇文章

u;/u

运行一段时间后系统会自动杀死整个APP

手段六：****开启前台服务（亲测有效）

在Service的onCreate方法中开启前台服务

当然，APP保活的方式方法远不止这些，但是随着Android 系统的不断优化，保活现在越来越不太现实，但是我们可以尽量提高我们APP的优先级让系统不轻易杀死我们的APP，这一点还是可以办到的。

相关问答

Q1: Android保活方案

系统出于性能和体验上的考虑，APP退到后台后并不会真正的kill、掉进程，而是将其缓存起来。

打开的应用越多，缓存的应用也就越多，在系统进程不足的情况下，系统根据自己的一套进程回收机制，来判断kill掉哪些进程，以腾出进程给需要的app，这套进程回收机制叫做low memory killer。

内存阀值，每个手机都不一样，当可用内存小于该值得时候，Android就会杀死对应优先级得进程。

进程的优先级通过oom_adj来判断，oom_adj取值如下：

0-3是比较安全的oom_adj一般不会被系统杀死的，所以我们只要保证自己的app oom_adj在0-3之间就可以了。

可以通过adb命令：cat /proc /4181/oom_adj来查看自己app的oom_adj的值

4181是进程号

原理：手机关闭屏幕的时候，偷偷创建一个activity，让应用成为前台进程，打开屏幕时关闭activity，这样用户就不会发现什么异常，我们知道前台应用的oom_adj为0是不会被杀死的，这样就达到看保活的目的。

缺点：activity不够干净，只有在息屏的时候才生效，存在局限性比较大，而且谷歌原生的系统息屏的时候不会清理进程，但是现在很多厂商会在息屏的时候清理内存，所以本方案的可行性不高，可以作为了解。

保活原理：启动一个前台服务，从而拉高整个应用的优先级。

因为一旦通知被用户干掉那么该保活方案就不好用了，所以通知图标存在与否是该方案是否可行的关键。

但是该方案是谷歌官方承认的保活方案，所以可行性还是很高的。

需要适配

API18通知图标不会显示

API=18API26可以启动双服务，绑定同样的D,然后stop

这个方法的原理是8.0系统之前会根据服务的id来判断通知，那么第二个id设置跟第一个相同，然后自杀，系统就会误认为此通知已死就不会通知了，那么通知栏上面就不会显示

API=26后暂时没有方式能够隐藏

8.0之后不可以创建同样的id的通知，所以此隐藏通知的方法就不好用了，当然了，通知显示与否不是该方案成功的评判标准，所以说还是可以用的。

在发生特定系统事件时,系统会发出广播,通过在 Androidmanifest中静

态注册对应的广播监听器,即可在发生响应事件时拉活

但是从 android7.0开始,对广播进行了限制,而且在8.0更加严格该方法就不适用了。

有多个app在用户设备上安装,只要开启其中一个就可以将其他的app也拉

活。比如手机里装了手Q、QQ空间、兴趣部落等等,那么打开任意一个app后,其

他的app也都会被唤醒

系统每隔一段时间会进行账户同步，当系统去账户同步的时候(不一定多长时间，跟系统有关)，我们就去拉活app，这个方案是非常稳定的，当然了国内的系统都是定制的，所以还是需要一定的适配的。

优点：系统唤醒，比较稳定

缺点：时间不能把控

JobScheduler允许在特定状态与特定时间间隔周期执行任务。可以利

用它的这个特点完成保活的功能，效果即开启一个定时器，与普通定时器不

同的是其调度由系统完成。

同样在某些ROM可能并不能达到需要的效果

Q2: Android后台进程保活方案

思想： 使用 Linux 中的 fork 机制创建 Native 进程，在 Native 进程中监控主进程的存活，当主进程挂掉后，在 Native 进程中立即对主进程进行拉活。

原理： 在 Android 中所有进程和系统组件的生命周期受 ActivityManagerService 的统一管理。Android5.0以下通过 Linux 的 fork 机制创建的进程为纯 Linux 进程，其生命周期不受 Android 的管理。

该方案主要适用于 Android5.0 以下版本手机。

该方案不受 forceclose 影响，被强制停止的应用依然可以被拉活，在 Android5.0 以下版本拉活效果非常好。

详情

对于 Android5.0 以上手机，系统虽然会将native进程内的所有进程都杀死，这里其实就是系统“依次”杀死进程时间与拉活逻辑执行时间赛跑的问题，如果可以跑的比系统逻辑快，依然可以有效拉起。在 某些 Android 5.0 以上机型有效。

详情

作者5.0以下系统用一个java进程和一个fork出来的纯native进程双管道互锁监听对方的状态，无论哪个被杀后都拉起第三个进程，第三个进程来拉活常驻进程，实现拉活。

5.0以上同一进程组的进程会被同时杀死，所以5.0以上使用双java进程在native层互锁文件实现监听，但任务管理器会在短时间内杀死所有进程，只能用反射提前初始化pacel，在进程被杀的时候和系统抢那几十毫秒的时间发送一个拉活的广播。用4个文件来让两个进程实现互锁来做监听，但实际效果很一般，测试了几个5.0以上的国产机型都不行，效果是根本监听不到进程被杀，目测原因是当任务管理器查杀进程的时候将所有的进程都挂起了，随后全部杀掉，并在一段时间内禁止进程启动。

PersistedJobService.java

BootReceiver.java静态注册BroadcastReceiver

注册，开机，网络切换、拍照、拍视频时候，利用系统产生的广播也能唤醒app，不过Android N已经将这三种广播取消了

常用的拉活权限

BackgroundService.java

WakeLock

作为前台应用运行，提高应用存活几率

service被关掉后自动启动

START_STICKY

如果系统在onStartCommand返回后被销毁，系统将会重新创建服务并依次调用onCreate和onStartCommand（注意：根据测试Android2.3.3以下版本只会调用onCreate根本不会调用onStartCommand，Android4.0可以办到），这种相当于服务又重新启动恢复到之前的状态了）。

START_NOT_STICKY

如果系统在onStartCommand返回后被销毁，如果返回该值，则在执行完onStartCommand方法后如果Service被杀掉系统将不会重启该服务。

START_REDELIVER_INTENT

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

service注册，权限设置为高优先级

KeepAliveService.java

注册，在新的独立进程内启动，适用5.0以下的原生系统，5.0以上同样会被杀死

他的局限性在于：

第一，用户会在系统设置的账户列表里面看到一个不认识的账户；

第二，同步的事件间隔是有限制的，最短1分钟，见源码，如果小雨60秒，置为60秒。而且各种国产机怎么改的源码我们未可知，是不是都能用仍然未可知；

第三，很致命，某些手机比如note3需要手动设置账户，你如何骗你的用户给你手动设置账户完了之后不卸载你；

第四，也很致命，必须联网！google提供这个组件是让你同步账户信息，不联网你同步个鬼，我们要保活，可以不联网不做事，但是不能不联网就死

集成三方推送平台sdk，友盟极光等

Q3: Android-保活

Low Memory Killer

打开的应用越多，后台缓存的进程也越多。因为系统出于体验和性能上的考虑，app在退到后台时系统并不会真正的kill掉这个进程，而是将其缓存起来。于是在系统内存不足的情况下，系统开始依据自身的一套进程回收机制来判断要kill掉哪些进程，以腾出内存来供给需要的app, 这套杀进程回收内存的机制就叫 Low Memory Killer。

进程的优先级（by:）

前台进程

用户正在使用的程序，一般系统是不会杀死前台进程的，除非用户强制停止应用或者系统内存不足等极端情况会杀死。

可见进程

用户正在使用，看得到，但是摸不着，没有覆盖到整个屏幕,只有屏幕的一部分可见进程不包含任何前台组件，一般系统也是不会杀死可见进程的，除非要在资源吃紧的情况下，要保持某个或多个前台进程存活施。

服务进程

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

后台进程

系统可能随时终止它们，回收内存。

空进程

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

内存阈值

内存阈值在不同的手机上不一样，一旦低于该值,Android便会杀死对应优先级的进程。一旦低于该值,Android便开始按逆序关闭进程。即优先级从最高的空进程开始，逆序关闭，直到内存足够。

如何判断进程的优先级？

通过 oom_adj 值，判断进程的优先级，不同手机的oom_adj 值可能不一样。

我们了解这个有什么用呢？PS：了解这个你才能想办法保证自己怎么不被杀掉。

网上的一些方案和自己认为有用的方案

1 开启一个像素Activity（伪前台进程）

在锁屏的时候在本进程开启一个Activity，为了欺骗用户，让这个Activity的大小是1像素，并且透明无切换动画，在开屏幕的时候，把这个Activity关闭掉，所以这个就需要监听系统锁屏广播。

我们的应用就始终和前台进程是一样的优先级了，为了省电，系统检测到锁屏事件后一段时间内会杀死后台进程，如果采取这种方案，就可以避免了这个问题，但是还是有被杀掉的可能。

Android5.0以下：

Process.killProcessQuiet(pid);

Android5.0以后：

Process.killProcessQuiet(app.pid);

Process.killProcessGroup(app.info.uid, app.pid);

应用退出后，ActivityManagerService不仅把主进程给杀死，另外把主进程所属的进程组一并杀死，这样一来，由于子进程和主进程在同一进程组，子进程在做的事情，也就停止了。

2 相互唤醒（广播唤醒）

相互唤醒的意思就是，假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app，那么你打开任意一个阿里系的app后，有可能就顺便把其他阿里系的app给唤醒了。这个完全有可能的。此外，开机，网络切换、拍照、拍视频时候，利用系统产生的广播也能唤醒app，不过Android N已经将这三种广播取消了。

3 JobSheduler机制保活（不推荐）

JobSheduler是作为进程死后复活的一种手段，native进程方式最大缺点是费电， Native 进程费电的原因是感知主进程是否存活有两种实现方式，在 Native 进程中通过死循环或定时器，判断主进程是否存活，当主进程不存活时进行拉活。其次5.0以上系统不支持。  但是JobSheduler可以替代在Android5.0以上native进程方式，这种方式即使用户强制关闭，部分厂商手机（如：华为）也能被拉起来，但AndroidN失效。

4 粘性服务与系统服务捆绑()

这个是系统自带的，onStartCommand方法必须具有一个整形的返回值，这个整形的返回值用来告诉系统在服务启动完毕后。Service的onStartCommand方法里返回 STATR_STICK，onDestory中start自启（准确的将算不上进程拉活，只能算service自启，force_stop后不能正常拉活）。

5 监听第三方app开放的静态广播（同2）

需要大量反编译app去找开放的静态广播，而且不保证长期有效，可能第三方开放广播在版本升级时改为私有广播，如果自己公司有多个app,可广播互相拉起。

6 NDK+Socket通过fork实现进程保活方案（）

实现进程守护实际是守护app的主要服务，当app主进程被系统kill时，主要服务也会杀死，守护进程将其唤醒。

实现原理图：

进程保活方案调研结果

未能实现真正意义上的进程保活。

光从保活这一点来说，绑定一个像素activity和循环一个无声的声音这种方法比较好，但是对用户来说太流氓了，不推荐。  对于有硬性需求的，可以引导用户加入白名单。至于推送，  可以尝试集成多个推送方案，小米，华为等都有推送sdk，在对应手机上可以确保收到消息，  然后像百度这种是多app公用通道的，也就是手机中有一个使用百度推送的app被允许后台启动，就能让其他app收到推送。随着Android版本的不断更新及国内厂商对ROM的不断优化，如何最大可能的对进程保活，是Android一道需要长期学习/钻研的学问，也是Android开发者不得不面对的问题。

引援: