手机"8+8G 内存"和 Linux swap 到底是不是一回事？

总有人说开启内存扩展手机会变卡，也有人说这就是 Linux swap 的翻版。 我把 AOSP 和 Linux 内核源码都翻了一遍，结果发现——两边都说对了一部分。

打开安卓手机的开发者选项，你应该见过一个开关：

内存扩展。 有的厂叫"智慧运存"，有的叫"内存融合"，有的叫"虚拟内存"，名字五花八门，但原理是一样的。

网上典型的声音有两类，各有各的道理，也各有各的误区：

先听听"反对派"怎么说

"别开！开了手机变卡，还伤闪存寿命，纯属智商税。"

把手机当服务器玩 swap？听听他们的担心有没有道理。

再听听"支持派"怎么说

"这不就是 Linux 的 swap 吗？服务器用了多少年了，怎么到手机上就成智商税了？"

技术原理确实相通，但手机真能照搬服务器那一套吗？

两边都觉得自己有理。你说哪个对？

代码不会骗人。我翻了一周源码，把两边的说法对照着验证了一遍。

一、"反对派"的担心：开启内存扩展到底有什么代价？

这部分确实不是空穴来风。开启内存扩展至少会带来四个实际问题：

1.1 zRAM 压缩解压消耗 CPU

手机的内存扩展优先走 zRAM——用 LZ4 或 Zstd 算法对冷内存页做压缩。压缩和解压都需要 CPU 参与。

正常用着手机不觉得有什么，但在以下场景你会直接感受到：

切回一个被压缩过的 App → CPU 先解压 → 再加载 → 前台动画掉帧 → 你觉得"卡了一下"

AOSP 源码中，zRAM 的交换活动会被记录到 PSI（Pressure Stall Information）信号中。LMKD 在第 2860-2890 行监听这个信号：

/* 计算颠簸率：有多少被换出去的页又被请求了 */
thrashing = (workingset_refault_file - init_ws_refault) * 100 / (base_file_lru + 1);

thrashing 值越高，说明越多的冷数据在被反复换入换出——CPU 大部分时间花在压缩解压而不是真正干活上。这跟 Linux 服务器上 swap 颠簸是一个道理。

1.2 闪存寿命写入

zRAM 满了之后，多余的数据会落到 UFS 闪存 swap 上。Android 的 swap 分区就分配在 UFS 上。

源码第 1999-2008 行：

static inline int64_t get_free_swap(union meminfo *mi) {
    if (swap_compression_ratio)
        return std::min(mi->field.free_swap,
                        mi->field.easy_available * swap_compression_ratio);
    return mi->field.free_swap;
}

正常的冷数据写闪存，只要不是高频颠簸，对现代 UFS 的寿命影响可以忽略。但如果物理内存确实太小、后台应用太多，一直触发闪存 swap 写入——UFS 的写入寿命确实会加速消耗。

1.3 额外耗电

CPU 压缩解压要耗电，UFS 读写也要耗电。正常用手机内存够的时候，这两部分能耗是零。开了扩展后，后台应用的冷数据一直在被"搬来搬去"——电量消耗虽然不是天文数字，但确实是多出来的。

1.4 物理内存大的时候，弊大于利

如果你的手机是 12GB 或 16GB 物理内存，正常使用根本吃不光。这时候开启扩展，系统反而会因为"看到了更多的总内存"而倾向于留住更多后台应用，然后你就被迫承担 zRAM 压缩解压的 CPU 开销和偶尔的卡顿——好处几乎没有，坏处实打实。

所以"反对派"说"开了会卡"——在一定条件下确实成立。

二、"支持派"的理由：这和 Linux swap 确实是同根同源的

这部分也站得住脚。把两者放在一起比，底层机制确实一模一样。

2.1 内核是同一个人写的

Linux 内核源码 mm/vmscan.c 是整个 swap 机制的实现。当物理内存吃紧时，内核的 kswapd 内核线程被唤醒，遍历 LRU 链表： - 把不活跃的页面筛选出来 - 写入 swap 分区（硬盘/SSD） - 腾出物理内存

AOSP LMKD 读取的内核统计量和 Linux 是一样的。第 430-440 行：

