5-26.【性能分析与优化】闭包捕获 self，除了循环引用问题，还可能带来哪些性能隐患？一句话总览（结论先行）下面一

一句话总览（结论先行）

闭包捕获 self 的最大性能隐患不是内存泄漏，而是：

ARC 热点（retain/release 风暴）

值类型被迫逃逸到 heap

跨线程 retain 的原子成本

优化被阻断（内联 / 特化 / 去虚）

UI / 响应节奏被无意中拉慢

下面一个一个说清楚。

1️⃣ ARC retain/release 成为热路径

发生机制

items.forEach {
    self.process($0)
}

closure 是 heap object
self 被捕获 → retain
每次执行 closure：
- retain self
- 调用
- release self

如果在：

for-loop
map / filter
SwiftUI body
Combine pipeline

👉 retain/release 会直接出现在 Time Profiler 前几名

Instruments 信号

swift_retain
swift_release
调用栈在 closure invoke

2️⃣ 值类型逃逸（隐蔽但很贵）

这是非常非直觉性的点。

struct Model {
    let data: [Int]
}

let model = Model(...)
items.forEach {
    use(model)
}

你以为：

捕获的是 struct
没有 ARC

实际上：

closure 是 heap object
捕获的值必须和 closure 生命周期一致
struct 被 box 到 heap
访问它 → ARC

👉 你以为在用值语义，实际上已经是引用语义

Allocations 特征

小对象（existential / box）
生命周期和 closure 一样

3️⃣ 跨线程 retain 的原子成本

DispatchQueue.global().async {
    self.work()
}

ARC 在多线程下是 原子操作
retain / release 需要 memory fence
成本比单线程高得多

高危场景

大量短 async task
TaskGroup
高频并发 map

👉 CPU 不高，但耗时明显

4️⃣ 编译器优化被阻断（最容易被忽略）

问题本质

一旦 self 被 closure 捕获：

编译器必须假设：
- self 可能逃逸
- 生命周期不可预测
结果：
- ❌ 无法内联
- ❌ 无法消除 retain
- ❌ 无法做泛型特化
- ❌ 无法消除 CoW

对比

// ✅ 易优化
func work(_ x: inout Model) { ... }

// ❌ 优化受限
items.forEach {
    self.work(model)
}

👉 不是 closure 慢，而是 closure 让优化失效

5️⃣ SwiftUI / Combine 中的“隐式风暴”

SwiftUI

var body: some View {
    Button("Tap") {
        self.state += 1
    }
}

body 频繁计算
closure 频繁创建
self 捕获 → ARC 抖动

Combine

publisher
    .map { self.transform($0) }
    .sink { self.handle($0) }

每个 operator 一个 closure
self 在整个 pipeline 被 retain

👉 链式 API = ARC 放大器

6️⃣ closure 捕获 self 的“性能误区”

❌ 误区 1：`[weak self]` 就没性能问题了

{ [weak self] in self?.work() }

weak 本身也是 runtime 机制
每次访问都有：
- load
- nil-check
在热路径中仍然不便宜

❌ 误区 2：只要不循环引用就安全

不泄漏 ≠ 不慢
热路径 retain/release 比泄漏更常见

7️⃣ 什么时候捕获 self 是“安全的”？

场景	为什么 OK
closure 非 escaping	编译期可优化
单次 async	ARC 可摊销
UI 事件（低频）	不在热路径
self 是轻量 final class	retain 可被优化

8️⃣ 工程级应对策略（重点）

✅ 1️⃣ 提前解构 self

let service = self.service
items.forEach {
    service.process($0)
}

closure 捕获具体字段
减少 retain/release self

✅ 2️⃣ 热路径不用 closure

for i in items {
    process(i)
}

比 map / forEach 快得多（真的）

✅ 3️⃣ 用泛型 / inout 替代捕获

func run<T>(_ t: T, _ f: (T) -> Void) {
    f(t)
}

✅ 4️⃣ 控制并发粒度

合并 async
批量处理
减少跨线程 retain

九、最终总结（非常重要）

闭包捕获 self 的最大性能风险是：

你在不知不觉中：

制造了 heap 对象

放大了 ARC

阻断了编译器优化

而这一切，看起来只是“一行很优雅的 Swift”。

在性能敏感代码中，我的原则是：

closure 是一种“抽象税”
捕获 self 是“复合税”

5-26.【性能分析与优化】闭包捕获 self，除了循环引用问题，还可能带来哪些性能隐患？