16G 安卓旗舰,依然养不起后台的流氓

那就加。从早年的 2GB、4GB，一路堆到 8GB、12GB，再到今天旗舰机常见的 16GB、24GB。

可手机用起来总有点不对劲。拿一台 16GB 内存的安卓旗舰，刚开机，系统页面上还显示着接近 6GB 可用内存。微信、美团、哔哩哔哩都挂在后台，打开一个大型手游玩十分钟，再切出来，微信重新加载了。

进设置看一眼，内存页面上还挂着“可用 5.8GB”。

既然还有几 GB 空闲内存，为什么后台还是被清了？

现代安卓杀后台，很多时候不是因为 DRAM 塞满了。系统更怕后台进程耗电、发热、把前台帧率拖下去。

技术文章常拿 DRAM，也就是物理内存，类比成仓库。16GB 的仓库装了 10GB，剩下 6GB 空着，理论上放着也没什么成本。

从存储数据这个角度看，没错。LPDDR5X 的自刷新功耗并不高，内存里留着数据，耗电远没有屏幕点亮、CPU 跑满、蜂窝网络上传下载那么夸张。问题不在于那些页面还占着多少字节，而在于一个没死的 App 并不会老实躺在内存里当标本。

它可能挂着定时任务，隔几十秒醒来检查一次状态；可能持续监听定位、蓝牙、计步器；可能被别的 App 通过广播或 Binder 顺手拉起来；也可能还有埋点、同步、广告、日志上传之类的后台线程没停。用户看见的是后台卡片，系统看见的是一群随时准备碰 CPU、网络和传感器的进程。

手机 SoC 的省电不是靠“少跑一点”完成的。屏幕熄灭、前台没有重负载时，处理器希望尽可能长时间停在低功耗状态，核心降频、关停，整机进入深睡眠。真正省电的是少唤醒，最好一觉睡到底。

后台 App 每弹出一个 Timer 任务，哪怕只跑几毫秒，系统都可能需要退出深度休眠、拉起合适的 CPU 核心和频率、处理任务，再回到低功耗状态。单次没什么，几十个 App 轮着来，睡眠窗口被切得稀碎。

屏幕关着，电量却每小时掉几格，机身还莫名发温。大多不是 DRAM 自刷新在作妖，是后台唤醒、网络活动和 CPU 调度没停。

所以厂商的策略很直接。内存里留着可以，别折腾。你在后台频繁拉 CPU、碰网络、链式启动别的进程，哪怕设备还空着 10GB 内存，策略进程也可能把你停掉。没有商量。

16GB 也不是完整交给 App 的 16GB。

从 Linux 的视角往下看，应用层摸到这块内存前，系统已经先切走了一部分。图形渲染要用，GPU 驱动要用，相机 ISP 和多帧合成也要用。尤其是相机，夜景、人像、HDR 连拍时，连续帧缓冲和计算摄影链路会吃掉不少内存。有些内存统计页写着“可用”，不代表此刻能拿来稳定养住一个任性后台进程。

安卓还大量依赖 ZRAM。

ZRAM 不是传统意义上把内存数据换到闪存里的 Swap，而是在 RAM 中拿出一部分空间，压缩那些暂时不用的匿名页。后台 App 占了 1GB，不代表它会原样躺在物理页里。系统可能把其中一批冷页面压缩进 ZRAM，原来 1GB 的数据压成数百 MB，给前台腾位置。

常规物理内存 (RAM)                 ZRAM 压缩区┌──────────────────────┐         ┌──────────────────────┐│ 前台应用 A (2 GB)      │         │ 后台 App B 数据       │├──────────────────────┤   压缩   │ (原本 1 GB 压缩为      ││ 前台应用 B (3 GB)      │ ──────► │ 300 MB 存放在此)      │├──────────────────────┤          └──────────────────────┘│ 系统预留/显存 (3GB)    │                     │└──────────────────────┘                     │ 重新打开时                                             ▼ 解压                                  CPU 算力飙升 / 瞬间卡顿  

