【Android 系统开发】_“核心技术”篇 -- LowMemoryKiller

时间 2019-12-06

标签 Android 系统开发核心技术 lowmemorykiller 栏目 Android 繁體版

原文原文链接

核心源码

关键类	路径
lmkd.c	system/core/lmkd/lmkd.c
lmkd.rc	system/core/lmkd/lmkd.rc
lowmemorykiller.c	kernel-3.18/drivers/staging/android/lowmemorykiller.c
ProcessList.java	frameworks/base/services/core/java/com/android/server/am/ProcessList.java

进程生命周期

Android系统的设计理念正是但愿应用进程能尽可能长时间地存活，以提高用户体验。应用首次打开比较慢，这个过程有进程建立以及Application等信息的初始化，因此应用在启动以后，即使退到后台并不是马上杀死，而是存活一段时间，这样下次再使用则会很是快。对于APP一样但愿自身尽量存活更长的时间，甚至探索各类保活黑科技。物极必反，系统处于低内存的状态下，手机性能会有所降低；系统继续听任全部进程一直存活，系统内存很快就会枯竭而亡，那么须要合理地进程回收机制。java

到底该回收哪一个进程呢？系统根据进程的组件状态来决定每一个进程的优先级值ADJ，系统根据必定策略先杀优先级最低的进程，而后逐步杀优先级更低的进程，依此类推，以回收预期的可用系统资源，从而保证系统正常运转。linux

LowMemoryKiller 机制就是系统用于断定是否须要杀进程和杀哪些进程的一个机制。android

进程优先级

系统内进程优先级分 5 级：ios

进程	说明
前台进程（Foreground process）	用户当前操做所必需的进程。
可见进程（Visible process）	没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。可见进程被视为是极其重要的进程，除非为了维持全部前台进程同时运行而必须终止，不然系统不会终止这些进程。
服务进程（Service process）	正在运行已使用 startService() 方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联，可是它们一般在执行一些用户关心的操做（例如，在后台播放音乐或从网络下载数据）。所以，除非内存不足以维持全部前台进程和可见进程同时运行，不然系统会让服务进程保持运行状态。
后台进程（Background process）	包含目前对用户不可见的 Activity 的进程（已调用 Activity 的 onStop() 方法）。这些进程对用户体验没有直接影响，系统可能随时终止它们，以回收内存供前台进程、可见进程或服务进程使用。
空进程（Empty process）	不含任何活动应用组件的进程。保留这种进程的的惟一目的是用做缓存，以缩短下次在其中运行组件所需的启动时间。为使整体系统资源在进程缓存和底层内核缓存之间保持平衡，系统每每会终止这些进程。

Framework OOM Adjustment

咱们看看进程优先级的相关代码：git

ADJ 级别

ADJ 定义在 ProcessList.java 中：oom_adj划分为16级，取值范围[-1000~1001]算法

ADJ 级别	取值	说明
UNKNOWN_ADJ	1001	通常指将要会缓存进程，没法获取肯定值
CACHED_APP_MAX_ADJ	906	不可见进程的 adj 最大值
CACHED_APP_MIN_ADJ	900	不可见进程的 adj 最小值
SERVICE_B_AD	800	B List中的Service（较老的、使用可能性更小）
PREVIOUS_APP_ADJ	700	上一个App的进程(每每经过按返回键)
HOME_APP_ADJ	600	Home进程
SERVICE_ADJ	500	服务进程(Service process)
HEAVY_WEIGHT_APP_ADJ	400	后台的重量级进程，system/rootdir/init.rc文件中设置
BACKUP_APP_ADJ	300	备份进程
PERCEPTIBLE_APP_ADJ	200	可感知进程，好比后台音乐播放
VISIBLE_APP_ADJ	100	可见进程(Visible process)
FOREGROUND_APP_ADJ	0	前台进程（Foreground process）
PERSISTENT_SERVICE_ADJ	-700	关联着系统或 persistent 进程
PERSISTENT_PROC_ADJ	-800	系统 persistent 进程，好比 telephony
SYSTEM_ADJ	-900	系统进程，仅指system_server进程
NATIVE_ADJ	-1000	native进程（不被系统管理）

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

state 级别

STATE 定义在 ActivityManager.java中：process_state 划分20类，取值范围[-1~18]缓存

