乐趣区

Android 8.1源码_进程篇 — LowMemoryKiller 原理分析

核心源码

关键类
路径

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 同样希望自身尽可能存活更长的时间,甚至探索各种保活黑科技。物极必反,系统处于低内存的状态下,手机性能会有所下降;系统继续放任所有进程一直存活,系统内存很快就会枯竭而亡,那么需要合理地进程回收机制。
到底该回收哪个进程呢?系统根据进程的组件状态来决定每个进程的优先级值 ADJ,系统根据一定策略先杀优先级最低的进程,然后逐步杀优先级更低的进程,依此类推,以回收预期的可用系统资源,从而保证系统正常运转。
LowMemoryKiller 机制就是系统用于判定是否需要杀进程和杀哪些进程的一个机制。
进程优先级
系统内进程优先级分 5 级:

进程
说明

前台进程(Foreground process)
用户当前操作所必需的进程。

可见进程(Visible process)
没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。可见进程被视为是极其重要的进程,除非为了维持所有前台进程同时运行而必须终止,否则系统不会终止这些进程。

服务进程(Service process)
正在运行已使用 startService() 方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联,但是它们通常在执行一些用户关心的操作(例如,在后台播放音乐或从网络下载数据)。因此,除非内存不足以维持所有前台进程和可见进程同时运行,否则系统会让服务进程保持运行状态。

后台进程(Background process)
包含目前对用户不可见的 Activity 的进程(已调用 Activity 的 onStop() 方法)。这些进程对用户体验没有直接影响,系统可能随时终止它们,以回收内存供前台进程、可见进程或服务进程使用。

空进程(Empty process)
不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存,以缩短下次在其中运行组件所需的启动时间。为使总体系统资源在进程缓存和底层内核缓存之间保持平衡,系统往往会终止这些进程。

Framework OOM Adjustment
我们看看进程优先级的相关代码:
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 采用数字 1、2、3,这样的调整可以更进一步地细化进程的优先级,比如在 VISIBLE_APP_ADJ(100)与 PERCEPTIBLE_APP_ADJ(200)之间,可以有 ADJ=101、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…

退出移动版