性能优化

Android系统进程优先级策略-ADJ

2019-02-19  本文已影响0人  凡星轨迹

本篇文章是基于Android9.0来介绍Android系统关于进程的优先级是如何定义和管理的。

概述

1.进程

进程-Process 是程序的一个运行实例。通常会有唯一一个pid与之对应。但pid不是绝对唯一的，当进程死亡后pid会被回收给另外的进程使用。在Android世界里，App开发者很容易认为系统的四大组件就是进程的载体，实际上，它们不能算是完整的进程实例，最多只能算是进程的组成部分。由于Android系统框架中，系统对进程的创建和管理进行了封装，每当我们在启动四大组件Activity, BroadcastReceiver,ContentProvider,Service任意一个的时候，系统就会去检查该组件所在的进程是否已经存在，如果不存在，框架就会自动调用startProcessLocked函数去创建进程。当然一个app可以存在多个进程，多个app也可以运行在同一个进程下，我们可以通过Android:process来设置。

2.优先级

Android系统框架设计理念里是希望对用户很重要的进程尽可能的长期存活，以此来提高用户体验。我们知道Android app在启动的时候会去做很多事情，比如系统会检测该app进程是否存在，如果不存在则需要通知zygote进程去fork app进程，同时完成application信息的初始化工作。此时如果app的进程存在，那么就会省略这个步骤，直接快速唤起app。对于app来说也是一样，通过进程保活可以去实现更多的功能，但是如果所有的app不管有用没用的都存活下来了，系统的资源毕竟是有限的，系统内存很快就会枯竭而亡，这时就需要有合理地进程回收机制了。那么究竟该怎么回收进程呢？其实系统是根据各个app四大组件的状态来决定进程的优先级值adj。系统会根据一定的策略先去回收优先级最低的（同时也是adj值最大的），其次再回收优先级略低的，依次类推，直到回收了足够的系统资源，保证系统正常运转。

3.adj取值范围及含义

ADJ级别 取值 含义
NATIVE_ADJ -1000 native进程
SYSTEM_ADJ -900 仅指system_server进程
PERSISTENT_PROC_ADJ -800 系统persistent进程
PERSISTENT_SERVICE_ADJ -700 关联着系统或persistent进程
FOREGROUND_APP_ADJ 0 前台进程
VISIBLE_APP_ADJ 100 可见进程
PERCEPTIBLE_APP_ADJ 200 可感知进程，比如后台音乐播放
BACKUP_APP_ADJ 300 备份进程
HEAVY_WEIGHT_APP_ADJ 400 重量级进程
SERVICE_ADJ 500 服务进程
HOME_APP_ADJ 600 Home进程
PREVIOUS_APP_ADJ 700 上一个进程
SERVICE_B_ADJ 800 B List中的Service
CACHED_APP_MIN_ADJ 900 不可见进程的adj最小值
CACHED_APP_MAX_ADJ 906 不可见进程的adj最大值

从Android 7.0开始，ADJ采用100、200、300；在这之前的版本ADJ采用数字1、2、3，这样的调整可以更进一步地细化进程的优先级，比如在VISIBLE_APP_ADJ(100)与PERCEPTIBLE_APP_ADJ(200)之间，可以有ADJ=101、102级别的进程。

关于进程的优先级可以通过如下的命令查看

adb shell
cd /proc/pid/
oom_adj   oom_score  oom_score_adj
cat oom_adj
0 表示前台进程FOREGROUND_APP_ADJ

省去lmk对oom_score_adj的计算过程，Android 7.0之前的版本，oom_score_adj= oom_adj * 1000/17； 而Android 7.0开始，oom_score_adj= oom_adj，不用再经过一次转换。

4.LowMemoryKiller

Android的Low Memory Killer基于Linux的OOM(Out Of Memory Killer)机制，在Linux中，内存是以页面为单位分配的，OOM的策略更多的是用于分配内存不足时触发，将得分最高的进程杀掉。而lmk则会每隔一段时间检查一次，当系统剩余可用内存较低时，便会触发杀进程的策略，根据不同的剩余内存档位来选择杀不同优先级的进程，而不是等到OOM时再来杀进程，真正OOM时系统可能已经处于异常状态，系统更希望的是未雨绸缪，在内存很低时来杀掉一些优先级较低的进程来保障后续操作的顺利进行。这里不详细说，接下来会有一篇关于Low Memory Killer的文章来详细介绍。
那么在哪里可以看到各个剩余内存档位呢？可以通过如下方式：

frameworks/base/services/core/java/com/android/server/am/ProcessList.java
// These are the various interesting memory levels that we will give to
// the OOM killer.  Note that the OOM killer only supports 6 slots, so we
// can't give it a different value for every possible kind of process.
private final int[] mOomAdj = new int[] {
        FOREGROUND_APP_ADJ, VISIBLE_APP_ADJ, PERCEPTIBLE_APP_ADJ,
        BACKUP_APP_ADJ, CACHED_APP_MIN_ADJ, CACHED_APP_MAX_ADJ
};
从ProcessList.java中关于mOomAdj的定义及注释中我们可以发现，
系统一共定义了6个档位，
分别对应了上表格中列出的几种进程类型。