STATE 级别	取值	说明
PROCESS_STATE_NONEXISTENT	18	不存在的进程
PROCESS_STATE_CACHED_EMPTY	17	进程处于cached状态，且为空进程
PROCESS_STATE_CACHED_ACTIVITY_CLIENT	16	进程处于cached状态，且为另外一个cached进程(内含Activity)的client进程 adj 最大值
PROCESS_STATE_CACHED_ACTIVITY	15	进程处于cached状态，且内含Activity
PROCESS_STATE_LAST_ACTIVITY	14	后台进程，且拥有上一次显示的Activity
PROCESS_STATE_HOME	14	后台进程，且拥有home Activity
PROCESS_STATE_RECEIVER	12	后台进程，且正在运行receiver
PROCESS_STATE_SERVICE	11	后台进程，且正在运行service
PROCESS_STATE_HEAVY_WEIGHT	10	后台进程，但没法执行restore，所以尽可能避免kill该进程
PROCESS_STATE_BACKUP	9	后台进程，正在运行backup/restore操做
PROCESS_STATE_TRANSIENT_BACKGROUND	8	进程短暂进入后台，咱们应该尽可能保持运行
PROCESS_STATE_IMPORTANT_BACKGROUND	7	对用户很重要的进程，用户不可感知其存在
PROCESS_STATE_IMPORTANT_FOREGROUND	6	对用户很重要的进程，用户可感知其存在
PROCESS_STATE_TOP_SLEEPING	5	与PROCESS_STATE_TOP同样，但此时设备正处于休眠状态
PROCESS_STATE_FOREGROUND_SERVICE	4	拥有给一个前台Service
PROCESS_STATE_BOUND_FOREGROUND_SERVICE	3	拥有给一个前台Service，且由系统绑定
PROCESS_STATE_TOP	2	拥有当前用户可见的top Activity
PROCESS_STATE_PERSISTENT_UI	1	persistent系统进程，并正在执行UI操做
PROCESS_STATE_PERSISTENT	0	persistent系统进程
PROCESS_STATE_UNKNOWN	-1	不可知的进程

这里作个特殊说明：从 Android 7.0 开始，省去 lmk 对 oom_score_adj 的计算过程，Android 7.0 以前的版本，oom_score_adj= oom_adj * 1000/17；
而 Android 7.0 开始，oom_score_adj= oom_adj，不用再通过一次转换。（咱们后面会讲解到这个）

Read The Fucking Code

lmkd

ProcessList 中定义有进程的优先级，越重要的进程的优先级越低，前台 APP 的优先级为 0，系统 APP 的优先级通常都是负值，因此通常进程管理以及杀进程都是针对与上层的 APP 来讲的，而这些进程的优先级调整都在 AMS 里面，AMS 根据进程中组件的状态去不断的计算每一个进程的优先级，计算以后会及时更新到对应进程的文件节点中，而这个对文件节点的更新并非它完成的，而是 lmkd ，他们之间经过 socket 通讯。网络

lmkd 在手机中是一个常驻进程，用来处理上层 ActivityManager 在进行 updateOomAdj 以后，经过 socket 与 lmkd 进行通讯，更新进程的优先级，若是必要则杀掉进程释放内存。数据结构

lmkd 是在 init 进程启动的时候启动的，经过解析 init.rc 文件来启动 lmkd 守护进程。在 lmkd 中有定义 lmkd.rc:

service lmkd /system/bin/lmkd
    class core
    group root readproc
    critical
    socket lmkd seqpacket 0660 system system
    writepid /dev/cpuset/system-background/tasks

lmkd 会建立名为 lmkd 的 socket，节点位于/dev/socket/lmkd，该 socket 用于跟上层 framework 交互。

上层 AMS 跟 lmkd 通讯主要分为三种 command，每种 command 表明一种数据控制方式，在 ProcessList 以及 lmkd 中都有定义，ProcessList 中文件的定义必须跟 lmkd.c 定义彻底一致，格式以下：

LMK_TARGET <minfree> <minkillprio> ... (up to 6 pairs)
LMK_PROCPRIO <pid> <uid> <prio>
LMK_PROCREMOVE <pid>

上述3个命令的使用都经过 ProcessList.java 中的以下方法:

功能	命令	对应方法
LMK_TARGET	更新 oom_adj	PorcessList.setOomAdj()
LMK_PROCPRIO	设置进程 adj	PorcessList.updateOomLevels()
LMK_PROCREMOVE	移除进程	PorcessList.remove()

在开始分析 lmkd 的处理逻辑以前，lmkd.c 中有几个重要的变量与数据结构提早说明一下：

... ...

// 内存级别限额
#define INKERNEL_MINFREE_PATH "/sys/module/lowmemorykiller/parameters/minfree"

// 不一样级别内存对应要杀的的优先级
#define INKERNEL_ADJ_PATH "/sys/module/lowmemorykiller/parameters/adj"

... ...

// 三种 command
enum lmk_cmd {
    LMK_TARGET,
    LMK_PROCPRIO,
    LMK_PROCREMOVE,
    LMK_MEDLOOSEN,
};

... ...

/* OOM score values used by both kernel and framework */
// 优先级的最小值
#define OOM_SCORE_ADJ_MIN       (-1000)

// 优先级的最大值
#define OOM_SCORE_ADJ_MAX       1000

static int lowmem_adj[MAX_TARGETS];
static int lowmem_minfree[MAX_TARGETS];

... ...

// 双向链表结构体
struct adjslot_list {
    struct adjslot_list *next;
    struct adjslot_list *prev;
};

// 进程在 lmkd 中的数据结构体
struct proc {
    struct adjslot_list asl;
    int pid;
    uid_t uid;
    int oomadj;
    struct proc *pidhash_next;
};

// 存放进程 proc 的 hashtable ，index 是经过 pid 的计算得出
static struct proc *pidhash[PIDHASH_SZ];

// 根据 pid 计算 index 的 hash 算法
#define pid_hashfn(x) ((((x) >> 8) ^ (x)) & (PIDHASH_SZ - 1))

