iOS 内存管理深度剖析(上):你以为的＂内存＂其实有 5 种

这是 iOS 内存深度剖析系列的第一篇——原理篇。 本系列共三篇：

• 上篇 · 原理篇（本文）：从虚拟内存到 ARC，jetsam 杀进程的真实逻辑。
• 中篇 · 场景与优化篇：图片解码 / Autorelease 池 / 循环引用 / 大对象生命周期。
• 下篇 · 实战篇：5 类 OOM 形态 / Memory Graph / MetricKit / 线上止损 Playbook。

同一个 Notification Service Extension，调试时跑得好好的，上线后大量用户反馈"通知图片不显示"。一查崩溃日志全是 OOM——内存才用了 28MB，怎么就被系统杀了？

这是 iOS 工程师最常见的困惑之一。背后有一个反直觉的事实：你看到的"内存"，其实是 5 种完全不同的东西混在一起。它们的成本天差地别、被系统看待的方式也不同，但大多数 iOS 工程师从来没把它们分清楚。

这一篇我们就把这 5 种内存讲透——从虚拟内存到物理内存、从 ARC 引用计数到 isa 指针、从 dirty page 到 jetsam 杀进程的真实决策——让你下次看到内存崩溃报告，能立刻知道问题出在哪一层。

全文阅读时间约 15 分钟，建议收藏后慢慢看。

一、内存视角：iOS 的"内存"到底指什么

1.1 虚拟内存 vs 物理内存：进程看到的地址全是假的

讨论 iOS 内存之前，先建立一个最重要的认知：你在代码里看到的所有指针、所有内存地址，都是"假地址"——准确说叫虚拟地址（Virtual Address）。

NSObject *obj = [NSObject new];NSLog(@"%p", obj);   // 输出 0x00006000017c0040

这个 0x00006000017c0040不是物理内存上的真实位置，而是 iOS 内核给你这个进程分配的"虚拟地址空间"里的一个编号。每个进程都有自己独立的虚拟地址空间——64-bit 系统理论上每个进程的虚拟地址空间能到几百 TB（2^47量级），iOS 实际给用户态进程的范围比这小，但仍远超物理内存能提供的。

但你的设备只有 6GB / 8GB 物理内存，怎么可能给你这么大的虚拟空间？答案是：虚拟地址要通过页表（page table）映射到物理地址才能真正使用。

进程视角（虚拟地址空间）              物理内存（实际 RAM）────────────────────────              ─────────────────0x00006000017c0000  ──┐                  ┌─── 真实的 16KB 物理页                      ├── 页表映射 ──────┤0x00006000017c4000  ──┤                  ├─── 另一张物理页                      │                  │0x00006000017c8000  ──X (没映射)         └─── 还没分配

关键认识：

• 进程"看到"的地址全是虚拟的
• 虚拟地址只有在访问的那一瞬间才会被映射到物理内存
• 没访问过的地址，物理内存里什么都没有

这个机制是 iOS 内存管理的基石——后面所有内容都建立在这个认知之上。

1.2 一个 App 的内存图谱

打开 Instruments 看一个真实 App 的内存分布，会发现它由很多种"段"组成：

这些只是用户态可见的部分。内核态还有页表、文件 cache 等，但开发者一般不需要关心。

1.3 用 vmmap 实际看一个 App 的内存分布

最直观的方式是用 vmmap命令（macOS 自带）：

# 模拟器 / Mac Catalyst App：直接用 pidvmmap <pid> | head -50

真机上 vmmap受限不能直接调用，几条替代路径：

• Xcode → Debug → Memory Graph：右下角 Statistics 面板能看到分类内存（最方便）
• 真机 sysdiagnose：长按音量+电源 5 秒触发，导出后在报告里能找到完整的 vmmap输出
• Instruments → VM Tracker：可视化版本

输出长这样（这只是简化版本，§4.6 会展示完整版做 footprint 推导）：

==== Writable regions for process YourApp [12345]REGION TYPE                      VIRTUAL   RESIDENT   DIRTY__TEXT                            350M       80M       0K     ← 代码段（clean）__DATA                             18M       16M      16Mmapped file                       200M       50M       0K     ← mmap 文件MALLOC heaps                      160M      150M     150M     ← 堆（malloc / new）Image IO / IOSurface               60M       60M      60M     ← 解码图片CoreAnimation                       8M        8M       8MStack                              16M        2M       2M     ← 主线程 + 子线程栈