/* LMKD 直接从 /proc/meminfo 读取 */
"Active(anon):",      // 活跃匿名页
"Inactive(anon):",    // 不活跃匿名页（和 Linux 的 inactive_list 对应）
"SwapTotal:",         // swap 总大小
"SwapFree:",          // swap 剩余
"SwapCached:",        // 换回仍在 swap 里的页

这些字段在 Linux 服务器上 cat /proc/meminfo 也能看到完全一样的名字。

2.2 swap 利用率的算法一样

第 2696 行：

static int calc_swap_utilization(union meminfo *mi) {
    int64_t swap_used = mi->field.total_swap - get_free_swap(mi);
    int64_t total_swappable = mi->field.active_anon +
                              mi->field.inactive_anon +
                              mi->field.shmem + swap_used;
    return total_swappable > 0 ? (swap_used * 100) / total_swappable : 0;
}

就是 已用 swap / 可 swap 内存——和 Linux 上 free -m 看 swap 利用率是同一个逻辑。

2.3 杀进程决策树也是基于 swap 状态

第 2980 行：

if (swap_is_low && wmark < WMARK_HIGH) {
    kill_reason = LOW_MEM_AND_SWAP;
} else if (wmark < WMARK_HIGH &&
           swap_util_max < 100 &&
           (swap_util = calc_swap_utilization(&mi)) > swap_util_max) {
    kill_reason = LOW_MEM_AND_SWAP_UTIL;
} else if (wmark < WMARK_HIGH && thrashing > thrashing_limit) {
    kill_reason = LOW_MEM_AND_THRASHING;
}

三路决策和 Linux 内核的内存回收逻辑一一对应：swap 不足 → 回收、swap 利用率高 → 回收、颠簸 → 回收。

所以"支持派"说"这就是 Linux swap"——从底层机制上说，确实没错。

三、"两边都说对了一部分"——到底哪边对了哪边错了？

四、zRAM —— 安卓和 Linux swap 最重要的那道分水岭

安卓在物理内存里单独划了一块区域叫 zRAM，用 LZ4 / Zstd 压缩冷数据：

3GB 冷数据 → LZ4 压缩 → 占用 ~1.5GB 物理内存

压缩过的数据还在物理内存，不写闪存。这是安卓在 Linux swap 之上最有价值的改进——既缓解了内存压力，又不让闪存背上额外的写入负担。

代价是压缩和解压都消耗 CPU。切回一个已经被压缩的 App，你会感觉到：

1. 解压那段冷数据
2. 再加载到物理内存
3. 再渲染到屏幕

这几步加在一起，就是台式机和服务器上没有的、手机独有的"卡顿感"。

五、到底要不要开？

两边的事实都摆出来了，不同配置的人应该有不同的答案：

六、结论

两派都说了真话，但都只说了一半。

说"开了会卡"的人——在 12GB 物理内存的旗舰机上，他们是对的。但在 6GB 设备上，不开的内存不足导致的频繁杀后台，比开了带来的轻微卡顿更影响体验。

说"就是 Linux swap"的人——从源码层面完全正确。但忽略了手机上多出来的 zRAM 缓冲层和提前杀进程的 LMKD，这两者在服务器上是没有的。手机上 swap 的执行细节比服务器多了几道工序。

内存扩展技术本身没问题，问题出在预期管理上。 拿 6GB 设备的扩展故事去套 16GB 旗舰机，只会让用户骂厂商；拿旗舰机的体验去否定所有内存扩展的价值，也不公平。

代码不会骗人。 两边的说法到源码里一对，都能找到部分正确的依据，也都能找到被夸大的部分。

免责声明 本文引用的 Android 源码来自 AOSP（Android Open Source Project）主线分支（main），对应 Android 15+（API 35） 以 system/memory/lmkd/lmkd.cpp 为主； Linux 内核源码来自 Linux 主线 6.x 版本，以 mm/vmscan.c 为主。 各手机厂商（小米、OPPO、vivo、荣耀等）可能对 LMKD 参数、zRAM 配置、 内存扩展策略做了不同程度的定制和魔改，实际表现以各厂具体实现为准。 本文仅分析开源代码层面的通用机制，不保证覆盖所有厂商的魔改版本。 源码地址： AOSP：https://android.googlesource.com/platform/system/memory/lmkd/ Linux：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/