【iOS】内存：从页面状态、Memory Footprint 到 OOM

#为什么虚拟地址不等于物理内存

首先推荐阅读：Friday Q&A 2012-12-28: What Happens When You Load a Byte of Memory 中译版： 读取一字节内存时发生了什么

Apple 在 WWDC18《iOS Memory Deep Dive》中以典型的 16 KiB 页面说明：内存系统以页为粒度管理和统计资源，一个页面可以容纳多个堆对象，一个对象也可能跨越多个页面。因此，哪怕程序只修改其中一个字节，受影响的仍可能是整个页面。

这里不能把 ”内存使用量” 笼统地理解为所有虚拟地址范围。虚拟地址空间大小、当前驻留的物理页、堆分配量和系统用于限制 App 的 Memory Footprint 是不同指标。后文所说的 footprint，重点关注 App 需要系统保留的 dirty 与 compressed 页面，而 clean 页面可以从原始来源重新建立，因此记账方式不同。

#进程级汇总与逐个 VM Region

上一篇通过 VM Region 观察进程地址空间中的一段段连续范围；这一篇转向整个进程的内存汇总指标。task_basic_info、mach_task_basic_info 描述的是整个任务（进程）的虚拟内存和驻留内存汇总信息，不是单个 VM Region：

1
/* 当前 SDK 的注释已明确建议改用 MACH_TASK_BASIC_INFO */
2
struct task_basic_info {
3
    integer_t       suspend_count;
4
    vm_size_t       virtual_size;
5
    vm_size_t       resident_size;
6
    time_value_t    user_time;
7
    time_value_t    system_time;
8
    policy_t        policy;
9
};
10

11
struct mach_task_basic_info {
12
    mach_vm_size_t  virtual_size;
13
    mach_vm_size_t  resident_size;
14
    mach_vm_size_t  resident_size_max;
15
    time_value_t    user_time;
16
    time_value_t    system_time;
17
    policy_t        policy;
18
    integer_t       suspend_count;
19
};

这段代码只是两个返回结构的定义，本身不会主动统计内存。程序调用 Mach 的 task_info()，并选择 MACH_TASK_BASIC_INFO，系统才会把任务级数据写入 mach_task_basic_info。当前 SDK 已把 task_basic_info 标为旧接口，新的代码应使用始终采用 64 位大小字段的 MACH_TASK_BASIC_INFO。

其中与本篇最相关的字段是：

因此要区分两种观察尺度：

1
VM Region / vmmap
2
    → 逐段观察地址范围、权限和内容来源
3

4
MACH_TASK_BASIC_INFO
5
    → 观察整个进程的 virtual_size 与 resident_size 汇总
6

7
TASK_VM_INFO.phys_footprint
8
    → 观察更接近 iOS Memory Footprint 口径的进程责任内存

virtual_size、resident_size 与 phys_footprint 不能互相替代。后面的真机实验使用 task_info(TASK_VM_INFO) 读取 phys_footprint，正是因为本篇要研究的是 App 当前承担的内存责任，而不只是地址空间有多大或多少页面暂时驻留。

图示来源：Apple《Identifying high-memory use with Jetsam Event Reports》。

#路径一：malloc、首次访问与 Dirty Page

以上一篇实验代码中的 RunMemoryExperiment（见上一篇）为例：malloc(32 * 1024) 申请一段 32 KiB 空间，与 memset(heapBuffer, 0x5A, 1) 真正触碰其中一个字节，并不是同一个动作。分配器可能先为程序准备可用的虚拟地址；当程序首次访问相应页面时，系统才通过按需分页机制建立页面支持。实际变化还会受到页面是否已经存在、写入是否落在同一页以及分配器元数据等因素影响，所以不能机械地推导出” 每写一个字节，Memory Footprint 就一定增加 16 KiB”。

#iPhone 15 真机实测：malloc 与首次写入

我在 iPhone 15（iOS 26.5.2，16 KiB 页面）上连续运行两次同一份 Debug 实验。程序分别在 malloc(32 * 1024) 之前、申请之后和写入第一个字节之后，通过 task_info(TASK_VM_INFO) 读取 phys_footprint：

这两轮数据共同支持一个结论：申请 32 KiB 堆空间没有立刻表现为 footprint 增加 32 KiB。malloc 返回了可用地址，但虚拟地址范围、分配器可用空间和进程当前承担的物理内存不是同一个指标。

