第十三板块：Android 综合架构与未来演进 | 第三十二篇：Android 内存管理与 LMK 机制的深度剖析
所属板块：第十三板块 --- Android 综合架构与未来演进
前置知识：第三十一篇中的宏内核/微内核对比、Linux 进程管理、虚拟内存、Zygote 的 COW 机制、Binder IPC 的 mmap 映射
本篇定位 ：这是 Android 系统在有限物理资源下维持生存的呼吸机制 。如果说 CPU 是心脏，那么 内存管理 就是 血液循坏系统 。本篇将彻底拆解 Linux 页框（Page Frame）管理 、Low Memory Killer (LMK) 的评分与收割算法 、匿名共享内存（Ashmem）与 Pss 计算 、内存回收的水位线（Watermark）机制 。我们将深入 Kernel 内存子系统 、Framework 的 ProcessList，揭示 Android 为何会"杀后台"，以及系统如何在"流畅度"与"存活率"之间进行残酷的博弈。全程无内存优化技巧、无 LeakCanary 教程，仅保留 Android 内存管理的底层定义与调度规范。
1. 核心结论先行（Thesis Statement）
Android 的内存管理是一个基于威胁感知的抢占式资源回收系统。
- 内存的本质 ：虚拟地址空间（Virtual Address Space） 。每个进程看到的 4GB（32位）或 48-bit（64位）内存都是假的，由 MMU 映射到物理 RAM 上。Android 通过 Zygote 的 COW（Copy-On-Write） 让多个进程共享同一份物理内存（Framework 代码）。
- LMK 的本质 ：基于 OOM Adj 的冷血收割者 。它不是简单的"内存不够就杀"，而是根据
oom_adj分数 和 内存压力阈值 进行精准收割。前台应用是"神"，后台服务是"草"。 - Pss 的本质 ：按比例分摊的私有内存。计算应用内存占用的唯一真理。它把共享库的内存按比例分摊给使用该库的进程，从而准确反映进程对系统的真实内存负担。
- 水位线（Watermark）的本质 ：内核的预警机制 。
min、low、high三个水位决定了何时唤醒kswapd进行回收，以及何时触发直接回收（Direct Reclaim）。
2. Android 内存架构全景图
2.1 从物理内存到应用进程
#mermaid-svg-CVMgvF3JKNDUM1S1{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-CVMgvF3JKNDUM1S1 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-CVMgvF3JKNDUM1S1 .error-icon{fill:#552222;}#mermaid-svg-CVMgvF3JKNDUM1S1 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-CVMgvF3JKNDUM1S1 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-CVMgvF3JKNDUM1S1 .marker.cross{stroke:#333333;}#mermaid-svg-CVMgvF3JKNDUM1S1 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-CVMgvF3JKNDUM1S1 p{margin:0;}#mermaid-svg-CVMgvF3JKNDUM1S1 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-CVMgvF3JKNDUM1S1 .cluster-label text{fill:#333;}#mermaid-svg-CVMgvF3JKNDUM1S1 .cluster-label span{color:#333;}#mermaid-svg-CVMgvF3JKNDUM1S1 .cluster-label span p{background-color:transparent;}#mermaid-svg-CVMgvF3JKNDUM1S1 .label text,#mermaid-svg-CVMgvF3JKNDUM1S1 span{fill:#333;color:#333;}#mermaid-svg-CVMgvF3JKNDUM1S1 .node rect,#mermaid-svg-CVMgvF3JKNDUM1S1 .node circle,#mermaid-svg-CVMgvF3JKNDUM1S1 .node ellipse,#mermaid-svg-CVMgvF3JKNDUM1S1 .node polygon,#mermaid-svg-CVMgvF3JKNDUM1S1 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-CVMgvF3JKNDUM1S1 .rough-node .label text,#mermaid-svg-CVMgvF3JKNDUM1S1 .node .label text,#mermaid-svg-CVMgvF3JKNDUM1S1 .image-shape .label,#mermaid-svg-CVMgvF3JKNDUM1S1 .icon-shape .label{text-anchor:middle;}#mermaid-svg-CVMgvF3JKNDUM1S1 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-CVMgvF3JKNDUM1S1 .rough-node .label,#mermaid-svg-CVMgvF3JKNDUM1S1 .node .label,#mermaid-svg-CVMgvF3JKNDUM1S1 .image-shape .label,#mermaid-svg-CVMgvF3JKNDUM1S1 .icon-shape .label{text-align:center;}#mermaid-svg-CVMgvF3JKNDUM1S1 .node.clickable{cursor:pointer;}#mermaid-svg-CVMgvF3JKNDUM1S1 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-CVMgvF3JKNDUM1S1 .arrowheadPath{fill:#333333;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-CVMgvF3JKNDUM1S1 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-CVMgvF3JKNDUM1S1 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-CVMgvF3JKNDUM1S1 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-CVMgvF3JKNDUM1S1 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-CVMgvF3JKNDUM1S1 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-CVMgvF3JKNDUM1S1 .cluster text{fill:#333;}#mermaid-svg-CVMgvF3JKNDUM1S1 .cluster span{color:#333;}#mermaid-svg-CVMgvF3JKNDUM1S1 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-CVMgvF3JKNDUM1S1 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-CVMgvF3JKNDUM1S1 rect.text{fill:none;stroke-width:0;}#mermaid-svg-CVMgvF3JKNDUM1S1 .icon-shape,#mermaid-svg-CVMgvF3JKNDUM1S1 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-CVMgvF3JKNDUM1S1 .icon-shape p,#mermaid-svg-CVMgvF3JKNDUM1S1 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-CVMgvF3JKNDUM1S1 .icon-shape .label rect,#mermaid-svg-CVMgvF3JKNDUM1S1 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-CVMgvF3JKNDUM1S1 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-CVMgvF3JKNDUM1S1 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-CVMgvF3JKNDUM1S1 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 应用进程
Android 特有
内核内存管理
物理内存 (RAM)
映射
映射
映射
低于 low
回收页
计算
触发
收割
页框 (Page Frames)
DMA Zone
Normal Zone
High Mem Zone
伙伴系统 (Buddy System)
Slab 分配器
kswapd (回收线程)
水位线 (min/low/high)
Low Memory Killer
oom_adj 评分
进程状态 (IMPORTANCE)
Zygote (共享库)
App 1 (私有内存)
App 2 (私有内存)
2.2 核心组件职责表
| 组件 | 层级 | 职责 | 学术定义 |
|---|---|---|---|
| 伙伴系统 (Buddy) | Kernel | 物理页分配 | 管理物理页框，解决外部碎片，以 2 的幂次方分配内存。 |
| Slab 分配器 | Kernel | 小内存分配 | 管理内核对象（如 task_struct）的缓存，解决内部碎片。 |
| kswapd | Kernel | 后台回收 | 当内存低于 low 水位时唤醒，异步回收页框到 Swap。 |
| LMK | Kernel Driver | 前台收割 | 当内存低于 min 水位或特定阈值时，同步杀死进程释放内存。 |
| oom_adj | Framework | 优先级评分 | Framework 根据进程状态计算的权重，值越低越重要。 |
3. 进程内存画像：VSS, RSS, PSS, USS
要理解 LMK，必须先理解内存的四种计算口径。
| 指标 | 全称 | 学术定义 | 是否准确 |
|---|---|---|---|
| VSS | Virtual Set Size | 进程申请的虚拟内存总量（含映射但未使用）。 | 不准确 |
| RSS | Resident Set Size | 进程实际占用的物理内存（含共享库）。 | 偏大 |
| PSS | Proportional Set Size | RSS + 共享库按进程数分摊。 | 最准确 |
| USS | Unique Set Size | 进程独占的物理内存（不含共享）。 | 偏小 |
3.1 PSS 的计算逻辑
假设有 3 个进程，共享一个 30MB 的库。
#mermaid-svg-4zarEY1Ir30WeLfw{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-4zarEY1Ir30WeLfw .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-4zarEY1Ir30WeLfw .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-4zarEY1Ir30WeLfw .error-icon{fill:#552222;}#mermaid-svg-4zarEY1Ir30WeLfw .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-4zarEY1Ir30WeLfw .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-4zarEY1Ir30WeLfw .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-4zarEY1Ir30WeLfw .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-4zarEY1Ir30WeLfw .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-4zarEY1Ir30WeLfw .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-4zarEY1Ir30WeLfw .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-4zarEY1Ir30WeLfw .marker{fill:#333333;stroke:#333333;}#mermaid-svg-4zarEY1Ir30WeLfw .marker.cross{stroke:#333333;}#mermaid-svg-4zarEY1Ir30WeLfw svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-4zarEY1Ir30WeLfw p{margin:0;}#mermaid-svg-4zarEY1Ir30WeLfw .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-4zarEY1Ir30WeLfw .cluster-label text{fill:#333;}#mermaid-svg-4zarEY1Ir30WeLfw .cluster-label span{color:#333;}#mermaid-svg-4zarEY1Ir30WeLfw .cluster-label span p{background-color:transparent;}#mermaid-svg-4zarEY1Ir30WeLfw .label text,#mermaid-svg-4zarEY1Ir30WeLfw span{fill:#333;color:#333;}#mermaid-svg-4zarEY1Ir30WeLfw .node rect,#mermaid-svg-4zarEY1Ir30WeLfw .node circle,#mermaid-svg-4zarEY1Ir30WeLfw .node ellipse,#mermaid-svg-4zarEY1Ir30WeLfw .node polygon,#mermaid-svg-4zarEY1Ir30WeLfw .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-4zarEY1Ir30WeLfw .rough-node .label text,#mermaid-svg-4zarEY1Ir30WeLfw .node .label text,#mermaid-svg-4zarEY1Ir30WeLfw .image-shape .label,#mermaid-svg-4zarEY1Ir30WeLfw .icon-shape .label{text-anchor:middle;}#mermaid-svg-4zarEY1Ir30WeLfw .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-4zarEY1Ir30WeLfw .rough-node .label,#mermaid-svg-4zarEY1Ir30WeLfw .node .label,#mermaid-svg-4zarEY1Ir30WeLfw .image-shape .label,#mermaid-svg-4zarEY1Ir30WeLfw .icon-shape .label{text-align:center;}#mermaid-svg-4zarEY1Ir30WeLfw .node.clickable{cursor:pointer;}#mermaid-svg-4zarEY1Ir30WeLfw .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-4zarEY1Ir30WeLfw .arrowheadPath{fill:#333333;}#mermaid-svg-4zarEY1Ir30WeLfw .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-4zarEY1Ir30WeLfw .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-4zarEY1Ir30WeLfw .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-4zarEY1Ir30WeLfw .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-4zarEY1Ir30WeLfw .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-4zarEY1Ir30WeLfw .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-4zarEY1Ir30WeLfw .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-4zarEY1Ir30WeLfw .cluster text{fill:#333;}#mermaid-svg-4zarEY1Ir30WeLfw .cluster span{color:#333;}#mermaid-svg-4zarEY1Ir30WeLfw div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-4zarEY1Ir30WeLfw .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-4zarEY1Ir30WeLfw rect.text{fill:none;stroke-width:0;}#mermaid-svg-4zarEY1Ir30WeLfw .icon-shape,#mermaid-svg-4zarEY1Ir30WeLfw .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-4zarEY1Ir30WeLfw .icon-shape p,#mermaid-svg-4zarEY1Ir30WeLfw .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-4zarEY1Ir30WeLfw .icon-shape .label rect,#mermaid-svg-4zarEY1Ir30WeLfw .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-4zarEY1Ir30WeLfw .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-4zarEY1Ir30WeLfw .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-4zarEY1Ir30WeLfw :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} PSS 计算
物理内存
共享库: 30MB
App A 私有: 10MB
App B 私有: 20MB
App C 私有: 5MB
App A: 10 + (30/3) = 20MB
App B: 20 + (30/3) = 30MB
App C: 5 + (30/3) = 15MB
学术定义：
- PSS 是 LMK 的唯一依据。LMK 不会看 RSS，因为它会误判共享库占用大的应用。LMK 看 PSS，因为它反映了应用对系统内存的真实消耗。
4. Low Memory Killer (LMK) 的收割算法
4.1 oom_adj 评分体系
Framework 根据进程状态计算 oom_adj。
| 进程状态 | oom_adj 值 | 学术定义 |
|---|---|---|
| 前台进程 (Foreground) | 0 | 正在与用户交互，绝不杀死。 |
| 可见进程 (Visible) | 1 | 可见但不在前台（如弹窗后），尽量不杀。 |
| 服务进程 (Service) | 2 - 5 | 后台服务，优先级较高。 |
| 缓存进程 (Cached) | 9 - 15 | 后台应用，随时可杀，回收主力。 |
| 空进程 (Empty) | 15 | 无任何组件，优先杀死。 |
4.2 LMK 的收割阈值
LMK 定义了几个内存阈值（以 MB 为单位，具体取决于设备 RAM）。
bash
# /sys/module/lowmemorykiller/parameters/minfree
18432,23040,27648,32256,36864,41472
# 对应 oom_adj
0, 1, 2, 3, 9, 15学术定义：
- 联动机制 ：当系统可用内存低于 36864 MB 时，杀死
oom_adj >= 15的进程（空进程）。 - 逐级收割 ：当内存继续下降到 18432 MB 时，杀死
oom_adj >= 0的进程（理论上不应发生，除非极端情况）。
4.3 收割逻辑源码解析
c
// drivers/staging/android/lowmemorykiller.c
static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc) {
// 1. 获取当前可用内存
int other_free = global_page_state(NR_FREE_PAGES);
// 2. 遍历进程，找到 oom_adj 最大的
for_each_process(p) {
if (p->oom_score_adj >= min_score_adj) {
// 3. 计算 PSS
pss = get_mm_rss(p->mm);
if (pss > selected_pss) {
selected = p;
selected_pss = pss;
}
}
}
// 4. 发送 SIGKILL
send_sig(SIGKILL, selected, 0);
}5. 内存回收的水位线与 kswapd
5.1 水位线（Watermark）
Linux 内核为每个内存 Zone 设置了三条水位线。
| 水位线 | 学术定义 | 行为 |
|---|---|---|
| High | 高水位 | 内存充足，kswapd 休息。 |
| Low | 低水位 | 内存紧张，唤醒 kswapd 开始后台回收。 |
| Min | 最小水位 | 内存极度匮乏，触发 Direct Reclaim（阻塞当前进程进行回收）。 |
5.2 Direct Reclaim 与卡顿
学术定义：
- Direct Reclaim（直接回收） ：当进程申请内存时，发现水位低于
min，内核会强制该进程暂停，亲自去回收内存（扫描 LRU 链表，写 Swap），直到有足够内存。这会导致 UI 卡顿。 - kswapd 的作用：避免 Direct Reclaim。kswapd 在后台悄悄回收，尽量不让前台进程感知。
6. Ashmem (匿名共享内存) 与 LMK
6.1 Ashmem 的特殊性
Ashmem 是 Android 特有的共享内存机制，常用于 Binder 传输大数据。
学术定义：
- Pin/Unpin: Ashmem 区域可以被 Pin（锁定）或 Unpin（解锁）。
- 可回收性：Unpin 的区域在内存紧张时可以被 kswapd 回收。Pin 的区域则不能被回收，容易导致 OOM。
6.2 Ashmem 与 LMK 的协作
当 LMK 杀死一个进程时，如果该进程持有 Ashmem 区域，且该区域没有其他引用者，Ashmem 区域会被释放。这是 Android 能够支持多任务的关键。
7. 关键源码深度解析
7.1 Framework 计算 oom_adj
java
// frameworks/base/services/core/java/com/android/server/am/ProcessList.java
final class ProcessList {
// 计算 adj
int computeOomAdjLocked(ProcessRecord app, ...) {
if (app.curProcState == PROCESS_STATE_TOP) {
// 前台应用
adj = FOREGROUND_APP_ADJ; // 0
} else if (app.curProcState == PROCESS_STATE_CACHED_ACTIVITY) {
// 缓存应用
adj = CACHED_APP_MIN_ADJ; // 9
}
// ...
app.setAdj(adj);
}
}7.2 查看内存状态
bash
# 查看进程 PSS
dumpsys meminfo <pid>
# 查看 LMK 阈值
cat /sys/module/lowmemorykiller/parameters/minfree
# 查看内存水位
cat /proc/zoneinfo8. 内存管理的常见误区
| 误区 | 学术解释 |
|---|---|
| 杀后台是因为内存不够 | 不完全。是因为内存低于 LMK 的阈值，且后台进程 oom_adj 太高。 |
| 大内存手机不杀后台 | 物理内存大，LMK 阈值高，确实不容易触发，但依然会杀。 |
| Service 在后台不会被杀 | 错误。Service 的 oom_adj 通常在 2-5，缓存进程满了照样杀。 |
| Native 内存泄漏不会导致 LMK | 错误。Native 泄漏同样消耗物理内存，最终触发 LMK。 |
9. 本篇总结（Knowledge Closure）
| 关键点 | 纯学术定义 |
|---|---|
| 内存的本质 | 虚拟地址到物理页框的映射，通过 Zygote COW 实现共享。 |
| LMK 的本质 | 基于 oom_adj 和 PSS 的精准收割机制，保护前台，收割后台。 |
| PSS 指标 | 衡量进程内存占用的唯一真理，按使用比例分摊共享库。 |
| 水位线机制 | min/low/high 控制 kswapd 的唤醒，防止 Direct Reclaim 导致卡顿。 |
| Direct Reclaim | 导致 UI 卡顿的元凶，由内存低于 min 水位触发。 |
10. 第十三板块结语
至此，第十三板块：Android 综合架构与未来演进 已全部完结。
我们从 宏内核的历史包袱 出发，深入 微内核的未来愿景 ，探索 Fuchsia 的 Capability 安全 ，最终抵达 内存管理的生死博弈。
我们揭示了 Android 作为移动操作系统的终极生存法则：用 Zygote 共享内存换取空间，用 LMK 收割后台换取流畅。
下一篇预告 ：第十四板块：Android 硬件抽象与安全加固 | 第三十三篇：Verified Boot 与 硬件信任链（Trusty TEE）