Android进程保活招式大全
发布于 1 年前 作者 Bugly_Tony 355692 次浏览 来自 技术

作者:腾讯——张兴华

目前市面上的应用,貌似除了微信和手Q都会比较担心被用户或者系统(厂商)杀死问题。本文对 Android 进程拉活进行一个总结。

Android 进程拉活包括两个层面:

A. 提供进程优先级,降低进程被杀死的概率

B. 在进程被杀死后,进行拉活

本文下面就从这两个方面做一下总结。

1. 进程的优先级

Android 系统将尽量长时间地保持应用进程,但为了新建进程或运行更重要的进程,最终需要清除旧进程来回收内存。 为了确定保留或终止哪些进程,系统会根据进程中正在运行的组件以及这些组件的状态,将每个进程放入“重要性层次结构”中。 必要时,系统会首先消除重要性最低的进程,然后是清除重要性稍低一级的进程,依此类推,以回收系统资源。

进程的重要性,划分5级:

  1. 前台进程(Foreground process)

  2. 可见进程(Visible process)

  3. 服务进程(Service process)

  4. 后台进程(Background process)

  5. 空进程(Empty process)

前台进程的重要性最高,依次递减,空进程的重要性最低,下面分别来阐述每种级别的进程

1.1. 前台进程 —— Foreground process

用户当前操作所必需的进程。通常在任意给定时间前台进程都为数不多。只有在内存不足以支持它们同时继续运行这一万不得已的情况下,系统才会终止它们。

