详解Android进程保活的方法

关于 Android 平台的进程保活这一块,想必是所有 Android 开发者瞩目的内容之一。你到网上搜 Android 进程保活,可以搜出各种各样神乎其技的做法,绝大多数都是极其不靠谱。前段时间,Github还出现了一个很火的“黑科技”进程保活库,声称可以做到进程永生不死。

怀着学习和膜拜的心情进去Github围观,结果发现很多人提了 Issue 说各种各样的机子无法成功保活。

看到这里,我瞬间就放心了。坦白的讲,我是真心不希望有这种黑科技存在的,它只会滋生更多的流氓应用,拖垮我大 Android 平台的流畅性。

扯了这么多,接下来就直接进入本文的正题,谈谈关于进程保活的知识。提前声明以下四点

  • 本文是本人开发 Android 至今综合各方资料所得
  • 不以节能来维持进程保活的手段,都是耍流氓
  • 本文不是教你做永生不死的进程,如果指望实现进程永生不死,请忽略本文
  • 本文有错误的地方,欢迎留下评论互相探讨(拍砖请轻拍)

保活手段

当前业界的Android进程保活手段主要分为 黑、白、灰 三种,其大致的实现思路如下:

黑色保活:不同的app进程,用广播相互唤醒(包括利用系统提供的广播进行唤醒)

白色保活:启动前台Service

灰色保活:利用系统的漏洞启动前台Service

黑色保活

所谓黑色保活,就是利用不同的app进程使用广播来进行相互唤醒。举个3个比较常见的场景:

场景1:开机,网络切换、拍照、拍视频时候,利用系统产生的广播唤醒app

场景2:接入第三方SDK也会唤醒相应的app进程,如微信sdk会唤醒微信,支付宝sdk会唤醒支付宝。由此发散开去,就会直接触发了下面的 场景3

场景3:假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app,那么你打开任意一个阿里系的app后,有可能就顺便把其他阿里系的app给唤醒了。(只是拿阿里打个比方,其实BAT系都差不多)

没错,我们的Android手机就是一步一步的被上面这些场景给拖卡机的。

针对场景1,估计Google已经开始意识到这些问题,所以在最新的Android N取消了 ACTION_NEW_PICTURE(拍照),ACTION_NEW_VIDEO(拍视频),CONNECTIVITY_ACTION(网络切换)等三种广播,无疑给了很多app沉重的打击。我猜他们的心情是下面这样的

而开机广播的话,记得有一些定制ROM的厂商早已经将其去掉。

针对场景2和场景3,因为调用SDK唤醒app进程属于正常行为,此处不讨论。但是在借助LBE分析app之间的唤醒路径的时候,发现了两个问题:

1.很多推送SDK也存在唤醒app的功能

2.app之间的唤醒路径真是多,且错综复杂

我把自己使用的手机测试结果给大家围观一下(我的手机是小米4C,刷了原生的Android5.1系统,且已经获得Root权限才能查看这些唤醒路径)

15组相互唤醒路径

全部唤醒路径

我们直接点开 简书 的唤醒路径进行查看

简书唤醒路径

可以看到以上3条唤醒路径,但是涵盖的唤醒应用总数却达到了23+43+28款,数目真心惊人。请注意,这只是我手机上一款app的唤醒路径而已,到了这里是不是有点细思极恐。

当然,这里依然存在一个疑问,就是LBE分析这些唤醒路径和互相唤醒的应用是基于什么思路,我们不得而知。所以我们也无法确定其分析结果是否准确,如果有LBE的童鞋看到此文章,不知可否告知一下思路呢?但是,手机打开一个app就唤醒一大批,我自己可是亲身体验到这种酸爽的......

白色保活

白色保活手段非常简单,就是调用系统api启动一个前台的Service进程,这样会在系统的通知栏生成一个Notification,用来让用户知道有这样一个app在运行着,哪怕当前的app退到了后台。如下方的LBE和QQ音乐这样:

灰色保活