// 进程优先级到数组的 index 之间的转换
// 由于进程的优先级能够是负值，可是数组的 index 不能为负值
// 不过由于这个转换只是简单加了 1000，为了方便，后面的描述中就认为是优先级直接作了 index
#define ADJTOSLOT(adj) ((adj) + -OOM_SCORE_ADJ_MIN)

// table，相似 hashtable ，不过计算 index 的方式不是 hash ，而是 oom_score_adj 通过转换后直接做为 index
// 数组的每一个元素都是双向循环链表
// 进程的优先级做为数组的 index
// 即以进程的优先级为 index，从 -1000 到 +1000 + 1 大小的数组，根据优先级，同优先级的进程 index 相同
// 每一个元素是一个双向链表，这个链表上的全部 proc 的优先级都相同
// 这样根据优先级杀进程的时候就会很是方便，要杀指定优先级的进程能够根据优先级获取到一个进程链表，逐个去杀
static struct adjslot_list procadjslot_list[ADJTOSLOT(OOM_SCORE_ADJ_MAX) + 1];

lmkd 启动后，接下里的操做都在 /system/core/lmkd/lmkd.c 文件，首先进入 main() 方法：

main

咱们看看 lmkd 进程的入口函数 main：

int main(int argc __unused, char **argv __unused) {
    struct sched_param param = {
            .sched_priority = 1,
    };

    medium_oomadj = property_get_int32("ro.lmk.medium", 800);
    orig_medium_oomadj = medium_oomadj;
    critical_oomadj = property_get_int32("ro.lmk.critical", 0);
    debug_process_killing = property_get_bool("ro.lmk.debug", false);
    enable_pressure_upgrade = property_get_bool("ro.lmk.critical_upgrade", false);
    upgrade_pressure = (int64_t)property_get_int32("ro.lmk.upgrade_pressure", 50);
    downgrade_pressure = (int64_t)property_get_int32("ro.lmk.downgrade_pressure", 60);
    is_go_device = property_get_bool("ro.config.low_ram", false);

    if (mlockall(MCL_CURRENT | MCL_FUTURE))
        ALOGW("mlockall failed: errno=%d", errno);

    // 设置此线程的调度策略为 SCHED_FIFO，first-in-first-out，param 中主要设置 sched_priority
    // 因为 SCHED_FIFO 是一种实时调度策略，在这个策略下优先级从1(low) -> 99(high)
    // 实时线程一般会比普通线程有更高的优先级
    sched_setscheduler(0, SCHED_FIFO, &param);
    
    // 初始化 epoll 以及与 ActivityManager 的 socket 链接,等待 cmd 和 data
    // 💥 💥 💥 💥 💥 💥 重点讨论 💥 💥 💥 💥 💥 💥
    if (!init())
        // 进入死循环epoll_wait等待fd事件
        mainloop();    // 💥 💥 💥 💥 💥 💥 重点讨论 💥 💥 💥 💥 💥 💥

    ALOGI("exiting");
    return 0;
}

前面已经提到，这个进程存在的主要做用是跟 AMS 进行通讯，更新 oomAdj ，在必要的时候杀掉进程。因此在 main 函数中主要就是建立了 epoll 以及初始化 socket 并链接 ActivityManager ，而后阻塞等待上层传递 cmd 以及数据过来。

重点分析下 init()：

init

static int init(void) {
    struct epoll_event epev;
    int i;
    int ret;

    page_k = sysconf(_SC_PAGESIZE);
    if (page_k == -1)
        page_k = PAGE_SIZE;
    page_k /= 1024;

    // 建立 epoll 监听文件句柄
    epollfd = epoll_create(MAX_EPOLL_EVENTS);
    if (epollfd == -1) {
        ALOGE("epoll_create failed (errno=%d)", errno);
        return -1;
    }

    // 获取 lmkd 的 socket fd
    ctrl_lfd = android_get_control_socket("lmkd");
    if (ctrl_lfd < 0) {
        ALOGE("get lmkd control socket failed");
        return -1;
    }

    // 监听 lmkd socket
    ret = listen(ctrl_lfd, 1);
    if (ret < 0) {
        ALOGE("lmkd control socket listen failed (errno=%d)", errno);
        return -1;
    }

    epev.events = EPOLLIN;

    // ctrl_connect_handler 里面完成了 soclet 的 accpet 以及 read 数据，并对数据进行相应的处理
    // 💥 💥 💥 💥 💥 💥 下面会重点讨论 💥 💥 💥 💥 💥 💥
    epev.data.ptr = (void *)ctrl_connect_handler;
    if (epoll_ctl(epollfd, EPOLL_CTL_ADD, ctrl_lfd, &epev) == -1) {
        ALOGE("epoll_ctl for lmkd control socket failed (errno=%d)", errno);
        return -1;
    }
    maxevents++;

    // 该路径是否具备可写的权限
    /*
     * 这里，经过检验 /sys/module/lowmemorykiller/parameters/minfree 节点是否具备可写权限
     *
     *     #define INKERNEL_MINFREE_PATH "/sys/module/lowmemorykiller/parameters/minfree"
     * 
     * 来判断是否使用 kernel 接口来管理 lmk 事件。
     * 默认该节点是具备系统可写的权限，也就意味着 use_inkernel_interface = 1
     */
    has_inkernel_module = !access(INKERNEL_MINFREE_PATH, W_OK);
    use_inkernel_interface = has_inkernel_module && !is_go_device;

    // 这个 use_inkernel_interface 是根据是否有 “/sys/module/lowmemorykiller/parameters/minfree” 的写权限来判断的，没有的状况下就使用 kernel 空间的逻辑
    // 目前遇到的都是 use_inkernel_interface
    if (use_inkernel_interface) {
        ALOGI("Using in-kernel low memory killer interface");
    } else {
        ret = init_mp_medium();
        ret |= init_mp_critical();
        if (ret)
            ALOGE("Kernel does not support memory pressure events or in-kernel low memory killer");
    }

    // 双向链表初始化
    for (i = 0; i <= ADJTOSLOT(OOM_SCORE_ADJ_MAX); i++) {
        procadjslot_list[i].next = &procadjslot_list[i];
        procadjslot_list[i].prev = &procadjslot_list[i];
    }

    return 0;
}