关键三列：

• VIRTUAL：虚拟地址空间占用（你"申请"了多少）
• RESIDENT：实际占用的物理内存（真正用了多少）
• DIRTY：被写过的"脏页"（这个数字才是 jetsam 真正关心的）

反直觉的事实：

• __TEXT段虚拟空间 350MB，但 dirty 是 0——代码段只读，永远不脏
• mapped file200MB，但 dirty 也是 0——mmap 文件不修改就不脏
• Stack那行 VIRTUAL=16M 是所有线程的栈虚拟空间总和（每个线程预留 ~1MB / 512KB），RESIDENT=2M 才是实际访问到的——栈只在用到的部分占物理内存
• 真正贡献内存压力的是 MALLOC和 Image IO这些 DIRTY 高的区域

这就引出了核心结论：内存压力 = dirty page 数量，不是 RESIDENT 总量。这个区分是后面所有内存优化的基础。

记住一句话：决定你的 App 会不会被系统杀的不是"看着用了多少内存"，而是 dirty page 有多少。后面 §四 会把"为什么是 dirty"这件事彻底拆开讲。

1.4 iOS 没有传统 swap，但有压缩内存

桌面操作系统（macOS / Linux / Windows）在内存不够时会把不活跃的页写到磁盘 swap 分区，腾出物理内存。但 iPhone 上没有传统 swap——闪存写入次数有限，写入也太慢。

iOS 的替代方案是 memory compressor（内存压缩器）——iOS 7 / macOS 10.9（2013 年）就引入了：

内存压力小：   active page → 留在物理内存内存压力大：   inactive page → 用 WKdm 算法压缩 → 仍留在物理内存                                        （压缩比通常 2:1 ~ 3:1）内存压力极大：   还压不下 → 系统通过 jetsam 杀进程

这是为什么你看到的 RESIDENT 数字有时候比实际"在用"的内存大——一部分已经被压缩了。vmmap输出里的 Compressed那一行就是压缩内存的统计。

iPad 是个例外：iPadOS 16.1 起，搭载 M1 / M2 芯片且 8GB+ RAM 的 iPad 引入了真正的 swap（Apple 称为 "Virtual Memory Swap"），系统按需将不活跃内存写入闪存。iPhone 至今没有 swap。

二、ObjC 内存管理：ARC 不是魔法

ObjC 的 isa / SideTable / weak 机制网上深度文章很多（draveness、sunnyxx 等），重复讲意义不大。这一章只讲三件讲机制时常被遗漏、但和性能直接挂钩的事：① 引用计数到底有多便宜 ② weak 自动 nil 的代价 ③ 一行属性赋值的真实代价。

2.1 引用计数到底有多便宜——nonpointer isa 的精妙之处

很多教程会讲"每个对象都有一个 retainCount 字段"——这是简化但不准确的说法。真实情况：64-bit 时代起，引用计数被压进了 isa 指针的 19 bit 位域里（叫 nonpointer isa）。

为什么能塞进去？因为：

• arm64 用户态虚拟地址实际只用 47-48 bit
• 类指针按 8 字节对齐，低 3 bit 永远是 0
• 所以 64 bit 里能挤出大约 19 bit 空闲位

Apple 把它做成了位域，最关键的字段：

完整定义在 libobjc 的 objc-private.h。位域 bit 数在不同架构（arm64 真机 / arm64 模拟器 / x86_64）有差异，但设计思想一致。

这个设计的真正性能意义：

[obj retain] 的成本：  99% 情况：一次 CAS 原子操作（修改 isa 的 extra_rc 位）→ 几纳秒   1% 情况：引用计数 > 524288，溢出到 SideTable → 加锁 + 查表 → 几百纳秒

也就是说——绝大多数 retain/release 没有锁、不查表。这是 ObjC ARC 在 iOS 这种单核时代过来的语言里仍然能保持高性能的根本。

2.2 SideTable 与 weak 的自动 nil

SideTable 是什么：当 isa 的 19 bit 不够时（极少见）、或者需要存 weak 引用列表时，runtime 会把数据外置到一个全局哈希表 SideTable——按对象地址哈希到 64 张表中的一张（分散降锁竞争）。

weak 指针自动置 nil 的实现也在这里：