A. 拥有用户正在交互的 Activity(已调用 onResume()

B. 拥有某个 Service,后者绑定到用户正在交互的 Activity

C. 拥有正在“前台”运行的 Service(服务已调用 startForeground()

D. 拥有正执行一个生命周期回调的 Service(onCreate()onStart()onDestroy()

E. 拥有正执行其 onReceive() 方法的 BroadcastReceiver

1.2. 可见进程 —— Visible process

没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。可见进程被视为是极其重要的进程,除非为了维持所有前台进程同时运行而必须终止,否则系统不会终止这些进程。

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

B. 拥有绑定到可见(或前台)Activity 的 Service

1.3. 服务进程 —— Service process

尽管服务进程与用户所见内容没有直接关联,但是它们通常在执行一些用户关心的操作(例如,在后台播放音乐或从网络下载数据)。因此,除非内存不足以维持所有前台进程和可见进程同时运行,否则系统会让服务进程保持运行状态。

A. 正在运行 startService() 方法启动的服务,且不属于上述两个更高类别进程的进程。

1.4. 后台进程 —— Background process

后台进程对用户体验没有直接影响,系统可能随时终止它们,以回收内存供前台进程、可见进程或服务进程使用。 通常会有很多后台进程在运行,因此它们会保存在 LRU 列表中,以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法,并保存了其当前状态,则终止其进程不会对用户体验产生明显影响,因为当用户导航回该 Activity 时,Activity 会恢复其所有可见状态。

A. 对用户不可见的 Activity 的进程(已调用 Activity的onStop() 方法)

1.5. 空进程 —— Empty process

保留这种进程的的唯一目的是用作缓存,以缩短下次在其中运行组件所需的启动时间。 为使总体系统资源在进程缓存和底层内核缓存之间保持平衡,系统往往会终止这些进程。

A. 不含任何活动应用组件的进程

详情参见:http://developer.android.com/intl/zh-cn/guide/components/processes-and-threads.html

2. Android 进程回收策略

Android 中对于内存的回收,主要依靠 Lowmemorykiller 来完成,是一种根据 OOM_ADJ 阈值级别触发相应力度的内存回收的机制。

关于 OOM_ADJ 的说明如下:

其中红色部分代表比较容易被杀死的 Android 进程(OOM_ADJ>=4),绿色部分表示不容易被杀死的 Android 进程,其他表示非 Android 进程(纯 Linux 进程)。在 Lowmemorykiller 回收内存时会根据进程的级别优先杀死 OOM_ADJ 比较大的进程,对于优先级相同的进程则进一步受到进程所占内存和进程存活时间的影响。

Android 手机中进程被杀死可能有如下情况:

综上,可以得出减少进程被杀死概率无非就是想办法提高进程优先级,减少进程在内存不足等情况下被杀死的概率。

3. 提升进程优先级的方案

3.1. 利用 Activity 提升权限

3.1.1. 方案设计思想

监控手机锁屏解锁事件,在屏幕锁屏时启动1个像素的 Activity,在用户解锁时将 Activity 销毁掉。注意该 Activity 需设计成用户无感知。

通过该方案,可以使进程的优先级在屏幕锁屏时间由4提升为最高优先级1。

3.1.2. 方案适用范围

适用场景: 本方案主要解决第三方应用及系统管理工具在检测到锁屏事件后一段时间(一般为5分钟以内)内会杀死后台进程,已达到省电的目的问题。

适用版本: 适用于所有的 Android 版本。

3.1.3. 方案具体实现

首先定义 Activity,并设置 Activity 的大小为1像素:

其次,从 AndroidManifest 中通过如下属性,排除 Activity 在 RecentTask 中的显示:

最后,控制 Activity 为透明:

Activity 启动与销毁时机的控制:

3.2. 利用 Notification 提升权限

3.2.1. 方案设计思想

Android 中 Service 的优先级为4,通过 setForeground 接口可以将后台 Service 设置为前台 Service,使进程的优先级由4提升为2,从而使进程的优先级仅仅低于用户当前正在交互的进程,与可见进程优先级一致,使进程被杀死的概率大大降低。

3.2.2. 方案实现挑战

从 Android2.3 开始调用 setForeground 将后台 Service 设置为前台 Service 时,必须在系统的通知栏发送一条通知,也就是前台 Service 与一条可见的通知时绑定在一起的。

对于不需要常驻通知栏的应用来说,该方案虽好,但却是用户感知的,无法直接使用。

3.2.3. 方案挑战应对措施

通过实现一个内部 Service,在 LiveService 和其内部 Service 中同时发送具有相同 ID 的 Notification,然后将内部 Service 结束掉。随着内部 Service 的结束,Notification 将会消失,但系统优先级依然保持为2。

3.2.4. 方案适用范围

适用于目前已知所有版本。

3.2.5. 方案具体实现

4. 进程死后拉活的方案

4.1. 利用系统广播拉活

#####4.1.1. 方案设计思想

在发生特定系统事件时,系统会发出响应的广播,通过在 AndroidManifest 中“静态”注册对应的广播监听器,即可在发生响应事件时拉活。

常用的用于拉活的广播事件包括:

4.1.2. 方案适用范围

适用于全部 Android 平台。但存在如下几个缺点:

1) 广播接收器被管理软件、系统软件通过“自启管理”等功能禁用的场景无法接收到广播,从而无法自启。

2) 系统广播事件不可控,只能保证发生事件时拉活进程,但无法保证进程挂掉后立即拉活。

因此,该方案主要作为备用手段。

4.2. 利用第三方应用广播拉活

4.2.1. 方案设计思想

该方案总的设计思想与接收系统广播类似,不同的是该方案为接收第三方 Top 应用广播。

通过反编译第三方 Top 应用,如:手机QQ、微信、支付宝、UC浏览器等,以及友盟、信鸽、个推等 SDK,找出它们外发的广播,在应用中进行监听,这样当这些应用发出广播时,就会将我们的应用拉活。

4.2.2. 方案适用范围

该方案的有效程度除与系统广播一样的因素外,主要受如下因素限制:

1) 反编译分析过的第三方应用的多少

2) 第三方应用的广播属于应用私有,当前版本中有效的广播,在后续版本随时就可能被移除或被改为不外发。

这些因素都影响了拉活的效果。

4.3. 利用系统Service机制拉活

4.3.1. 方案设计思想

将 Service 设置为 START_STICKY,利用系统机制在 Service 挂掉后自动拉活:

4.3.2. 方案适用范围

如下两种情况无法拉活:

  1. Service 第一次被异常杀死后会在5秒内重启,第二次被杀死会在10秒内重启,第三次会在20秒内重启,一旦在短时间内 Service 被杀死达到5次,则系统不再拉起。

  2. 进程被取得 Root 权限的管理工具或系统工具通过 forestop 停止掉,无法重启。

4.4. 利用Native进程拉活

#####4.4.1. 方案设计思想

**主要思想:**利用 Linux 中的 fork 机制创建 Native 进程,在 Native 进程中监控主进程的存活,当主进程挂掉后,在 Native 进程中立即对主进程进行拉活。

**主要原理:**在 Android 中所有进程和系统组件的生命周期受 ActivityManagerService 的统一管理。而且,通过 Linux 的 fork 机制创建的进程为纯 Linux 进程,其生命周期不受 Android 的管理。

#####4.4.2. 方案实现挑战