mainloop

来看看 mainloop 的逻辑：

// 进入死循环，而后调用 epoll_wait 阻塞等待事件的到来
static void mainloop(void) {
    while (1) {
        struct epoll_event events[maxevents];
        int nevents;
        int i;

        ctrl_dfd_reopened = 0;
        // 等待 epoll_wait 上的事件
        nevents = epoll_wait(epollfd, events, maxevents, -1);

        if (nevents == -1) {
            if (errno == EINTR)
                continue;
            ALOGE("epoll_wait failed (errno=%d)", errno);
            continue;
        }

        for (i = 0; i < nevents; ++i) {
            if (events[i].events & EPOLLERR)
                ALOGD("EPOLLERR on event #%d", i);
            // 当事件到来，则调用 ctrl_connect_handler 方法
            if (events[i].data.ptr)
                (*(void (*)(uint32_t))events[i].data.ptr)(events[i].events);
        }
    }
}

主循环调用 epoll_wait()，等待 epollfd 上的事件，当接收到中断或者不存在事件，则执行 continue 操做。当事件到来，则调用的 ctrl_connect_handler 方法，该方法是由 init() 过程当中设定的方法（咱们以前在分析 init() 的时候提过）。

ctrl_connect_handler

咱们以前在 init() 中看到如下代码：

// ctrl_connect_handler 里面完成了 soclet 的 accpet 以及 read 数据，并对数据进行相应的处理
epev.data.ptr = (void *)ctrl_connect_handler;

它是专门处理 Socket 传递过来的数据的，咱们跟下代码：

static void ctrl_connect_handler(uint32_t events __unused) {
    struct epoll_event epev;

    if (ctrl_dfd >= 0) {
        ctrl_data_close();
        ctrl_dfd_reopened = 1;
    }

    ctrl_dfd = accept(ctrl_lfd, NULL, NULL);

    if (ctrl_dfd < 0) {
        ALOGE("lmkd control socket accept failed; errno=%d", errno);
        return;
    }

    ALOGI("ActivityManager connected");
    maxevents++;
    epev.events = EPOLLIN;
    epev.data.ptr = (void *)ctrl_data_handler;
    
    // 将 ctrl_dfd 添加到 epollfd
    if (epoll_ctl(epollfd, EPOLL_CTL_ADD, ctrl_dfd, &epev) == -1) {
        ALOGE("epoll_ctl for data connection socket failed; errno=%d", errno);
        ctrl_data_close();
        return;
    }
}

ctrl_data_handler

当事件触发，则调用 ctrl_data_handler()：

static void ctrl_data_handler(uint32_t events) {
    if (events & EPOLLHUP) {
        ALOGI("ActivityManager disconnected");
        // ActivityManager 链接断开
        if (!ctrl_dfd_reopened)
            ctrl_data_close();
    } else if (events & EPOLLIN) {
        ctrl_command_handler();
    }
}

ctrl_command_handler

static void ctrl_command_handler(void) {
    int ibuf[CTRL_PACKET_MAX / sizeof(int)];
    int len;
    int cmd = -1;
    int nargs;
    int targets;

    len = ctrl_data_read((char *)ibuf, CTRL_PACKET_MAX);
    if (len <= 0)
        return;

    nargs = len / sizeof(int) - 1;
    if (nargs < 0)
        goto wronglen;

    // 将网络字节顺序转换为主机字节顺序
    cmd = ntohl(ibuf[0]);

    // 一共三种command
    switch(cmd) {
    // 更新内存级别以及对应级别的进程 adj
    case LMK_TARGET:
        targets = nargs / 2;
        if (nargs & 0x1 || targets > (int)ARRAY_SIZE(lowmem_adj))
            goto wronglen;
        cmd_target(targets, &ibuf[1]);
        break;
    // 根据 pid 更新 adj
    case LMK_PROCPRIO:
        if (nargs != 3)
            goto wronglen;
        // 💥 💥 💥 💥 💥 💥 下面会重点讨论 💥 💥 💥 💥 💥 💥
        cmd_procprio(ntohl(ibuf[1]), ntohl(ibuf[2]), ntohl(ibuf[3]));
        break;
    // 根据 pid 移除 proc
    case LMK_PROCREMOVE:
        if (nargs != 1)
            goto wronglen;
        cmd_procremove(ntohl(ibuf[1]));
        break;
    case LMK_MEDLOOSEN:
        if (nargs != 1)
            goto wronglen;
        cmd_medloosen(ntohl(ibuf[1]));
        break;
    default:
        ALOGE("Received unknown command code %d", cmd);
        return;
    }

    return;

wronglen:
    ALOGE("Wrong control socket read length cmd=%d len=%d", cmd, len);
}