adb shell
cat /sys/module/lowmemorykiller/parameters/adj
0,100,200,300,900,906

adj值对应如下：
FOREGROUND_APP_ADJ(0)
VISIBLE_APP_ADJ(100)
PERCEPTIBLE_APP_ADJ(200)
BACKUP_APP_ADJ(300)
CACHED_APP_MIN_ADJ(900)
CACHED_APP_MAX_ADJ(906)

cat /sys/module/lowmemorykiller/parameters/minfree
18432,23040,27648,32256,85296,120640
由于一个page=4k,对应的换算公式是：value*4/1024,换算结果如下：
72M,90M,108M,126M,144M,180M

剩余内存值档位对应如下：
FOREGROUND_APP_ADJ(72M)
VISIBLE_APP_ADJ(90M)
PERCEPTIBLE_APP_ADJ(108M)
BACKUP_APP_ADJ(126M)
CACHED_APP_MIN_ADJ(144M)
CACHED_APP_MAX_ADJ(180M)

进程刚启动时ADJ等于INVALID_ADJ，当执行完attachApplication()，该该进程的curAdj和setAdj不相等，则会触发执行setOomAdj()将该进程的节点/proc/pid/oom_score_adj写入oomadj值。举例：当系统剩余空闲内存低于某阈值(比如140MB)，则从ADJ大于或等于相应阈值(比如900)的进程中，选择ADJ值最大的进程，如果存在多个ADJ相同的进程，则选择内存最大的进程。
在updateOomLevels()过程，会根据手机屏幕尺寸或内存大小来调整scale，默认大多数手机内存都大于700MB，则scale等于1。对于64位手机，cached进程的阈值会更大些。

private void updateOomLevels(int displayWidth, int displayHeight, boolean write) {
        // Scale buckets from avail memory: at 300MB we use the lowest values to
        // 700MB or more for the top values.
        float scaleMem = ((float)(mTotalMemMb-350))/(700-350);
        ...
        // Scale buckets from screen size.
        int minSize = 480*800;  //  384000
        int maxSize = 1280*800; // 1024000  230400 870400  .264
        float scaleDisp = ((float)(displayWidth*displayHeight)-minSize)/(maxSize-minSize);
        ...
        float scale = scaleMem > scaleDisp ? scaleMem : scaleDisp;
        if (scale < 0) scale = 0;
        else if (scale > 1) scale = 1;
        ...
        final boolean is64bit = Build.SUPPORTED_64_BIT_ABIS.length > 0;
        for (int i=0; i<mOomAdj.length; i++) {
            int low = mOomMinFreeLow[i];
            int high = mOomMinFreeHigh[i];
            if (is64bit) {
                // Increase the high min-free levels for cached processes for 64-bit
                if (i == 4) high = (high*3)/2;
                else if (i == 5) high = (high*7)/4;
            }
            mOomMinFree[i] = (int)(low + ((high-low)*scale));
        }
}

ADJ详解

1.ADJ优先级小于0的，就是说正常情况下肯定不会被杀死，即使被杀死了也会被重启的进程。

2.ADJ优先级大于等于0的

final int numCachedAndEmpty = numCached + numEmpty;
int memFactor;
if (numCached <= mConstants.CUR_TRIM_CACHED_PROCESSES
        && numEmpty <= mConstants.CUR_TRIM_EMPTY_PROCESSES) {
    if (numCachedAndEmpty <= ProcessList.TRIM_CRITICAL_THRESHOLD) {
        memFactor = ProcessStats.ADJ_MEM_FACTOR_CRITICAL;
    } else if (numCachedAndEmpty <= ProcessList.TRIM_LOW_THRESHOLD) {
        memFactor = ProcessStats.ADJ_MEM_FACTOR_LOW;
    } else {
        memFactor = ProcessStats.ADJ_MEM_FACTOR_MODERATE;
    }
} else {
    memFactor = ProcessStats.ADJ_MEM_FACTOR_NORMAL;
}
内存因子 取值 先决条件
ADJ_MEM_FACTOR_CRITICAL 3 Cached+Empty<=3
ADJ_MEM_FACTOR_LOW 2 Cached+Empty<=5
ADJ_MEM_FACTOR_MODERATE 1 Cached<=5 && Empty<=8
ADJ_MEM_FACTOR_NORMAL 0 Cached>5或者Empty>8

注：用于限制empty或cached进程的上限为16个，
并且empty超过8个时会清理掉30分钟没有活跃的进程。 cached和empty主要是区别是否有Activity
系统会有相应的log输出：