第一轮首次写入后，显示值增加约 0.02 MiB，与一个 16 KiB 页的量级接近；但第二轮在保留两位小数的瞬时采样中没有显示变化。因此，不能把第一轮结果直接总结成 “写一个字节必然增加一页”：

1. 分配器可能复用已经存在并已承担 footprint 的页面，而不是为本次 32 KiB 请求建立全新 Region；
2. 采样值保留两位小数，16 KiB 只约等于 0.0156 MiB，显示结果会受到舍入影响；
3. task_info 读取的是进程总体 footprint，同一时刻其他运行时活动也可能产生变化；
4. phys_footprint 的三次总量采样不能单独证明究竟是哪一页变 dirty，也不能直接给出 clean、dirty、compressed 各自的页数。

所以这次实验支持的是 “分配和首次触碰必须分开观察”，而不是 “由一组三次采样精确归因一个页面”。如果要进一步验证每次写入影响了哪些页面，应把缓冲区按 16 KiB 步长逐页写入，并结合 VM Tracker、Memgraph 或更细的 VM 统计重复对照。

当 App 开始写入页面时，相关页面可能从 clean 变为 dirty。下面这张图描述的是 ”已分配” 和 ”已写入” 在页面状态上的区别，而不是上一篇五大分区中的新区域。

图示来源：Apple《Reducing your app’s memory use》。

#路径二：Copy-on-Write 与 Private Dirty Page

上一篇提到，Mach-O 的 __DATA 段这类可写数据可能通过 Copy-on-Write 形成进程私有页面——这里补上具体机制：

1. __DATA 对程序通常表现为可写的 VM Region，但它的共享模式可以是 Copy-on-Write。页面内容尚未被当前进程修改时，可以继续复用文件支持或共享的物理页，此时内容仍是 clean。
2. 当程序第一次写入相应页面时，底层只读保护会触发一次可以修复的 Page Fault。内核识别出这是合法的 COW 写入，于是为当前进程建立私有副本，再完成这次写入。这里的 “底层保护” 不等于 App 看到的 VM Region 是 r--；在 vmmap 或 memory region 中，它仍可以显示为 rw-。
3. 从这一刻起，这个页面的内容已经和原文件产生分歧，不再能靠重新读文件恢复——这正是 dirty 的定义。它变成了一个进程私有的、系统必须负责保管的页面。

在 vmmap 的描述中，这类 Region 可以同时显示为可写权限 rw- 和共享模式 COW；Apple 的 Viewing Virtual Memory Usage 也专门区分了访问权限和共享模式。

在本文关注的 iOS App 内存模型里，未修改的文件支持 clean page 可以在压力下丢弃并重新载入；不能直接丢弃的 private／dirty page 才是内存压缩主要处理的对象。被压缩后，数据仍保存在物理内存中，只是占用空间变小，后续访问时需要解压。

新申请的匿名虚拟地址可能尚未获得对应的驻留物理页；当程序真正写入时，系统才按需建立页面支持，并使相关页面进入 dirty 状态。非可丢弃的 dirty page 不能像 clean 文件页那样直接丢弃，但 App 可以主动释放它，系统也可以压缩它；压力仍无法缓解时，系统可能终止进程。

#两条路径的区别

1
匿名堆内存：
2
malloc → 获得可用虚拟地址 → 首次写入 → 匿名 Dirty Page
3

4
文件支持内存：
5
Clean／共享页面 → 首次写入触发 COW → Private Dirty Page

两条路径的起点不同：前者从新申请的匿名地址开始，后者从已有的文件支持或共享页面开始；但实际写入以后，它们都可能形成需要当前进程负责的 dirty memory。下面再分别说明 Clean、Dirty 与 Compressed 到底代表什么。

#Clean memory

Clean 描述的是页面内容可以从原始来源重新取得，而不是页面 “没有占用物理内存”，也不是说这段地址只能读、不能写。访问权限由 VM Region 的 r--、rw- 等属性决定，Clean／Dirty 描述的是页面内容是否已经发生需要保留的修改，这两个维度不能混在一起。

常见的 clean memory 包括：

1. 尚未被修改的可执行文件和系统 Framework 代码页；
2. 尚未被修改的只读数据和文件映射页面，例如按需载入的图片文件、模型文件；
3. 内容仍与原始文件一致、在压力下可以丢弃并在以后重新读取的页面。

Clean page 既可能已经驻留并占用 RAM，也可能尚未进入物理内存。系统在压力下可以丢弃可重建的 clean page，需要时再从文件载入，而不是把这类页面先压缩保存。