• __weak赋值时，runtime 把 weak 指针的地址记到对应对象的 weak_table 里
• 目标对象 dealloc 时，runtime 遍历 weak_table，把所有指向自己的 weak 指针逐一写为 nil

性能代价：

• __weak赋值比 __strong慢一个数量级（要查表 + 加锁）
• 在循环里频繁创建 weak 引用是反模式——例如 for cell in cells { __weak typeof(self) wself = self; ... }，wself应该提到循环外只创建一次

2.3 一行 self.obj = newObj的真实代价

ARC 的本质是编译器自动帮你插 retain/release 代码——它是编译期机制，不是运行时机制。

你写的：

self.obj = newObj;

编译器实际展开为：

objc_storeStrong(&self->_obj, newObj);// 内部：objc_retain(newObj) → 写指针 → objc_release(prev)

真实成本：1 次原子 retain + 1 次指针赋值 + 1 次原子 release。

如果 release 后引用计数归 0，还会链式触发完整的 dealloc 流程：

1. 调用对象自己的 -dealloc
2. 释放该对象的所有 strong ivar（每个又触发一次 release——可能递归）
3. 通知 weak_table 把所有 weak 引用置 nil
4. 通知关联对象表清理
5. 沿继承链调用父类的 dealloc（直到 NSObject）
6. 调 free把内存归还给分配器

实战结论：在性能敏感的代码里——比如列表 cell 的 layoutSubviews、动画的每帧回调——减少不必要的 strong 属性赋值能带来可观的性能收益。这是大多数"ObjC 源码分析"文章会漏掉的实操结论：他们只讲机制，不讲"机制对你的代码意味着什么"。

记住一句话：ARC 不是运行时机制——它是编译器在你看不到的地方插了 retain/release 代码。你写得越简洁，它替你插得越多。self.obj = newObj是 3 次操作，不是 1 次。

三、Swift 内存管理：与 ObjC 同根但不同枝

Swift 的内存管理本质上和 ObjC 是同一套机制——都是 ARC + 引用计数。但它在三个地方有显著不同。

3.1 Swift 的引用计数：strong / weak / unowned

ObjC 只有 strong和 weak，Swift 多了一个 unowned：

Swift 的 unowned默认是 unowned(safe)——仍维护一份轻量的 unowned reference count，访问已释放对象时 runtime 能检测到并抛错（不会任意访问垃圾内存）。如果用 unowned(unsafe)才是真正的裸指针，性能更好但完全不安全。

unowned(safe)比 weak性能更好——不需要维护 weak_table、不需要 Optional 解包——但用错就崩溃。常见安全用法：