获取 framework 传递过来的 buf 数据后，根据 3 种不一样的命令，进入不一样的分支。

LMK_TARGET

// 上层逻辑是在 ProcessList.updateOomLevels 中
        if (write) {
            ByteBuffer buf = ByteBuffer.allocate(4 * (2*mOomAdj.length + 1));
            buf.putInt(LMK_TARGET);
            for (int i=0; i<mOomAdj.length; i++) {
                buf.putInt((mOomMinFree[i]*1024)/PAGE_SIZE);
                buf.putInt(mOomAdj[i]);
            }

            writeLmkd(buf);
            SystemProperties.set("sys.sysctl.extra_free_kbytes", Integer.toString(reserve));
        }

// lmkd 处理逻辑
static void cmd_target(int ntargets, int *params) {
    int i;

    if (ntargets > (int)ARRAY_SIZE(lowmem_adj))
        return;

    // 这个 for 循环对应上面的 for 循环，将数据读出装进数组中
    for (i = 0; i < ntargets; i++) {
        lowmem_minfree[i] = ntohl(*params++);
        lowmem_adj[i] = ntohl(*params++);
    }

    lowmem_targets_size = ntargets;

    // 使用kernel空间的处理逻辑
    if (has_inkernel_module) {
        char minfreestr[128];
        char killpriostr[128];

        minfreestr[0] = '\0';
        killpriostr[0] = '\0';

        // 取出两个数组中的数据，以","分隔，分别拼接成 string
        for (i = 0; i < lowmem_targets_size; i++) {
            char val[40];

            if (i) {
                strlcat(minfreestr, ",", sizeof(minfreestr));
                strlcat(killpriostr, ",", sizeof(killpriostr));
            }

            snprintf(val, sizeof(val), "%d", use_inkernel_interface ? lowmem_minfree[i] : 0);
            strlcat(minfreestr, val, sizeof(minfreestr));
            snprintf(val, sizeof(val), "%d", use_inkernel_interface ? lowmem_adj[i] : 0);
            strlcat(killpriostr, val, sizeof(killpriostr));
        }
        
        // 将生成好的 string 写入到文件节点 minfree 以及 adj
        writefilestring(INKERNEL_MINFREE_PATH, minfreestr);
        writefilestring(INKERNEL_ADJ_PATH, killpriostr);
    }
}

上面的处理逻辑主要是：

        ✨ 1. 按照顺序取出数据，装进lmkd的数组中
        ✨ 2. 分别将两个数组中的数取出，用”,”分隔
        ✨ 3. lowmem_minfree中的数据拼成的string写到 “/sys/module/lowmemorykiller/parameters/minfree”
        ✨ 4. lowmem_adj中的数据拼成的string写到 “/sys/module/lowmemorykiller/parameters/adj”

LMK_PROCPRIO

// 上层逻辑是在 ProcessList.setOomAdj 中
    public static final void setOomAdj(int pid, int uid, int amt) {
        // 当 adj = 16，则直接返回
        if (amt == UNKNOWN_ADJ)
            return;

        long start = SystemClock.elapsedRealtime();
        ByteBuffer buf = ByteBuffer.allocate(4 * 4);
        buf.putInt(LMK_PROCPRIO);
        buf.putInt(pid);
        buf.putInt(uid);
        buf.putInt(amt);
        // 将 16Byte 字节写入 socket
        // buf 大小为 16 个字节，依次写入 LMK_PROCPRIO(命令类型), pid(进程pid), uid(进程uid), amt(目标adj)，将这些字节经过 socket 发送给 lmkd.
        writeLmkd(buf);
        long now = SystemClock.elapsedRealtime();
        if ((now-start) > 250) {
            Slog.w("ActivityManager", "SLOW OOM ADJ: " + (now-start) + "ms for pid " + pid
                    + " = " + amt);
        }
    }

writeLmkd

private static void writeLmkd(ByteBuffer buf) {
        // 当 socket 打开失败会尝试 3 次
        for (int i = 0; i < 3; i++) {
            if (sLmkdSocket == null) {
                    // 打开 socket
                    if (openLmkdSocket() == false) {
                        try {
                            Thread.sleep(1000);
                        } catch (InterruptedException ie) {
                        }
                        continue;
                    }
            }

            try {
                将 buf 信息写入 lmkd socket
                sLmkdOutputStream.write(buf.array(), 0, buf.position());
                return;
            } catch (IOException ex) {
                Slog.w(TAG, "Error writing to lowmemorykiller socket");

                try {
                    sLmkdSocket.close();
                } catch (IOException ex2) {
                }

                sLmkdSocket = null;
            }
        }
    }

openLmkdSocket