内存映射文件也不一定永远是 clean 或只读：只读且未修改的文件映射通常保持 clean；如果映射允许写入并且内容被修改，相应页面就可能变成 dirty。Framework 的 __DATA_CONST 也不会因为 App “使用了这个 Framework” 就自动变 dirty，真正的判断依据仍然是页面是否发生了需要私有保存的修改。

#Dirty memory

Dirty 表示页面内容已经被修改，不能在不保存内容的情况下直接丢弃并依靠原始文件恢复。它不是 “永远不能重复使用” 的内存：App 主动释放对象后，相关空间仍可以被分配器重新利用；在内存压力下，系统也可以压缩近期不活跃的 dirty page。

常见来源包括：

1. 已经实际写入的堆对象和缓冲区；
2. 图片解码后的像素缓冲，例如 ImageIO、Core Graphics 或 IOSurface 相关内存；
3. 缓存、可变集合，以及 Framework 中实际需要写入的 __DATA、__DATA_DIRTY 页面；
4. 文件支持页面经过 Copy-on-Write 后形成的进程私有副本。

这里不能简单地说 “所有 heap allocation 都是 dirty”。malloc 返回地址并不代表整段空间已经获得并写入了对应物理页；尚未触碰的部分、分配器复用的页面和分配器元数据都可能让实际结果与申请字节数不同。

理解工具结果时还要区分：

1
Allocations
2
→ 关注堆上发生了哪些分配
3

4
Dirty Size
5
→ 关注哪些页面已经被写入并需要进程负责

例子：80,000 字节会覆盖多少页？

如果缓冲区恰好从页边界开始，按 16 KiB 一页计算：

1
ceil(80,000 / 16,384) = 5 页

如果起始地址没有页对齐，它也可能跨越 6 个页面。通过 malloc(80000) 申请时，分配器还可能复用已有 Region，所以这个计算只表示地址范围最多跨过多少页，不能直接证明系统新分配了同样数量的物理页。

当程序第一次写入某个尚未承担实际内容的页面时，该页才可能进入 dirty 状态。只写第一页和最后一页，不代表中间所有页面都会同时变 dirty。

#Compressed memory

iOS 可以把近期不活跃、又不能直接丢弃的页面压缩后保留。压缩比例取决于页面内容，没有一个可以通用于所有数据的固定比例；再次访问这些页面时，系统需要先解压。

Compressed memory 并没有消失：压缩后的实际存储体积可能比未压缩时更小，但内容仍属于 App 的内存责任。Apple 的工具文档还明确说明，系统对 compressed／swapped dirty memory 的 Footprint 记账按照压缩前的原始大小计算，因此不能把 “已经压缩” 理解成 “App 的内存账单已经减少”。压缩和解压还会消耗 CPU，所以内存压力也可能表现为性能与能耗问题。

在本文采用的 App 内存模型中，三种状态可以用下面这条常见路径连接起来：

1
共享/文件映射（可能是 clean） --首次写入触发 COW--> 私有 dirty 页 --内存压力--> compressed

#Xcode 显示的 App 内存是怎么来的

前面已经出现过三个容易混淆的进程级指标，它们回答的不是同一个问题：

Xcode 中关注的 Memory Footprint 更接近第三种，而不是把虚拟地址范围或所有驻留页面简单相加。在 Apple 面向开发者的内存模型中，分析 Footprint 时主要关注 Dirty Memory 与 Compressed Memory：dirty 页面不能依靠原始文件直接恢复；它被压缩以后，内容仍需要系统替 App 保存，而且记账使用压缩前的原始大小。

Clean Memory 即使已经驻留，也可能占用物理 RAM；但它的内容能够从可执行文件、Framework 或映射文件重新取得，系统可以在压力下丢弃并在以后重新载入。因此，Clean Memory 通常不是降低 App Footprint 时的首要目标。

上图和 “Dirty + Compressed” 用于理解和优化，不是 phys_footprint 内核实现的完整数学公式。实际记账还会涉及其他系统内存类别，本文不把开发者模型写成一条绝对等式。

#不要依赖桌面式 Swap 为 App 兜底

桌面操作系统通常可以把一部分匿名内存换出到磁盘。较早的 iOS 内存资料常用 “iOS 没有传统 Swap” 强调移动系统不会让前台 App 依靠无限增长的匿名 dirty memory 长期运行。这个结论表达了正确的开发约束，但放到现代 iOS 上不能再写成绝对事实。

