Android保活方案

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

创新互联建站长期为上千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为婺源企业提供专业的网站设计制作、成都网站制作，婺源网站改版等技术服务。拥有十载丰富建站经验和众多成功案例,为您定制开发。

打开的应用越多，缓存的应用也就越多，在系统进程不足的情况下，系统根据自己的一套进程回收机制，来判断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可能并不能达到需要的效果

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，这一点还是可以办到的。

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开发者不得不面对的问题。

引援:

Android保活系列之——双进程守护

近期跳槽到玩加电竞，加之英雄联盟云顶之弈排位模式的推出，导致个人精力有限没有时间和心情去写相关的博客。

在Context中提供了bindService的方法

绑定服务是客户端--服务器接口中的服务器。组件和服务进行绑定后，可以发送请求、接收响应、执行进程间通信（IPC）。这里的服务器模型不同于网络C-S模型而是针对于Android应用不同的功能进行进程划分，例如提供视频播放的进程我们可以把它当做视频播放服务器，我们UI层属于客户端，客户端想要调用视频播放，需要用IPC方式通过bind服务的方式调用视频播放服务。（PS:如果大家对IPC不太熟悉可以参考我的其他文章 Android跨进程通信技术的使用及原理 ）客户端可以通过调用bindService()绑定到服务。调用时，必须提供ServiceConnection的实现，后者会监控与服务的连接及销毁。

借助bindService的机制，我们可以在主进程创建时创建一个守护进程，并监听守护进程的连接及销毁，再守护进程bindService中绑定主进程，这样即使进程因为锁屏、内存等问题杀掉后，也会被守护进程拉起，这就是Android中双进程守护的概念。当然早在PC时期，网吧的计时系统就使用了双进程守护机制，防止被恶意杀掉。

实现方式就不写了，网络上一搜一堆，这里给出一篇文章

Android 双进程守护

写的中规中矩，如果不清楚如何实现可以看一下。

谷歌官方8.0变更

当版本8.0时，如果需要在后台启动服务需要调用startForegroundService。并且在serivce中onCreate方法必须在5秒内调用startForeground ,向通知栏发一个通知告知用户你的App正在后台运行，否则就会抛出异常

8.0通知适配

保活分两种：拉活、保活

拉活和保活是相辅相成的。在6.0版本以后的机型上，系统杀应用是按照进程组杀的，会直接导致双进程守护失效。那么因此就不使用双进程了么？

1.低版本双进程守护是依然亲测好使。

2.双进程守护可以和后面讲到的 账号同步、外部PUSH、JobScheduler

相结合，可以规避开系统杀进程组的问题。使双进程守护功能可以兼容高版本。

讲的有些笼统，我寻思的发Dome、写例子，但这样解决不了根本问题，只有懂得了思路，了解了什么是双进程守护，才能在开发中随机应变。只能说Android水太深，大家需要细心细心再细心。

Android保活——蓝牙唤醒（主动kill掉也可唤醒）

项目需要后台保活，但无论怎么保活，只要用户主动kill掉，app依然是活不了。

发现了蓝牙唤醒这个方式，用户主动kill掉也可行。

Android 8.0开始提供了 startscan的方法，

public void startScan(ScanCallback callback)

public void startScan(ListScanFilter filters,ScanSettings settings,ScanCallback callback)

public int startScan(ListScanFilter filters,ScanSettings settings,PendingIntent callbackIntent)

第一个没有过滤条件，锁屏就停止扫描

第二个可以加过滤条件，锁屏不影响扫描 

第三个的扫描结果由PendingIntent发送，即使app没有在运行，系统也可以扫描后唤醒app，这就是我们要的方法了。

PendingIntent是对Intent的封装，是满足某些条件或触发某些事件后才执行指定的行为，主要用于闹钟、通知、桌面部件。Android的四大组件之间通信用Intent，跨进程通信用PendingIntent。

Android 8.0 引进了Context.startForegroundService()，在系统创建服务后，应用需要在ANR发生前调用startForeground(int ,android.app.Notification)，如果未及时调用该方法，系统将报ANR错误 。系统给前台服务的ANR时间是20秒。

用startScan蓝牙唤醒的原理是：app向系统订阅了扫描结果（预先加了过滤条件），当蓝牙连接断开的时候，设备就会发广播，这时系统就可以扫描到对应的广播，唤醒对应的service，这时想做什么操作就根据你的项目需要了。至于系统会为你扫描多久，这个还没测试。

（1）setScanMode有四个参数可以选 ：

SCAN_MODE_BALANCED：在平衡电源模式下执行蓝牙LE扫描。返回扫描结果的速度能够很好地权衡扫描频率和功耗。

SCAN_MODE_LOW_LATENCY：扫描使用最高占空比。建议只在应用程序在前台运行时使用此模式。

SCAN_MODE_LOW_POWER：在低功耗模式下执行蓝牙LE扫描。这是默认的扫描模式，因为它消耗的能量最少。如果扫描应用程序不在前台，则强制执行此模式。

SCAN_MODE_OPPORTUNISTIC：一种特殊的蓝牙LE扫描模式。使用这种扫描模式的应用程序将被动地侦听其他扫描结果，而不启动BLE扫描本身

（2）settingBuilder.setMatchMode有两个参数可以选：

MATCH_MODE_AGGRESSIVE：  信号弱也会报告 

MATCH_MODE_STICKY：  信号比较强和扫描到的次数比较多才会报告

（3)settingBuilder.setCallbackType也有其他参数可选，但适用的就一个

(4)  ScanFilter  的过滤方法有几个,如下图，打勾的是测试了可行的，但只有第一个DeviceAddress有唯一性  

网页标题：android保活,Android保活方案
链接URL：http://kswjz.com/article/dsgcish.html