挑战一:在 Native 进程中如何感知主进程死亡。

要在 Native 进程中感知主进程是否存活有两种实现方式:

  1. 在 Native 进程中通过死循环或定时器,轮训判断主进程是否存活,档主进程不存活时进行拉活。该方案的很大缺点是不停的轮询执行判断逻辑,非常耗电。

  2. 在主进程中创建一个监控文件,并且在主进程中持有文件锁。在拉活进程启动后申请文件锁将会被堵塞,一旦可以成功获取到锁,说明主进程挂掉,即可进行拉活。由于 Android 中的应用都运行于虚拟机之上,Java 层的文件锁与 Linux 层的文件锁是不同的,要实现该功能需要封装 Linux 层的文件锁供上层调用。

封装 Linux 文件锁的代码如下:

Native 层中堵塞申请文件锁的部分代码:

挑战二:在 Native 进程中如何拉活主进程。

通过 Native 进程拉活主进程的部分代码如下,即通过 am 命令进行拉活。通过指定“–include-stopped-packages”参数来拉活主进程处于 forestop 状态的情况。

挑战三:如何保证 Native 进程的唯一。

从可扩展性和进程唯一等多方面考虑,将 Native 进程设计层 C/S 结构模式,主进程与 Native 进程通过 Localsocket 进行通信。在Native进程中利用 Localsocket 保证 Native 进程的唯一性,不至于出现创建多个 Native 进程以及 Native 进程变成僵尸进程等问题。

4.4.3. 方案适用范围

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

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

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

4.5. 利用 JobScheduler 机制拉活

4.5.1. 方案设计思想

Android5.0 以后系统对 Native 进程等加强了管理,Native 拉活方式失效。系统在 Android5.0 以上版本提供了 JobScheduler 接口,系统会定时调用该进程以使应用进行一些逻辑操作。

在本项目中,我对 JobScheduler 进行了进一步封装,兼容 Android5.0 以下版本。封装后 JobScheduler 接口的使用如下:

4.5.2. 方案适用范围

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

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

仅在小米手机可能会出现有时无法拉活的问题。

4.6. 利用账号同步机制拉活

#####4.6.1. 方案设计思想

Android 系统的账号同步机制会定期同步账号进行,该方案目的在于利用同步机制进行进程的拉活。添加账号和设置同步周期的代码如下:

该方案需要在 AndroidManifest 中定义账号授权与同步服务。

####4.6.2. 方案适用范围

该方案适用于所有的 Android 版本,包括被 forestop 掉的进程也可以进行拉活。

最新 Android 版本(Android N)中系统好像对账户同步这里做了变动,该方法不再有效。

5. 其他有效拉活方案

经研究发现还有其他一些系统拉活措施可以使用,但在使用时需要用户授权,用户感知比较强烈。

这些方案包括:

  1. 利用系统通知管理权限进行拉活

  2. 利用辅助功能拉活,将应用加入厂商或管理软件白名单。

这些方案需要结合具体产品特性来搞。

上面所有解释这些方案都是考虑的无 Root 的情况。

其他还有一些技术之外的措施,比如说应用内 Push 通道的选择:

  1. 国外版应用:接入 Google 的 GCM。

  2. 国内版应用:根据终端不同,在小米手机(包括 MIUI)接入小米推送、华为手机接入华为推送;其他手机可以考虑接入腾讯信鸽或极光推送与小米推送做 A/B Test。

32 回复

纯纯的干货,给力。如果能有Demo就更好了。 利用 JobScheduler 机制拉活其实就是代替了AlarManager?

JobInfo.Builder.setPeriodic(long intervalMillis)中接收的时间间隔是以毫秒为单位的,图上传了10进去真的好吗?耗电、发热会不会很严重? 利用账号同步机制拉活的一个弊端是在设置-账户里会增加自己App的条目,看到账户多1个会不会觉得有些错愕?作者好像没有提到这点。 另外,手机QQ的1像素方案也太不优雅了。

在Android 6.0以上的Doze模式中,JobScheduler是在第一阶段废掉的,而AlarmManager在第二阶段才废掉,从这点上看似乎不如AlarmManager?而且还要分版本写2个方法? 对作者的 对 JobScheduler 进行了进一步封装,兼容 Android5.0 以下版本 表示质疑,JobScheduler是API 21 才引入的,5.0以下版本的Android上根本找不到这个类,Google也没有推出兼容包。像是Evernote的Andorid-Job是分版本使用JobScheduler, GCMNetworkManager, AlarmManger的。 怀疑Force Close也关不掉是因为Periodic设的太小、频繁唤醒所致?