private static boolean openLmkdSocket() {
        try {
            sLmkdSocket = new LocalSocket(LocalSocket.SOCKET_SEQPACKET);
            // 与远程 lmkd 守护进程创建 socket 链接
            sLmkdSocket.connect(
                new LocalSocketAddress("lmkd",
                        LocalSocketAddress.Namespace.RESERVED));
            sLmkdOutputStream = sLmkdSocket.getOutputStream();
        } catch (IOException ex) {
            Slog.w(TAG, "lowmemorykiller daemon socket open failed");
            sLmkdSocket = null;
            return false;
        }

        return true;
    }

该方法是打开一个名为 lmkd 的 socket，类型为 LocalSocket.SOCKET_SEQPACKET，这只是一个封装，真实类型就是 SOCK_SEQPACKET。先跟远程 lmkd 守护进程创建链接，再向其经过 write() 将数据写入该 socket，再接下来进入 lmkd 过程。

咱们看看lmkd的处理逻辑：

// lmkd 处理逻辑
static void cmd_procprio(int pid, int uid, int oomadj) {
    struct proc *procp;
    char path[80];
    char val[20];
    int soft_limit_mult;

    if (oomadj < OOM_SCORE_ADJ_MIN || oomadj > OOM_SCORE_ADJ_MAX) {
        ALOGE("Invalid PROCPRIO oomadj argument %d", oomadj);
        return;
    }

    // LMK_PROCPRIO 的主要做用就是更新进程的 oomAdj
    // 将上层传递过来的数据（pid以及优先级）写到该进程对应的文件节点
    // /proc/pid/oom_score_adj
    snprintf(path, sizeof(path), "/proc/%d/oom_score_adj", pid);
    snprintf(val, sizeof(val), "%d", oomadj);
    // 向节店 /proc/<pid>/oom_score_adj 写入 oomAdj
    writefilestring(path, val);

    // 若是使用 kernel 的逻辑，则 return
    // 即这个 command 传递过来只是更新了对应文件节点的 oom_score_adj
    if (use_inkernel_interface)
        return;

    if (oomadj >= 900) {
        soft_limit_mult = 0;
    } else if (oomadj >= 800) {
        soft_limit_mult = 0;
    } else if (oomadj >= 700) {
        soft_limit_mult = 0;
    } else if (oomadj >= 600) {
        // Launcher should be perceptible, don't kill it.
        oomadj = 200;
        soft_limit_mult = 1;
    } else if (oomadj >= 500) {
        soft_limit_mult = 0;
    } else if (oomadj >= 400) {
        soft_limit_mult = 0;
    } else if (oomadj >= 300) {
        soft_limit_mult = 1;
    } else if (oomadj >= 200) {
        soft_limit_mult = 2;
    } else if (oomadj >= 100) {
        soft_limit_mult = 10;
    } else if (oomadj >=   0) {
        soft_limit_mult = 20;
    } else {
        // Persistent processes will have a large
        // soft limit 512MB.
        soft_limit_mult = 64;
    }

    snprintf(path, sizeof(path), "/dev/memcg/apps/uid_%d/pid_%d/memory.soft_limit_in_bytes", uid, pid);
    snprintf(val, sizeof(val), "%d", soft_limit_mult * EIGHT_MEGA);
    writefilestring(path, val);

    // 从hashtable中查找proc
    procp = pid_lookup(pid);
    
    // 若是没有查找到，也就是说这个进程是新建立的，lmkd 维护的数据结构中尚未这个 proc，所以须要新建并添加到 hashtable 中
    if (!procp) {
            procp = malloc(sizeof(struct proc));
            if (!procp) {
                // Oh, the irony.  May need to rebuild our state.
                return;
            }

            procp->pid = pid;
            procp->uid = uid;
            procp->oomadj = oomadj;
            // 将 proc 插入到 lmkd 中的数据结构中，主要包括两个数据结构
            // 更新 hashtable，经过 pid 计算 hash 值，而后存储，解决冲突是让新来的做为数组元素链表的头结点
            // 优先级为 index 的双向链表组成的 table
            proc_insert(procp);
    } else {
        // hashtable 中已经有这个 proc
        // 可是由于优先级的变化，须要先把这个 proc 从原先的优先级 table 中对应位置的双向链表中 remove
        // 而后新加到新的优先级对应的双向链表中
        // 双向链表的添加是新来的放在头部
        proc_unslot(procp);
        procp->oomadj = oomadj;
        proc_slot(procp);
    }
}

// 其中 pid_lookup：查询 hashtable，由于进程的 pid 是惟一的，而后从中取出该 pid 在 lmkd 中的 proc 结构体
static struct proc *pid_lookup(int pid) {
    struct proc *procp;

    for (procp = pidhash[pid_hashfn(pid)]; procp && procp->pid != pid;
         procp = procp->pidhash_next)
            ;

    return procp;
}

LMK_PROCREMOVE

// 上层处理逻辑在 ProcessList.remove 中
    public static final void remove(int pid) {
        ByteBuffer buf = ByteBuffer.allocate(4 * 2);
        buf.putInt(LMK_PROCREMOVE);
        buf.putInt(pid);
        writeLmkd(buf);
    }