Apple 当前的 Reducing your app’s memory use 已经说明，iOS 可能把运行在后台的内存密集型 App 转移到固态存储；相关工具也会使用 compressed／swapped dirty memory 的表述。公开文档没有要求开发者把这一实现直接等同于桌面系统逐页换出的传统 Swap，因此这里不进一步猜测系统内部细节。

这也不等于 “iOS 的虚拟内存以前从不读取存储设备”。App 的可执行文件、动态库和内存映射文件本来就可以按需 page in；clean 的文件映射页被丢弃后，也可以在需要时重新读取。对于开发者，始终成立的结论是：不能期待系统通过存储转移替不断增长的 Footprint 兜底，更不能因此忽略内存峰值和后台内存。

#系统怎样处理不同状态的页面

前面已经解释了 Compressed memory 的定义。把它放进内存压力场景后，系统面对不同页面时大致有两种选择：

1
仍能从原始文件重新取得的 Clean Page
2
    → 可以直接回收，需要时重新载入
3

4
不能直接丢弃的 Dirty Page
5
    → 可以压缩近期不活跃的内容，后续访问时再解压

因此，压缩不是释放，只是系统在有限 RAM 中继续保留 dirty 内容的一种方式。如果回收 clean page、压缩 dirty page，以及 App 自己释放可重建资源以后仍不足以缓解压力，系统才可能需要终止进程来快速回收内存。

#Memory Warning 与 Jetsam

Memory Warning 和 Jetsam 是两种不同机制，都可能出现在系统处理内存压力的过程中，但不能把它们理解成一条 “必定先警告、不处理再杀” 的固定流程：

• Memory Warning（didReceiveMemoryWarning）是 UIKit 层面的建议性通知，发给还活着、还能执行代码的进程，本质是系统在说” 压力大了，你自己看着办、主动释放点缓存”。它不保证发生在终止之前，也不保证每个即将被终止的进程都收到过。

• Jetsam 是内核层面的强制终止机制，持续监控每个进程的 footprint 和系统整体压力，一旦超过阈值——可能是某进程自己的硬限制，也可能是系统整体压力排序后选中它——就会直接终止，不需要也不保证先经过任何 App 代码。尤其是后台进程，往往根本没有机会运行代码去响应警告，会被直接 Jetsam。

开发者事后能看到的是 Jetsam Event Report，它不同于由异常或信号产生的常规 crash report：进程是被内核从外部终止的，而不是自己触发了某个信号。

App 收到内存警告后，应该释放已经明确标记为可重建、当前又不需要的资源，并减少后续分配，而不是临时遍历整个对象图寻找 “看起来能删” 的内容。后者可能访问并解压长期未使用的页面，在压力最大的时刻制造额外峰值。Apple 的 Responding to low-memory warnings 也建议提前调整分配策略，而不是在警告到来后扫描整个对象图。

所以准确的说法是：忽略内存警告可能增加被 Jetsam 的概率，但 Jetsam 完全可以在没有任何前置警告的情况下发生，比如一个后台进程的 footprint 悄悄涨过了线。

#App 为什么会被推向 OOM

OOM 不等于内存泄漏。泄漏可能让 footprint 长期单调上升，但没有泄漏的程序也可能因为瞬时峰值超过限制而被终止。常见来源可以分成两类。

#第一步：确认终止类型

• 查找对应的 Jetsam Event Report 或系统提供的终止诊断，确认目标进程、终止原因、当时的进程状态和内存数据。
• 如果拿到的是普通 crash report，则先检查异常类型、触发线程和调用栈，不要预设它一定是 OOM。
• 没有收到 didReceiveMemoryWarning 不能排除 OOM；收到过警告也不能证明最终一定由高内存终止。

Jetsam 既可能由单进程限制触发，也可能发生在系统整体内存压力下。但不能把它简化成 “后台一定先于前台、占用高的一定先于占用低的、用户 App 一定先于系统进程” 的固定排序。内核还会考虑进程的 priority band、活跃状态、具体限制、coalition 和本次事件的 reason。下面这份真机日志就记录了系统守护进程因 per-process-limit 被移除，而当时占用更高的第三方前台进程没有被移除。

1
~/Library/Developer/Xcode/DeviceLogs/<设备>/Other Logs/JetsamEvent-*.ips