@qiyueliuhuo 这些问题非常好,我来一一回答一下: 1、图上传了10进去真的好吗? —— 不要纠结于本文中对数值的设定,本文主要从技术角度探索各种方案的可行性。 所以,本文截图不是真实产品中的数值,纯粹是验证方案可行性时Demo中个人随便设置的值,作为Demo当然会设置比较小的值看效果。如果想在实际产品采用,可以根据实际情况设置为一个合理的值。

看到账户多1个会不会觉得有些错愕? —— 跟上一个问题一样,如果从产品的角度去评判该方案,肯定会出这个问题。然而如果产品中需要登录态有登录功能,拿顺势搞这么一项出来就不会有问题。所以,这里的两点疑问归根结底都是纯技术角度与产品角度的碰撞与选择。所以,如本文中列举了这么多拉活措施,但从来没有说过每个应用都可以从头到尾来一遍。作者这里只是想将尽可能多的技术方案呈现给大家,至于要不要用,如何选用,需要每个人根据自己产品的特点有所取舍。

最后,澄清一点:所谓手Q的1像素方案,只是网上的说法(http://www.expreview.com/39438.html)。手Q有没有这样做,我不确定。

@qiyueliuhuo

JobScheduler在实验时发现在小米和华为等6.0手机是有效的,但实际数据并不理想。效果比较自测时大打折扣。所以,该方案在实际保活中最多可以作为一个有效补充吧。

@qiyueliuhuo 有一点很重要,当应用被force stop之后AlarmManager就无效了,但是JobScheduler还能正常拉活。不出意外的话,Android后续版本应该会修改JobScheduler的策略来防止这一点了。

@StonE 你好,你有JobScheduler的demo么,我的被一键清理后就起不来了,1426366264@qq.com,万分感谢

@zhgxhuaa 1像素方案按上面写的并不行,首先Activity界面会截获触摸事件,然后就算不截获任何触摸时间,切换以后以后,不会留在屏幕。退一步假设通过windowsmanager来addview,这时候退出应用以后像素依然在屏幕上,但是oom_adj,依然大于4,所以qq就算这么做,也不是这么简单弄的

安卓用户真可怜。。。

启动activity的时候会把之前的activity给起来,怎么避免呢 ? 有没有demo可以提供一个 934011814@qq.com

hi 楼主可以给我个demo吗? zhutingfa@163.com 谢谢

楼主,可以给个demo吗,weiguo@uddream.cn

测试了三台手机,小米6.0,华为6.0,魅族5.1,只有华为拉起来了。 楼主,有JobScheduler的demo吗?万分感谢。378674708@qq.com

JobScheduler是可以,不过华为手机还是需要用户设置不被系统干掉

楼主,可以给个demo吗,1272108979@qq.com 非常感谢

楼主,可以给个Demo吗,765451774@qq.com。我的程序被杀后好像拉不起来, 帐号同步也是,非常感谢

楼主,可以给个demo吗,974612726@qq.com 非常感谢

楼主,关于1像素进程保活的方案,可以给个demo吗,或者给点资料,1261329618@qq.com 非常感谢

楼主,可以给个demo吗,328414211@qq.com 非常感谢

楼主,好文章!!可以给个demo吗? 461122046@qq.com ;非常感谢!!!

楼主,求个demo,正在做相关功能的应用,快被折腾死了!1275445874@qq.com,非常感谢!!!

好文章,就个demo,695455657@qq.com

@tumengtech 有demo么,求共享695455657@qq.com

不错很有帮助,针对不同版本采用不同的效果在原生系统上比较有用,账户同步机制在国产ROM依旧有效,就是多次进行一键清理可能会出现无法同步的情况,不过手机重启后依旧可以启动(无自启动权限,未设置保护应用),已经满足了需求!

流氓应用耍流氓~~Android生态就是被这么玩坏的!

恳请楼主指点,求demo,1401429109@qq.com,感激不尽,谢谢。。。

国内用户真可怜。大长们多为用户考虑一下吧

恳请楼主指点,求demo,837839317@qq.com,感激不尽,谢谢。。。

麻烦楼主给个demo,最近在做这部分的研究,可是运用了你说的那些方法,有不少地方报红,估计是引用错了或者缺少类,948113678@qq.com,非常感谢~

可以发个demo给我吗?444386433@qq.com 万分感谢。