classPerson{let name: Stringlazyvar greet: () -> String = { [unownedself] inreturn"Hello, \(self.name)"// self 一定存在，因为闭包是 self 的属性    }init(name: String) { self.name = name }}

实操建议：90% 场景用 weak，只在确信生命周期的关键热点路径用 unowned。

3.2 Value type 的"没有引用计数"假象

Swift 的 struct/ enum/ tuple是 value type——赋值是复制，没有引用计数。但有个反直觉的事实：

Swift 的 Array / Dictionary / String / Set 都是 struct，但内部用了引用计数 + COW（Copy-On-Write）：

var a = [1, 2, 3, 4, 5]   // a 持有一个引用计数为 1 的 buffervar b = a                 // 没有复制！b 和 a 共享同一个 buffer，引用计数变为 2b.append(6)               // 触发 COW：检测到旧 buffer 引用计数 > 1// → 给 b 复制一份新 buffer// → b 释放对旧 buffer 的引用// 最终：a 持有旧 buffer（计数 1）、b 持有新 buffer（计数 1）

这意味着：

• let a = bigArray; let b = a看起来是值类型复制——实际不复制
• 一旦其中一个被修改，才真正复制
• 这个判断用 isKnownUniquelyReferenced(&buffer)在 runtime 完成

性能特征：

• 读多写少的场景：和引用类型一样快，零拷贝
• 多人共享 + 高频写入：每次写入前都要做一次 isKnownUniquelyReferenced检查，遇到共享时复制 buffer——这是为什么大型 SwiftUI 项目里偶尔出现 "Array 操作慢" 的根因

3.3 ARC + Generics + Existential 的特殊性能特征

这一节相对底层，对日常开发不感兴趣的可以跳过——只需要记住结论："性能热点路径上，泛型比协议类型快"。

Swift 比 ObjC 多了一类内存开销：Existential Container（存在性容器）。当你把一个值类型装进协议类型时，Swift 需要一个固定大小的容器来存它：

protocolDrawable{ funcdraw() }structCircle: Drawable{ var x, y, r: Double; funcdraw() { /* ... */ } }let circles: [Drawable] = [Circle(x: 0, y: 0, r: 1)]//   ^^^^^^^ 这里发生了什么？

[Drawable]数组里每个元素必须固定大小（因为数组要按 index 计算偏移），但 Circle是 24 字节、其他实现 Drawable的类型可能更大。Swift 用 Existential Container解决这个问题（单协议存在性容器）：

Existential Container（5 word = 40 字节，arm64）┌─────────────────────────────────────────────────┐│ Inline storage (3 word = 24 字节)               │ ← 不超过 24 字节直接存这里│ Type metadata pointer (1 word = 8 字节)         │ ← 类型元数据│ Witness table pointer (1 word = 8 字节)         │ ← 协议方法的虚函数表└─────────────────────────────────────────────────┘

Witness table 可以理解为"协议方法的虚函数表"——每个实现该协议的类型都有一份，记录了协议要求的方法实现地址。

• 不超过 24 字节的值（Circle三个 Double 正好 24 字节）：直接 inline 存储，零开销
• 大于 24 字节的值：堆分配一个 buffer，container 里存 buffer 指针——额外的堆分配 + 引用计数

性能影响：

// 性能不好：每个元素都要走 Existential Container，大对象还要堆分配let shapes: [Drawable] = [...]shapes.forEach { $0.draw() }   // 每次调用走 witness table 间接分发// 性能好：泛型在编译期被特化（specialization）——编译器为每种 T 生成专门的代码funcdrawAll<T: Drawable>(_ items: [T]) {    items.forEach { $0.draw() }   // 直接调用，无虚分发}

实操建议：性能敏感的代码用泛型而不是协议类型——在热点路径上能换来 2-5 倍性能提升。

记住一句话：Swift 的引用计数比 ObjC 少了 SideTable 哈希查找的开销，但多了 Existential Container 这个"装协议类型的容器"——前者是优化，后者是新增成本。

四、5 类内存页：dirty / clean / compressed / swap / mmap

这一章是后面所有内存优化的基础——读者如果只看一章，建议看这章。

4.1 五类内存页的成本对比表

iOS 上的内存页按"成本"可以分成 5 类：

三个反直觉的结论：

1. __TEXT段（代码）几百 MB 不算内存压力——它是 clean，系统压力大就丢，再要用从磁盘读回
2. mmap 一个 200MB 大文件不算内存压力——只要不写入它
3. 真正贡献 jetsam 杀进程概率的是 dirty page——这是 iOS 内存优化的核心目标

4.2 dirty page 是 iOS 杀进程的核心指标

为什么 dirty page 是关键？因为它不能被丢弃。这是和 clean page 最本质的区别：

clean page：物理内存不够 → 丢掉它 → 数据还在磁盘 → 要用时从磁盘读回dirty page：物理内存不够 → 丢不掉  → 必须压缩 / 写 swap / 杀进程

iOS 内核在内存压力大时，会按这个顺序处理：

① 释放 clean page（free 即可，无副作用）   ↓ 还不够② 压缩 inactive 的 dirty page（compressed memory）   ↓ 还不够③ 写入 swap（仅高端 iPad）   ↓ 还不够④ 触发 jetsam，杀掉一个进程释放它的所有 dirty page

这就把"footprint"这个核心指标解释清楚了：

• Crash 报告里的 "Footprint"≈ dirty page + compressed 之和
• 30MB Extension 内存上限，限制的就是 footprint
• 优化内存的第一目标：减少 dirty page

4.3 clean page 几乎免费

clean page 的典型例子是 __TEXT段——你的 App 二进制里的代码，被 mmap 进内存，永远只读、永不修改。下篇 §4.6 会展示完整 vmmap 输出——你会看到 __TEXT那行 RESIDENT 几十甚至上百 MB，但 dirty 永远是 0。

这就是为什么大型 App（QQ 几百 MB 二进制）启动后看着内存占用很大，但实际不会因此被杀。

Apple 在这点上做了大量优化：

• __DATA_CONST段：fixup 后变只读，从 dirty 转为 clean
• __DATA_DIRTY段：明确标识"这一块永远是 dirty 的"，方便监控
• dyld_shared_cache：所有 App 共享同一份系统库的 clean 内存映射

4.4 compressed memory：iOS 的"软 swap"

iOS 7 起内置的 memory compressor 工作机制：

进程 A 的 dirty page：   active 时：留在物理内存（占 16KB）   inactive 后：用 WKdm 压缩 → 占 4KB-8KB（仍在物理内存）   再被访问时：解压缩 → 重新变成 16KB dirty page效果：   原来 100MB dirty → 实际占用 35-50MB   压缩比一般 2:1 ~ 3:1

对开发者的影响：

• App 在后台时间长了，dirty 会逐渐变成 compressed（看起来 RESIDENT 在降）
• 切回前台访问时会有"解压缩成本"——多数 App 几毫秒到几十毫秒，大型 App 用户能感觉到一瞬间的卡顿
• compressed 仍然算进 footprint，仍然会让你被 jetsam 杀

4.5 mmap 文件：既不是 dirty 也不是 clean

mmap是个特殊存在——它把磁盘文件映射到虚拟地址空间：

int fd = open("big_file.dat", O_RDONLY);void *ptr = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);// 现在 ptr 指向的虚拟内存就是文件内容

关键特征：

• 读取时：触发 page fault，从磁盘读 16KB 到物理内存（clean page）
• 不读取时：不占物理内存
• 写入时（如果是 MAP_PRIVATE）：触发 COW，复制一份变成 dirty page

实战用法：

• 大图直接用 mmap加载——只占虚拟地址空间，物理内存按需读
• SQLite 的 WAL 模式底层就是 mmap
• Data(contentsOf: url, options: .alwaysMapped)也是 mmap

陷阱：mmap一个超大文件不会立刻 OOM，但遍历访问它会让所有页都被 page-in 进物理内存，瞬间内存暴涨。

4.6 实战：算一算你 App 的真实 footprint

理解了 5 类页之后，我们用一个真实场景把它们串起来——你 App 在 Xcode Memory Debug 里看到的"200 MB"，到底有多少会被 jetsam 算进 footprint？

假设一个中型 App 的 vmmap 摘要长这样：

REGION TYPE                      VIRTUAL   RESIDENT   DIRTY    SWAPPED__TEXT                            350M       80M       0K       0K__DATA_CONST                       40M       38M       0K       0K__DATA                             18M       16M      16M       0Kmapped file                       200M       50M       0K       0KMALLOC heaps                      160M      150M     150M       0KImage IO / IOSurface               60M       60M      60M       0KCoreAnimation                       8M        8M       8M       0KStack                              16M        2M       2M       0KCompressed                          0K       30M      30M       0K─────────────────────────────────────────────────────────────────Sum                              ~852M     ~434M    ~266M       0K

Xcode 顶部显示的 "Memory: 434 MB"≈ RESIDENT 总和。但这个数字不是 jetsam 真正看的。

真实 footprint 的算法（简化版）：

footprint = 各行的 dirty 之和 + Compressed         = 16M[__DATA] + 150M[MALLOC] + 60M[ImageIO] + 8M[CoreAnimation]           + 2M[Stack] + 30M[Compressed]         = 266M

也就是说：

• Xcode 看到 434MB，但只有 266MB 计入 footprint
• 其中 __TEXT80MB / __DATA_CONST38MB / mapped file50MB 完全不算——它们是 clean，系统压力大就丢掉
• Compressed30MB 要算进去——压缩了仍然是 dirty 的"另一种形态"

这解释了几个常见困惑：

1. "为什么我减小图片资源 App 占用没降？"：图片资源放在 Bundle 里，加载时是 clean page（mmap），减它对 footprint 没影响——除非你减的是运行时解码后的位图（IOSurface）。

2. **"为什么大型 App（QQ、微信）二进制几百 MB 还能跑？"**：因为 __TEXT几乎全是 clean，不计入 footprint。这就是为什么文章上一节 "QQ 几百 MB 二进制启动后实际不会因此被杀"——现在你看到了完整推理。

3. "为什么后台 App 看起来用了 100MB 还是被杀了？"：因为后台 App footprint 上限只有 ~50-200 MB，你 100MB 全是 dirty，已经接近红线。

实操方法：怎么算自己 App 的真实 footprint？