灰色保活,这种保活手段是应用范围最广泛。它是利用系统的漏洞来启动一个前台的Service进程,与普通的启动方式区别在于,它不会在系统通知栏处出现一个Notification,看起来就如同运行着一个后台Service进程一样。这样做带来的好处就是,用户无法察觉到你运行着一个前台进程(因为看不到Notification),但你的进程优先级又是高于普通后台进程的。那么如何利用系统的漏洞呢,大致的实现思路和代码如下:

思路一:API < 18,启动前台Service时直接传入new Notification();

思路二:API >= 18,同时启动两个id相同的前台Service,然后再将后启动的Service做stop处理;

public class GrayService extends Service {

  private final static int GRAY_SERVICE_ID = 1001;

  @Override
  public int onStartCommand(Intent intent, int flags, int startId) {
    if (Build.VERSION.SDK_INT < 18) {
      startForeground(GRAY_SERVICE_ID, new Notification());//API < 18 ,此方法能有效隐藏Notification上的图标
    } else {
      Intent innerIntent = new Intent(this, GrayInnerService.class);
      startService(innerIntent);
      startForeground(GRAY_SERVICE_ID, new Notification());
    }

    return super.onStartCommand(intent, flags, startId);
  }

  ...
  ...

  /**
   * 给 API >= 18 的平台上用的灰色保活手段
   */
  public static class GrayInnerService extends Service {

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
      startForeground(GRAY_SERVICE_ID, new Notification());
      stopForeground(true);
      stopSelf();
      return super.onStartCommand(intent, flags, startId);
    }

  }
}

代码大致就是这样,能让你神不知鬼不觉的启动着一个前台Service。其实市面上很多app都用着这种灰色保活的手段,什么?你不信?好吧,我们来验证一下。流程很简单,打开一个app,看下系统通知栏有没有一个 Notification,如果没有,我们就进入手机的adb shell模式,然后输入下面的shell命令

dumpsys activity services PackageName

打印出指定包名的所有进程中的Service信息,看下有没有 isForeground=true 的关键信息。如果通知栏没有看到属于app的 Notification 且又看到 isForeground=true 则说明了,此app利用了这种灰色保活的手段。

下面分别是我手机上微信、qq、支付宝、陌陌的测试结果,大家有兴趣也可以自己验证一下。

微信

手Q

支付宝

陌陌

其实Google察觉到了此漏洞的存在,并逐步进行封堵。这就是为什么这种保活方式分 API >= 18 和 API < 18 两种情况,从Android5.0的ServiceRecord类的postNotification函数源代码中可以看到这样的一行注释

当某一天 API >= 18 的方案也失效的时候,我们就又要另谋出路了。需要注意的是,使用灰色保活并不代表着你的Service就永生不死了,只能说是提高了进程的优先级。如果你的app进程占用了大量的内存,按照回收进程的策略,同样会干掉你的app。感兴趣于灰色保活是如何利用系统漏洞不显示 Notification 的童鞋,可以研究一下系统的 ServiceRecord、NotificationManagerService 等相关源代码,因为不是本文的重点,所以不做详述。

唠叨的分割线

到这里基本就介绍完了 黑、白、灰 三种实现方式,仅仅从代码层面去讲保活是不够的,我希望能够通过系统的进程回收机制来理解保活,这样能够让我们更好的避免踩到进程被杀的坑。

进程回收机制

熟悉Android系统的童鞋都知道,系统出于体验和性能上的考虑,app在退到后台时系统并不会真正的kill掉这个进程,而是将其缓存起来。打开的应用越多,后台缓存的进程也越多。在系统内存不足的情况下,系统开始依据自身的一套进程回收机制来判断要kill掉哪些进程,以腾出内存来供给需要的app。这套杀进程回收内存的机制就叫 Low Memory Killer ,它是基于Linux内核的 OOM Killer(Out-Of-Memory killer)机制诞生。

了解完 Low Memory Killer,再科普一下oom_adj。什么是oom_adj?它是linux内核分配给每个系统进程的一个值,代表进程的优先级,进程回收机制就是根据这个优先级来决定是否进行回收。对于oom_adj的作用,你只需要记住以下几点即可:

  • 进程的oom_adj越大,表示此进程优先级越低,越容易被杀回收;越小,表示进程优先级越高,越不容易被杀回收
  • 普通app进程的oom_adj>=0,系统进程的oom_adj才可能<0