// lmkd 处理逻辑
static void cmd_procremove(int pid) {
    // 若是使用kernel接口,return
    if (use_inkernel_interface)
        return;

    // 更新数据结构，pid 的 hashtable 以及进程优先级的双向链表 table
    pid_remove(pid);
}

static int pid_remove(int pid) {
    int hval = pid_hashfn(pid);
    struct proc *procp;
    struct proc *prevp;

    for (procp = pidhash[hval], prevp = NULL; procp && procp->pid != pid;
         procp = procp->pidhash_next)
            prevp = procp;

    if (!procp)
        return -1;

    if (!prevp)
        pidhash[hval] = procp->pidhash_next;
    else
        prevp->pidhash_next = procp->pidhash_next;

    // 进程优先级的table
    proc_unslot(procp);
    free(procp);
    return 0;
}

从上面的处理逻辑就能看出来，三种 command 的处理逻辑中都对 use_inkernel_interface 的状况下作了特殊处理，在 use_inkernel_interface 的状况下，作的事情都是很简单的，只是更新一下文件节点。若是不使用 kernel interface，就须要 lmkd 本身维护两个 table，在每次更新 adj 的时候去更新 table。且在初始化的时候也能看到，若是不使用 kernel 的 lowmemorykiller，则须要 lmkd 本身获取手机内存状态，若是匹配到了 minfree 中的等级，则须要经过杀掉一些进程释放内存。

小结

use_inkernel_interface 该值后续应该会逐渐采用用户空间策略。不过目前仍为 use_inkernel_interface = 1 ，则：

        ✨ 1. LMK_TARGET：AMS.updateConfiguration() 的过程当中调用 updateOomLevels() 方法, 分别向 /sys/module/lowmemorykiller/parameters 目录下的 minfree 和 adj 节点写入相应信息；
        ✨ 2. LMK_PROCPRIO: AMS.applyOomAdjLocked() 的过程当中调用 setOomAdj(),向 /proc/<pid>/oom_score_adj 写入 oomadj，则直接返回；
        ✨ 3. LMK_PROCREMOVE：AMS.handleAppDiedLocked 或者 AMS.cleanUpApplicationRecordLocked() 的过程，调用 remove()，目前不作任何事，直接返回；

Kernel

前面提过，大多状况实际上是使用 kernel interface 的，其实也就是 kernel 中的 lowmemorykiller。

lowmemorykiller driver 位于 kernel-3.18/drivers/staging/android/lowmemorykiller.c。

lowmemorykiller 中是经过 linux 的 shrinker 实现的，这个是 linux 的内存回收机制的一种，由内核线程 kswapd 负责监控，在 lowmemorykiller 初始化的时候注册 register_shrinker。

lowmemorykiller 初始化

static struct shrinker lowmem_shrinker = {
    .scan_objects = lowmem_scan,
    .count_objects = lowmem_count,
    .seeks = DEFAULT_SEEKS * 16
};

static int __init lowmem_init(void)
{
... ...

    register_shrinker(&lowmem_shrinker);

... ...
}

static void __exit lowmem_exit(void)
{
    unregister_shrinker(&lowmem_shrinker);
}

经过 register_shrinker 和 unregister_shrinker 分别用于初始化和退出。

minfree/min_adj

// 下面两个数组分别表明了两个参数文件中的默认值，数组默认的 size 都是 9
// 对应 "/sys/module/lowmemorykiller/parameters/adj"
static short lowmem_adj[9] = {
    0,
    1,
    6,
    12,
};
// 对应 "/sys/module/lowmemorykiller/parameters/minfree"
static int lowmem_adj_size = 9;
int lowmem_minfree[9] = {
    3 * 512,    /* 6MB */
    2 * 1024,    /* 8MB */
    4 * 1024,    /* 16MB */
    16 * 1024,    /* 64MB */
};
static int lowmem_minfree_size = 9;

shrinker

当内存不足时 kswapd 线程会遍历一张 shrinker 链表，并回调已注册的 shrinker 函数来回收内存 page，kswapd 还会周期性唤醒来执行内存操做。每一个 zone 维护 active_list 和 inactive_list 链表，内核根据页面活动状态将 page 在这两个链表之间移动，最终经过 shrink_slab 和 shrink_zone 来回收内存页，有兴趣想进一步了解 linux 内存回收机制，可自行研究。

lowmem_count

static unsigned long lowmem_count(struct shrinker *s,
                  struct shrink_control *sc)
{
... ...

        // ANON表明匿名映射，没有后备存储器；FILE表明文件映射； 内存计算公式= 活动匿名内存 + 活动文件内存 + 不活动匿名内存 + 不活动文件内存
    return global_page_state(NR_ACTIVE_ANON) +
        global_page_state(NR_ACTIVE_FILE) +
        global_page_state(NR_INACTIVE_ANON) +
        global_page_state(NR_INACTIVE_FILE);
}

lowmem_scan

当触发 lmkd，则先杀 oom_score_adj 最大的进程，当 oom_adj 相等时,则选择 rss 最大的进程。

