早前，我在知乎上回答了这样一个问题：怎么让 Android 程序一直后台运行，像 QQ 一样不被杀死？。关于 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之间的唤醒路径的时候，发现了两个问题：
- 很多推送SDK也存在唤醒app的功能
- 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进程被杀，需要尽可能的释放一些不用的资源，尤其是图片、音视频之类的。
总结
絮絮叨叨写完了这么多，最后来做个小小的总结。回归到开篇提到QQ进程不死的问题，我也曾认为存在这样一种技术。可惜我把手机root后，杀掉QQ进程之后就再也起不来了。有些手机厂商把这些知名的app放入了自己的白名单中，保证了进程不死来提高用户体验（如微信、QQ、陌陌都在小米的白名单中）。如果从白名单中移除，他们终究还是和普通app一样躲避不了被杀的命运，为了尽量避免被杀，还是老老实实去做好优化工作吧。
所以，进程保活的根本方案终究还是回到了性能优化上，进程永生不死终究是个彻头彻尾的伪命题！
补充更新 （2016-04-20）
有童鞋问，在华为的机子上发现微信和手Q的UI进程退到后台，oom_adj的值一点都没有变，是不是有什么黑科技在其中。为此，我稍稍验证了一下，验证方式就是把demo工程的包名改成手机QQ的，编译运行在华为的机子上，发现我的进程怎么杀也都是不死的，退到后台oom_adj的值同样不发生变化，而恢复原来的包名就不行了。所以，你懂的，手Q就在华为机子的白名单中。
文章到此结束，相关简单的实践代码请看
https://github.com/D-clock/AndroidDaemonService
从Android官方文档中，我们也能看到优先级从高到低列出了这些不同类型的进程：Foreground process、Visible process、Service process、Background process、Empty process。而这些进程的oom_adj分别是多少，又是如何挂钩起来的呢？推荐大家阅读下面这篇文章：
http://www.cnblogs.com/angeldevil/archive/2013/05/21/3090872.html
内容如下
Android Low Memory Killer
Low Memory Killer的原理
在Android中，即使当用户退出应用程序之后，应用程序的进程也还是存在于系统中，这样是为了方便程序的再次启动，但是这样的话，随着打开的程序数量的增加，系统的内存会变得不足，就需要杀掉一部分进程以释放内存空间。至于是否需要杀死一些进程和哪些进程需要被杀死，是通过Low Memory Killer机制来进行判定的。
Android的Low Memory Killer基于Linux的OOM机制，在Linux中，内存是以页面为单位分配的，当申请页面分配时如果内存不足会通过以下流程选择bad进程来杀掉从而释放内存：
alloc_pages -> out_of_memory() -> select_bad_process() -> badness()
在Low Memory Killer中通过进程的oom_adj与占用内存的大小决定要杀死的进程，oom_adj越小越不容易被杀死。
Low Memory Killer Driver在用户空间指定了一组内存临界值及与之一一对应的一组oom_adj值，当系统剩余内存位于内存临界值中的一个范围内时，如果一个进程的oom_adj值大于或等于这个临界值对应的oom_adj值就会被杀掉。
可以通过修改/sys/module/lowmemorykiller/parameters/minfree与/sys/module/lowmemorykiller/parameters/adj来改变内存临界值及与之对应的oom_adj值。minfree中数值的单位是内存中的页面数量，一般情况下一个页面是4KB。
比如如果向/sys/module/lowmemorykiller/parameters/adj写入0,8，向/sys/module/lowmemorykiller/parameters/minfree中写入1024,4096，假设一个页面大小为4KB，这样当系统空闲内存位于1024*4~4096*4KB之间时oom_adj大于等于8的进程就会被杀掉。
在lowmemorykiller.c中定义了阈值表的默认值，可以通过init.rc自定义：
static int lowmem_adj[6] = {
0,
1,
6,
12,
};
static int lowmem_adj_size = 4;
static size_t lowmem_minfree[6] = {
3 * 512, /* 6MB */
2 * 1024, /* 8MB */
4 * 1024, /* 16MB */
16 * 1024, /* 64MB */
};
static int lowmem_minfree_size = 4;
在init.rc中定义了init进程的oom_adj为-16，不可能会被杀死(init的PID是1)：
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_adj -16
在Linux中有一个kswapd的内核线程，当linux回收内存分页的时候，kswapd线程将会遍历一张shrinker链表，并执行回调，定义如下：
/*
* A callback you can register to apply pressure to ageable caches.
*
* 'shrink' is passed a count 'nr_to_scan' and a 'gfpmask'. It should
* look through the least-recently-used 'nr_to_scan' entries and
* attempt to free them up. It should return the number of objects
* which remain in the cache. If it returns -1, it means it cannot do
* any scanning at this time (eg. there is a risk of deadlock).
*
* The 'gfpmask' refers to the allocation we are currently trying to
* fulfil.
*
* Note that 'shrink' will be passed nr_to_scan == 0 when the VM is
* querying the cache size, so a fastpath for that case is appropriate.
*/
struct shrinker {
int (*shrink)(int nr_to_scan, gfp_t gfp_mask);
int seeks; /* seeks to recreate an obj */
/* These are for internal use */
struct list_head list;
long nr; /* objs pending delete */
};
#define DEFAULT_SEEKS 2 /* A good number if you don't know better. */
extern void register_shrinker(struct shrinker *);
extern void unregister_shrinker(struct shrinker *);
通过register_shrinker与unregister_shrinker向shrinker链表中添加或移除回调。当注册Shrinker后就可以在回收内存分页时按自己定义的规则释放内存。
Android Low Memory Killer的代码在drivers/staging/android/lowmemorykiller.c中，通过以下代码在模块初始化时注册Shrinker：
static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask);
static struct shrinker lowmem_shrinker = {
.shrink = lowmem_shrink,
.seeks = DEFAULT_SEEKS * 16
};
static int __init lowmem_init(void)
{
register_shrinker(&lowmem_shrinker);
return 0;
}
static void __exit lowmem_exit(void)
{
unregister_shrinker(&lowmem_shrinker);
}
module_init(lowmem_init);
module_exit(lowmem_exit);
这样就可以在回收内存分页时调用lowmem_shrink函数。
Low Memory Killer的实现
lowmem_shrink的定义如下：
static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
{
struct task_struct *p;
struct task_struct *selected = NULL;
int rem = 0;
int tasksize;
int i;
int min_adj = OOM_ADJUST_MAX + 1;
int selected_tasksize = 0;
int selected_oom_adj;
int array_size = ARRAY_SIZE(lowmem_adj);
int other_free = global_page_state(NR_FREE_PAGES);
int other_file = global_page_state(NR_FILE_PAGES);
if (lowmem_adj_size < array_size)
array_size = lowmem_adj_size;
if (lowmem_minfree_size < array_size)
array_size = lowmem_minfree_size;
for (i = 0; i < array_size; i++) {
if (other_free < lowmem_minfree[i] &&
other_file < lowmem_minfree[i]) {
min_adj = lowmem_adj[i];
break;
}
}
if (nr_to_scan > 0)
lowmem_print(3, "lowmem_shrink %d, %x, ofree %d %d, ma %d\n",
nr_to_scan, gfp_mask, other_free, other_file,
min_adj);
rem = global_page_state(NR_ACTIVE_ANON) +
global_page_state(NR_ACTIVE_FILE) +
global_page_state(NR_INACTIVE_ANON) +
global_page_state(NR_INACTIVE_FILE);
if (nr_to_scan <= 0 || min_adj == OOM_ADJUST_MAX + 1) {
lowmem_print(5, "lowmem_shrink %d, %x, return %d\n",
nr_to_scan, gfp_mask, rem);
return rem;
}
selected_oom_adj = min_adj;
read_lock(&tasklist_lock);
for_each_process(p) {
struct mm_struct *mm;
int oom_adj;
task_lock(p);
mm = p->mm;
if (!mm) {
task_unlock(p);
continue;
}
oom_adj = mm->oom_adj;
if (oom_adj < min_adj) {
task_unlock(p);
continue;
}
tasksize = get_mm_rss(mm);
task_unlock(p);
if (tasksize <= 0)
continue;
if (selected) {
if (oom_adj < selected_oom_adj)
continue;
if (oom_adj == selected_oom_adj &&
tasksize <= selected_tasksize)
continue;
}
selected = p;
selected_tasksize = tasksize;
selected_oom_adj = oom_adj;
lowmem_print(2, "select %d (%s), adj %d, size %d, to kill\n",
p->pid, p->comm, oom_adj, tasksize);
}
if (selected) {
lowmem_print(1, "send sigkill to %d (%s), adj %d, size %d\n",
selected->pid, selected->comm,
selected_oom_adj, selected_tasksize);
force_sig(SIGKILL, selected);
rem -= selected_tasksize;
}
lowmem_print(4, "lowmem_shrink %d, %x, return %d\n",
nr_to_scan, gfp_mask, rem);
read_unlock(&tasklist_lock);
return rem;
}分开来看这段代码，首先取得内存阈值表的大小，取阈值表数组大小与lowmem_adj_size，lowmem_minfree_size的较小值，然后通过globa_page_state获得当前剩余内存的大小，然后跟内存阈值表中的阈值相比较获得min_adj与selected_oom_adj：
int array_size = ARRAY_SIZE(lowmem_adj);
int other_free = global_page_state(NR_FREE_PAGES);
int other_file = global_page_state(NR_FILE_PAGES);
if (lowmem_adj_size < array_size)
array_size = lowmem_adj_size;
if (lowmem_minfree_size < array_size)
array_size = lowmem_minfree_size;
for (i = 0; i < array_size; i++) {
if (other_free < lowmem_minfree[i] && other_file < lowmem_minfree[i]) {
min_adj = lowmem_adj[i];
break;
}
}
selected_oom_adj = min_adj;
遍历所有进程找到oom_adj>min_adj并且占用内存大的进程：
read_lock(&tasklist_lock);
for_each_process(p) {
struct mm_struct *mm;
int oom_adj;
task_lock(p);
mm = p->mm;
if (!mm) {
task_unlock(p);
continue;
}
oom_adj = mm->oom_adj;
//获取task_struct->struct_mm->oom_adj，如果小于警戒值min_adj不做处理
if (oom_adj < min_adj) {
task_unlock(p);
continue;
}
//如果走到这里说明oom_adj>=min_adj，即超过警戒值
//获取内存占用大小，若<=0，不做处理
tasksize = get_mm_rss(mm);
task_unlock(p);
if (tasksize <= 0)
continue;
//如果之前已经先择了一个进程，比较当前进程与之前选择的进程的oom_adj与内存占用大小，如果oom_adj比之前选择的小或相等而内存占用比之前选择的进程小，不做处理。
if (selected) {
if (oom_adj < selected_oom_adj)
continue;
if (oom_adj == selected_oom_adj &&
tasksize <= selected_tasksize)
continue;
}
//走到这里表示当前进程比之前选择的进程oom_adj大或相等但占用内存大，选择当前进程
selected = p;
selected_tasksize = tasksize;
selected_oom_adj = oom_adj;
lowmem_print(2, "select %d (%s), adj %d, size %d, to kill\n",
p->pid, p->comm, oom_adj, tasksize);
}
如果选择出了符合条件的进程，发送SIGNAL信号Kill掉：
if (selected) {
lowmem_print(1, "send sigkill to %d (%s), adj %d, size %d\n",
selected->pid, selected->comm,
selected_oom_adj, selected_tasksize);
force_sig(SIGKILL, selected);
rem -= selected_tasksize;
}
oom_adj与上层Process Importance的关系
我们知道，在上层进程按重要性可以分为：Foreground process，Visible process，Service process，Background process与Empty process，那么这些重要性怎么与Low Memory Killer中的oom_adj对应起来的呢？
在ActivityManager.RunningAppProcessInfo中我们可以看到如下关于importance的定义：
/**
* Constant for {@link #importance}: this is a persistent process.
* Only used when reporting to process observers.
* @hide
*/
public static final int IMPORTANCE_PERSISTENT = 50;
/**
* Constant for {@link #importance}: this process is running the
* foreground UI.
*/
public static final int IMPORTANCE_FOREGROUND = 100;
/**
* Constant for {@link #importance}: this process is running something
* that is actively visible to the user, though not in the immediate
* foreground.
*/
public static final int IMPORTANCE_VISIBLE = 200;
/**
* Constant for {@link #importance}: this process is running something
* that is considered to be actively perceptible to the user. An
* example would be an application performing background music playback.
*/
public static final int IMPORTANCE_PERCEPTIBLE = 130;
/**
* Constant for {@link #importance}: this process is running an
* application that can not save its state, and thus can't be killed
* while in the background.
* @hide
*/
public static final int IMPORTANCE_CANT_SAVE_STATE = 170;
/**
* Constant for {@link #importance}: this process is contains services
* that should remain running.
*/
public static final int IMPORTANCE_SERVICE = 300;
/**
* Constant for {@link #importance}: this process process contains
* background code that is expendable.
*/
public static final int IMPORTANCE_BACKGROUND = 400;
/**
* Constant for {@link #importance}: this process is empty of any
* actively running code.
*/
public static final int IMPORTANCE_EMPTY = 500;
这些常量表示了Process的Importance等级，而在ProcessList中我们会发现关于adj的一些定义：
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
static final int HIDDEN_APP_MAX_ADJ = 15;
static int HIDDEN_APP_MIN_ADJ = 9;
// The B list of SERVICE_ADJ -- these are the old and decrepit
// services that aren't as shiny and interesting as the ones in the A list.
static final int SERVICE_B_ADJ = 8;
// This is the process of the previous application that the user was in.
// This process is kept above other things, because it is very common to
// switch back to the previous app. This is important both for recent
// task switch (toggling between the two top recent apps) as well as normal
// UI flow such as clicking on a URI in the e-mail app to view in the browser,
// and then pressing back to return to e-mail.
static final int PREVIOUS_APP_ADJ = 7;
// This is a process holding the home application -- we want to try
// avoiding killing it, even if it would normally be in the background,
// because the user interacts with it so much.
static final int HOME_APP_ADJ = 6;
// This is a process holding an application service -- killing it will not
// have much of an impact as far as the user is concerned.
static final int SERVICE_ADJ = 5;
// This is a process currently hosting a backup operation. Killing it
// is not entirely fatal but is generally a bad idea.
static final int BACKUP_APP_ADJ = 4;
// This is a process with a heavy-weight application. It is in the
// background, but we want to try to avoid killing it. Value set in
// system/rootdir/init.rc on startup.
static final int HEAVY_WEIGHT_APP_ADJ = 3;
// This is a process only hosting components that are perceptible to the
// user, and we really want to avoid killing them, but they are not
// immediately visible. An example is background music playback.
static final int PERCEPTIBLE_APP_ADJ = 2;
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
static final int VISIBLE_APP_ADJ = 1;
// This is the process running the current foreground app. We'd really
// rather not kill it!
static final int FOREGROUND_APP_ADJ = 0;
// This is a system persistent process, such as telephony. Definitely
// don't want to kill it, but doing so is not completely fatal.
static final int PERSISTENT_PROC_ADJ = -12;
// The system process runs at the default adjustment.
static final int SYSTEM_ADJ = -16;
我们可以看到：
static final int PREVIOUS_APP_ADJ = 7; static final int HOME_APP_ADJ = 6;
并不是所有的Background process的等级都是相同的。
关于ADJ与Importance的值都找到了，那么它们是怎么对应起来的呢？Activity实际是由ActivityManagerService来管理的，在ActivityManagerService中我们可以找到以下函数：
static int oomAdjToImportance(int adj, ActivityManager.RunningAppProcessInfo currApp) {
if (adj >= ProcessList.HIDDEN_APP_MIN_ADJ) {
if (currApp != null) {
currApp.lru = adj - ProcessList.HIDDEN_APP_MIN_ADJ + 1;
}
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND;
} else if (adj >= ProcessList.SERVICE_B_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE;
} else if (adj >= ProcessList.HOME_APP_ADJ) {
if (currApp != null) {
currApp.lru = 0;
}
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND;
} else if (adj >= ProcessList.SERVICE_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE;
} else if (adj >= ProcessList.HEAVY_WEIGHT_APP_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_CANT_SAVE_STATE;
} else if (adj >= ProcessList.PERCEPTIBLE_APP_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_PERCEPTIBLE;
} else if (adj >= ProcessList.VISIBLE_APP_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_VISIBLE;
} else {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_FOREGROUND;
}
}
在这个函数中实现了根据adj设置importance的功能。
我们还可以看到SERVICE还分为SERVICE_B_ADJ与SERVICE_ADJ，等级是不一样的，并不是所有Service的优先级都比Background process的优先级高。当调用Service的startForeground后，Service的importance就变为了IMPORTANCE_PERCEPTIBLE（在记忆中曾经将Service设置为foreground并打印出其importance的值与IMPORTANCE_PERCEPTIBLE相等），对应的adj是PERCEPTIBLE_APP_ADJ，即2，已经很难被系统杀死了。
// This is a system persistent process, such as telephony. Definitely
// don't want to kill it, but doing so is not completely fatal.
static final int PERSISTENT_PROC_ADJ = -12;
// The system process runs at the default adjustment.
static final int SYSTEM_ADJ = -16;
像电话等进程的adj为-12已基本不可能被杀死了，而在前面已经看到了，init.rc中将init进程的oom_adj设置为了-16，已经是永生进程了。
相关链接：
链接：https://www.jianshu.com/p/63aafe3c12af
扫一扫
703
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