压缩省的是物理页，不是计算。切回一个大量页面已经进 ZRAM 的后台 App，CPU 得解压、恢复页表映射、重新调度线程，缓存也要重新热起来。几个大 App 来回切，系统一边回收页面，一边压缩，一边解压，前台动画和触控响应就会被拖慢。

很多机型宁愿让后台应用重新加载，也不愿让用户在切换动画上看到半秒卡顿。冷启动难看，但容易归咎于 App；桌面、通知栏和手势掉帧，锅会直接落在系统头上。

Android 底层的 LMK，或者说后来的 lmkd，本身没有传说中那么凶。

它会参考进程优先级，为进程设置 oom_score_adj。前台、可见进程、前台服务、桌面、后台进程、缓存进程，分数不一样。内存压力逼近低水位线时，系统优先处理分数更高、可牺牲性更强的进程。

原生 AOSP 的这套路子，16GB 设备没必要频繁杀得满地都是尸体。

把后台搞成大逃杀的，常常是厂商在 AOSP 和 Linux 内核之外额外加的电量、温控和行为管控层。小米的 PowerKeeper、ColorOS 的后台冻结机制、OriginOS 的原子内存，名字不同，思路接近：内存水位只是一个参考，后台进程干了什么更重要。

App A 启动后试图经 Binder 拉起 App B，策略引擎可以直接拦截。B 不在前台，又不在允许范围内，那就不让它起来。微信、QQ、抖音这类高频应用往往能拿到更宽松的后台待遇；一个不知名的小工具，即便只占几十 MB，后台放几分钟也可能被标记成无效驻留，进程被清掉。后台 fork 子进程、消耗 CPU、频繁唤醒，也会让系统更快下手。

Android 12 之后，AOSP 还加入了对 phantom process 的限制。某些后台子进程如果数量过多，或者资源行为超出限制，会被系统杀掉。它主要是为了防止应用借子进程绕开后台限制，但对一些依赖辅助进程、脚本环境或旧式守护逻辑的软件来说，体验并不总是友好。

在这类策略面前，16GB 的意义会被削弱。App 被赶出去时，原因可能和“空间不够”关系不大。它被判断成了高耗电后台、异常拉活来源，或者只是没有进白名单。

也不能把账全算到国内 App 和厂商魔改头上。

安卓的麻烦来自几条路线撞在一起。Linux 进程模型允许应用保留活动能力；Android 的 Java/Kotlin 运行时带来垃圾回收、堆内存和进程生命周期管理的额外复杂度；移动设备又被一块几千毫安时的电池卡着脖子。后台多留一个活进程，就多一份唤醒、网络、计时器和资源竞争的可能。

iOS 走的是另一条更强硬的路。

应用离开前台后，绝大多数情况下会被挂起，后台执行能力被严格限定；推送通知更多依赖 APNs。Objective-C 和 Swift 的 ARC 也让对象生命周期管理的路径更明确，但 iOS 后台体验好，主要不是因为 ARC 有魔法，而是苹果从平台规则上就没给普通应用多少长期后台运行的空间。

Android 早期把更开放的后台能力当作优势。

应用可以跑服务、接广播、做同步、维持连接，开发者有更大的自由度。自由一多，保活手段也跟着膨胀。App 想常驻，系统要续航，厂商还得保住动画和游戏帧率，三边谁都不想退。

于是形成了一个很别扭的循环。

开发者为了不掉线、不漏消息、提高日活，会想办法留住后台进程；系统厂商看到后台被滥用，只能把限制再收紧；用户发现重要 App 被杀，又去买 16GB、24GB 的大内存机型，或者手动给应用加白名单。内存变大了，后台规则没变宽松，应用也没有变老实。

16GB 当然没有白加。

它能让前台游戏留下更多纹理、渲染和缓存空间，也能给相机的多帧计算留出余地。多开十几个应用时，系统不会立刻陷入回收、压缩和重启的混乱。它改善的是前台体验和短时间多任务的缓冲，不是一张“所有后台永久存活”的通行证。

只要手机还靠电池供电，只要 App 还想在后台拉 CPU、做网络请求、保活和互相唤醒，系统深处那个进程杀手就不会收刀。

往日推荐：

为什么 Linux 敢“超卖”内存，Windows 却不敢？