那么我们如何查看进程的oom_adj值呢,需要用到下面的两个shell命令

ps | grep PackageName //获取你指定的进程信息

这里是以我写的demo代码为例子,红色圈中部分别为下面三个进程的ID

  • UI进程:com.clock.daemon
  • 普通后台进程:com.clock.daemon:bg
  • 灰色保活进程:com.clock.daemon:gray

当然,这些进程的id也可以通过AndroidStudio获得

接着我们来再来获取三个进程的oom_adj

cat /proc/进程ID/oom_adj

从上图可以看到UI进程和灰色保活Service进程的oom_adj=0,而普通后台进程oom_adj=15。到这里估计你也能明白,为什么普通的后台进程容易被回收,而前台进程则不容易被回收了吧。但明白这个还不够,接着看下图

上面是我把app切换到后台,再进行一次oom_adj的检验,你会发现UI进程的值从0变成了6,而灰色保活的Service进程则从0变成了1。这里可以观察到,app退到后台时,其所有的进程优先级都会降低。但是UI进程是降低最为明显的,因为它占用的内存资源最多,系统内存不足的时候肯定优先杀这些占用内存高的进程来腾出资源。所以,为了尽量避免后台UI进程被杀,需要尽可能的释放一些不用的资源,尤其是图片、音视频之类的。

从Android官方文档中,我们也能看到优先级从高到低列出了这些不同类型的进程:Foreground process、Visible process、Service process、Background process、Empty process。

总结(文末有福利)

絮絮叨叨写完了这么多,最后来做个小小的总结。回归到开篇提到QQ进程不死的问题,我也曾认为存在这样一种技术。可惜我把手机root后,杀掉QQ进程之后就再也起不来了。有些手机厂商把这些知名的app放入了自己的白名单中,保证了进程不死来提高用户体验(如微信、QQ、陌陌都在小米的白名单中)。如果从白名单中移除,他们终究还是和普通app一样躲避不了被杀的命运,为了尽量避免被杀,还是老老实实去做好优化工作吧。

所以,进程保活的根本方案终究还是回到了性能优化上,进程永生不死终究是个彻头彻尾的伪命题!

补充更新

