【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 內存最大的進程，將其殺掉，從而釋放出內存。