static unsigned long lowmem_scan(struct shrinker *s, struct shrink_control *sc)
{
    struct task_struct *tsk;
    struct task_struct *selected = NULL;
    unsigned long rem = 0;
    int tasksize;
    int i;
    short min_score_adj = OOM_SCORE_ADJ_MAX + 1;
    int minfree = 0;
    int selected_tasksize = 0;
    short selected_oom_score_adj;
    int array_size = ARRAY_SIZE(lowmem_adj);
    
        // 获取当前剩余内存大小
    int other_free = global_page_state(NR_FREE_PAGES) - totalreserve_pages;
    int other_file = global_page_state(NR_FILE_PAGES) -
                        global_page_state(NR_SHMEM) -
                        global_page_state(NR_UNEVICTABLE) -
                        total_swapcache_pages();

        ... ...

        // 获取数组大小
    if (lowmem_adj_size < array_size)
        array_size = lowmem_adj_size;
    if (lowmem_minfree_size < array_size)
        array_size = lowmem_minfree_size;
        
        // 遍历 lowmem_minfree 数组找出相应的最小 adj 值
    for (i = 0; i < array_size; i++) {
        minfree = lowmem_minfree[i];
        if (other_free < minfree && other_file < minfree) {
            min_score_adj = lowmem_adj[i];
            break;
        }
    }

        ... ...

    if (min_score_adj == OOM_SCORE_ADJ_MAX + 1) {
            ... ...
        return 0;
    }

    selected_oom_score_adj = min_score_adj;


    rcu_read_lock();
    for_each_process(tsk) {
        struct task_struct *p;
        short oom_score_adj;

        if (tsk->flags & PF_KTHREAD)
            continue;

        p = find_lock_task_mm(tsk);
        if (!p)
            continue;

            ... ...

        if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
            time_before_eq(jiffies, lowmem_deathpending_timeout)) {
            task_unlock(p);
            rcu_read_unlock();
            spin_unlock(&lowmem_shrink_lock);
            return SHRINK_STOP;
        }
        oom_score_adj = p->signal->oom_score_adj;

            // 小于目标adj的进程，则忽略
        if (oom_score_adj < min_score_adj) {
            task_unlock(p);
            continue;
        }

            // 获取的是进程的 Resident Set Size，也就是进程独占内存 + 共享库大小
        tasksize = get_mm_rss(p->mm);

        task_unlock(p);
        if (tasksize <= 0)
            continue;
            // 算法关键，选择 oom_score_adj 最大的进程中，而且 rss 内存最大的进程
        if (selected) {
            if (oom_score_adj < selected_oom_score_adj)
                continue;
            if (oom_score_adj == selected_oom_score_adj &&
                tasksize <= selected_tasksize)
                continue;
        }

        selected = p;
        selected_tasksize = tasksize;
        selected_oom_score_adj = oom_score_adj;
        lowmem_print(2, "select '%s' (%d), adj %d, score_adj %hd, size %d, to kill\n",
                 p->comm, p->pid, REVERT_ADJ(oom_score_adj), oom_score_adj, tasksize);
    }

    if (selected) {
        long cache_size = other_file * (long)(PAGE_SIZE / 1024);
        long cache_limit = minfree * (long)(PAGE_SIZE / 1024);
        long free = other_free * (long)(PAGE_SIZE / 1024);
        trace_lowmemory_kill(selected, cache_size, cache_limit, free);

            // 输出 kill 的 log
        lowmem_print(1, "Killing '%s' (%d), adj %d, score_adj %hd, state(%ld)\n"...);
        lowmem_deathpending_timeout = jiffies + LOWMEM_DEATHPENDING_TIMEOUT;
        set_tsk_thread_flag(selected, TIF_MEMDIE);
            ... ...

            // //向选中的目标进程发送 signal 9 来杀掉目标进程
        send_sig(SIGKILL, selected, 0);
        rem += selected_tasksize;
    } else {
        if (d_state_is_found == 1)
            lowmem_print(2, "No selected (full of D-state processes at %d)\n", (int)min_score_adj);
    }

    lowmem_print(4, "lowmem_scan %lu, %x, return %lu\n",
             sc->nr_to_scan, sc->gfp_mask, rem);
    rcu_read_unlock();
    spin_unlock(&lowmem_shrink_lock);
    return rem;
}

当以下节点数据发送变化时，会经过修改 lowmem_minfree[] 和 lowmem_adj[] 数组：

/sys/module/lowmemorykiller/parameters/minfree
/sys/module/lowmemorykiller/parameters/adj

总结

本文主要从 frameworks 的 ProcessList.java 调整 adj，经过 socket 通讯将事件发送给 native 的守护进程 lmkd；lmkd 再根据具体的命令来执行相应操做，其主要功能更新进程的 oom_score_adj 值以及 lowmemorykiller 驱动的 parameters (包括 minfree 和 adj )；

最后讲到了 lowmemorykiller 驱动，经过注册 shrinker，借助 linux 标准的内存回收机制，根据当前系统可用内存以及 parameters 配置参数( adj , minfree )来选取合适的 selected_oom_score_adj，再从全部进程中选择 adj 大于该目标值的而且占用 rss 内存最大的进程，将其杀掉，从而释放出内存。

参考

01. http://gityuan.com/2016/09/17...
02. https://blog.csdn.net/u011733...
03. https://blog.csdn.net/su74952...
04. http://gityuan.com/2018/05/19...