有童鞋问,在华为的机子上发现微信和手Q的UI进程退到后台,oom_adj的值一点都没有变,是不是有什么黑科技在其中。为此,我稍稍验证了一下,验证方式就是把demo工程的包名改成手机QQ的,编译运行在华为的机子上,发现我的进程怎么杀也都是不死的,退到后台oom_adj的值同样不发生变化,而恢复原来的包名就不行了。所以,你懂的,手Q就在华为机子的白名单中。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • 详解Android进程和线程

    写在前面的话 一个Android应用就是一个Linux进程,每个应用在各自的进程中运行,互不干扰,比较安全. 一个应用对应一个主线程,就是通常所说的UI线程,android遵守的就是单线程模型,所以说Ui操作不是线程安全的并且这些操作必须在UI线程中执行. 本文是对官方文档的翻译,原文链接:https://developer.android.com/guide/components/processes-and-threads.html 概述 当某个应用组件启动且该应用没有运行其他任何组件时,An

  • 深入解读Android的内部进程通信接口AIDL

    意义: 由于每个应用进程都有自己的独立进程空间,在android平台上,一个进程通常不能访问另一个进程的内存空间,而我们经常需要夸进程传递对象,就需要把对象分解成操作对象可以理解的基本单元,并且有序的通过进程边界. 定义: AIDL(Android Interface Definition Language)是一种IDL语言,用于生成可以在Android设备上两个进程之间进行进程间通信(interprocess communication, IPC)的代码.如果在一个进程中(例如Activity

  • Android通过JNI实现守护进程

    开发一个需要常住后台的App其实是一件非常头疼的事情,不仅要应对国内各大厂商的ROM,还需要应对各类的安全管家...虽然不断的研究各式各样的方法,但是效果并不好,比如任务管理器把App干掉,服务就起不来了... 网上搜寻一番后,主要的方法有以下几种方法,但都是治标不治本: 1.提高Service的优先级:这个,也只能说在系统内存不足需要回收资源的时候,优先级较高,不容易被回收,然并卵... 2.提高Service所在进程的优先级:效果不是很明显 3.在onDestroy方法里重启service:

  • Android 进程间通信实现原理分析

    Android Service是分为两种: 本地服务(Local Service): 同一个apk内被调用 远程服务(Remote Service):被另一个apk调用远程服务需要借助AIDL来完成. AIDL 是什么 AIDL (Android Interface Definition Language) 是一种IDL 语言,用于生成可以在Android设备上两个进程之间进行进程间通信(interprocess communication, IPC)的代码.如果在一个进程中(例如Activit

  • Android 杀死进程几种方法详细介绍

    Android 杀死进程: 对于进程结束在开发APP应用当中还是有必要的,这里整理了三种方法,大家可以根据需求选用. 当应用不再使用时,通常需要关闭应用,可以使用以下三种方法关闭android应用: 第一种方法:首先获取当前进程的id,然后杀死该进程. android.os.Process.killProcess(android.os.Process.myPid()) 接下来实践一下: <RelativeLayout xmlns:android="http://schemas.androi

  • Android编程防止进程被第三方软件杀死的方法

    本文实例讲述了Android编程防止进程被第三方软件杀死的方法.分享给大家供大家参考,具体如下: 项目测试的时候发现,按home键回到桌面,再用360清理内存,软件被结束,再次进入的时候报错,看了下log,以为是有的地方没有控制好,但是又不知道360结束的是什么(这个现在还没弄明白).使用小米系统的进程管理优化内存就不报错. 后来想到用Service防止软件被kill掉,查了下资料,发现google 管方就有,ForegroundService 前台服务,让服务一直以前台任务的方式运行,可以在s

  • Android中进程生命周期的优先级

    学习Android最好的途径当然是强大的官方文档了,其中在Processes and Threads一节中对于进程生命周期淘汰优先级,有着详细的介绍.就不给大家转帖了,直接放译文吧,如下: Android系统会尽量维持进程的存在,但毕竟资源有限,当系统资源告急的时候会淘汰一部分进程.淘汰顺序的凭据就是系统进程的优先级了,优先级越高越不容易被杀死,反之亦然.系统总共为进程分了五个优先级,如下 一.前台进程(进程满足如下任一条件即为前台进程): 1. 拥有 一个执行了onresume方法正在与用户交

  • Android结束进程的方法详解

    本文实例讲述了Android结束进程的方法.分享给大家供大家参考,具体如下: 最近在做一个类似与任务管理器的东西,里面有个功能,可以通过这个管理器结束掉其他的进程. 在Android平台下,结束进程的方法还是比较多的.首先指明,此处的"结束进程",包含了结束自身进程和结束其他进程两个方面.通过查阅SDK文档和网上的一些资料,自己找到一些结束进程的方法.在这里做一些归纳和总结,文章的部分信息有可能来自网上已有的文章和帖子,由于过了比较长时间,所以若发现本文与其他文章雷同,请谅解. 一.结

  • Android Activity与Service通信(不同进程之间)详解

    在Android中,Activity主要负责前台页面的展示,Service主要负责需要长期运行的任务,所以在我们实际开发中,就会常常遇到Activity与Service之间的通信,我们一般在Activity中启动后台Service,通过Intent来启动,Intent中我们可以传递数据给Service,而当我们Service执行某些操作之后想要更新UI线程,我们应该怎么做呢?接下来我就介绍三种方式来实现Service与Activity之间的通信问题 Activity与Service通信的方式有三

  • Android开发中多进程共享数据简析

    背景 最近在工作中遇到一个需求,需要在接收到推送的时候将推送获得的数据存起来,以供app启动时使用.我们会认为这不是So easy吗?只要把数据存到SharedPreferences中,然后让app打开同一个SharedPreferences读取数据就可以了.但是在实际的测试中,我们发现推送进程存入的数据,并不能在app进程中获得.所以这是为什么呢,也许聪明的读者从我们上面的陈述中已经发现了原因,因为我们有两个进程,推送进程负责将推送数据存入,而app进程负责读取,但是正是由于是两个进程,如果它

随机推荐