//默认cachedProcessLimit=16
if (numCached > cachedProcessLimit) {
    app.kill("cached #" + numCached, true);
}
//默认CUR_TRIM_EMPTY_PROCESSES=8, 且满足30min
if (numEmpty > mConstants.CUR_TRIM_EMPTY_PROCESSES
        && app.lastActivityTime < oldTime) {
      app.kill("empty for "+ (
      (oldTime + ProcessList.MAX_EMPTY_TIME - app.lastActivityTime)
         / 1000) + "s", true);
}
//默认cachedProcessLimit=16
if (numEmpty > emptyProcessLimit) {
     app.kill("empty #" + numEmpty, true);
}

总结

Android进程优先级ADJ的每一个ADJ级别往往都有多种场景，使用adjType完美地区分相同ADJ下的不同场景； 不同ADJ进程所对应的schedGroup不同，从而分配的CPU资源也不同，schedGroup大体分为TOP(T)、前台(F)、后台(B)； ADJ跟AMS中的procState有着紧密的联系。

adj：通过调整oom_score_adj来影响进程寿命(Lowmemorykiller杀进程策略)；
schedGroup：影响进程的CPU资源调度与分配；
procState：从进程所包含的四大组件运行状态来评估进程状态，影响framework的内存控制策略。比如控制缓存进程和空进程个数上限依赖于procState，再比如控制APP执行handleLowMemory()的触发时机等。


from gityuan

CPU调度组：

调度级别 缩写 解释
SCHED_GROUP_BACKGROUND(0) B 后台进程组
SCHED_GROUP_DEFAULT(1) F 前台进程组
SCHED_GROUP_TOP_APP(2) T TOP进程组
SCHED_GROUP_TOP_APP_BOUND(3) T TOP进程组
  1. 常说的前台进程与后台进程，其实是从CPU调度角度来划分的前台与后台；为了让用户正在使用的TOP进程能分配到更多的CPU资源，从Android 6.0开始新增了TOP进程组，CPU调度优先分配给当前正在跟用户交互的APP，提升用户体验。
  2. 上图adjType=”broadcast”的CPU调度组的选择取决于广播队列，当receiver接收到的广播来自于前台广播队列则采用前台进程组，当receiver接收到的广播来自于后台广播队列则采用后台进程组。前后台广播队列的CPU资源调度优先级不同，所以前台广播超时10秒就会ANR，而后台广播超时60秒才会ANR。更少的CPU资源分配就需要更长的时间来完成执行，这也就是为何两个广播队列定义了不同的超时阈值。
  3. 上图adjType=”exec-service”的CPU调度组的选择取决于caller, 当发起bindService或者startService的调用者caller属于后台进程组，callerFg=false，则Service的生命周期回调运行在后台进程组，非常少的CPU资源；当caller属于前台或者TOP进程组，则Service的生命周期回调运行在前台进程组，分配较多的CPU资源。
  4. 上图adjType=”service”也有机会选择TOP组, 前提条件是在bindService的时候带有BIND_IMPORTANT的flags，用于标记该服务对于客户端进程很重要。

对于app开发者的建议：

  1. UI进程与Service进程一定要分离，因为对于包含activity的service进程，一旦进入后台就成为”cch-started-ui-services”类型的cache进程(ADJ>=900)，随时可能会被系统回收；而分离后的Service进程服务属于SERVICE_ADJ(500)，被杀的可能性相对较小。尤其是系统允许自启动的服务进程必须做UI分离，避免消耗系统较大内存。
  2. 只有真正需要用户可感知的应用，才调用startForegroundService()方法来启动前台服务，此时ADJ=PERCEPTIBLE_APP_ADJ(200)，常驻内存，并且会在通知栏常驻通知提醒用户，比如音乐播放，地图导航。切勿为了常驻而滥用前台服务，这会严重影响用户体验。
  3. 进程中的Service工作完成后，务必主动调用stopService或stopSelf来停止服务，避免占据内存，浪费系统资源；
  4. 不要长时间绑定其他进程的service或者provider，每次使用完成后应立刻释放，避免其他进程常驻于内存；
  5. APP应该实现接口onTrimMemory()和onLowMemory()，根据TrimLevel适当地将非必须内存在回调方法中加以释放。当系统内存紧张时会回调该接口，减少系统卡顿与杀进程频次。
  6. 减少在保活上花心思，更应该在优化内存上下功夫，因为在相同ADJ级别的情况下，系统会选择优先杀内存占用的进程。

参考：
http://gityuan.com/2018/05/19/android-process-adj/
https://blog.csdn.net/kickxxx/article/details/13996565
https://blog.csdn.net/u012602304/article/details/79066000
https://blog.csdn.net/sinat_34606064/article/details/77932268
http://gityuan.com/2016/09/17/android-lowmemorykiller/

上一篇 下一篇

猜你喜欢

热点阅读