1
{
2
  "bug_type": "298",
3
  "timestamp": "2026-06-22 10:51:37 +0800",
4
  "os_version": "iPhone OS 26.5 (23F77)"
5
}

1
{
2
  "product": "iPhone15,4",
3
  "memoryStatus": {
4
    "pageSize": 16384
5
  },
6
  "largestProcess": "<第三方前台进程，已脱敏>",
7
  "processes": [
8
    {
9
      "name": "<第三方前台进程，已脱敏>",
10
      "states": ["active", "frontmost"],
11
      "rpages": 73572,
12
      "lifetimeMax": 87958
13
    },
14
    {
15
      "name": "assetsd",
16
      "states": ["daemon", "idle"],
17
      "rpages": 1454,
18
      "reason": "per-process-limit",
19
      "lifetimeMax": 4596
20
    }
21
  ]
22
}

1
pageSize = 16,384 bytes = 16 KiB

1
当前使用量 ≈ rpages × pageSize
2
生命周期峰值 ≈ lifetimeMax × pageSize

1
name   = assetsd
2
reason = per-process-limit

1
rpages × pageSize
2
= 1,454 × 16,384
3
= 23,822,336 bytes
4
≈ 22.72 MiB

1
lifetimeMax × pageSize
2
= 4,596 × 16,384
3
= 75,300,864 bytes
4
≈ 71.81 MiB

1
rpages = 73,572
2
当前使用量约为 1,149.56 MiB
3

4
lifetimeMax = 87,958
5
生命周期峰值约为 1,374.34 MiB

1
错误顺序：
2
看到 largestProcess → 直接认定它 OOM
3

4
正确顺序：
5
在 processes 中搜索 reason
6
        ↓
7
确认被移除的进程与终止原因
8
        ↓
9
结合 pageSize、rpages、lifetimeMax 和 states 分析

#第二步：观察增长形态

1
重复操作后持续上升、很少回落
2
    → 优先排查泄漏、缓存和对象生命周期
3

4
某个操作瞬间陡升，随后本应回落
5
    → 优先排查图片解码、大缓冲区、多份副本和并发峰值
6

7
进入后台后更容易被终止
8
    → 检查后台仍保留的大资源和后台状态下更紧张的系统预算

不同设备、前后台状态以及 App 与 Extension 的限制可能不同，因此不要背诵一个 “所有 iPhone 通用的 OOM 阈值”。调试时应在目标设备和真实业务路径上观察趋势与峰值。

#第三步：选择对应工具

工具之间不能互相替代：Leaks 没有发现泄漏，不代表不存在图片解码或并发任务造成的峰值；Allocations 主要观察堆分配，也不能单独解释所有 VM、图形和压缩内存。正确顺序是先用 footprint 和报告确定现象，再根据增长来源缩小范围。

#我们能做些什么？

这部分我目前还缺少足够的大型项目治理经验，不适合总结一套 “照着做就不会 OOM” 的固定清单。不过从前面的页面模型和诊断方法出发，至少可以先做几件明确的事：

• 给缓存设置数量或成本边界，不让字典、图片和历史数据无限增长；
• 加载图片时关注解码后的像素尺寸，需要缩略图时优先用 ImageIO 下采样；
• 限制图片解码、数据解析和模型任务的并发数，避免多个合理任务叠出不合理峰值；
• 避免新旧两份大数据、缓冲区或模型长时间同时存在；
• 在进入后台或页面不可见后，释放当前不需要、又可以重新载入的大资源；
• 检查不必要的启动期初始化、Framework 和全局数据，确认它们是否在启动路径中过早制造长期存活的 dirty memory；
• 用同一台真机重复同一条业务路径，比较基线、峰值、操作结束后的回落和多轮执行后的趋势。

对于可以重新创建的缓存，NSCache 通常比无上限的 NSMutableDictionary 更合适：它支持自动淘汰策略，也允许从多个线程查询和修改。但淘汰时机与顺序不是业务代码可以依赖的确定保证，仍应合理设置 countLimit 或 totalCostLimit，具体行为见 Apple 的 NSCache 文档。NSPurgeableData 则适用于内容可以被丢弃的数据；只有在内容没有被标记为正在使用时，系统才可能在低内存情况下丢弃它。

下面两篇工程案例涉及线上监控、归因和治理，适合作为实践层面的延伸阅读：

• iOS 性能优化实践：头条抖音如何实现 OOM 崩溃率下降 50%+
• 你真的了解 OOM 吗？——京东 iOS App 内存优化实录