3、自动释放池：RunLoop与内存峰值控制
自动释放池，说白了就是 Objective-C 里的一种内存延迟释放机制。很多开发者觉得它就是个「自动回收站」，用完就扔。但在我多年的性能优化经验里，它其实是控制内存峰值的关键武器。
你想想看，一个 App 在运行过程中，会创建大量临时对象。如果每个对象都立刻释放，那内存波动会非常剧烈。自动释放池的作用，就是把这些对象的释放时机「攒」起来，等到一个合适的时机统一处理。
3.1 自动释放池的基本原理
每个自动释放池在底层对应一个 _objc_autoreleasePoolPage 对象。它是一个栈结构，当你调用 autorelease 时，对象指针被压入栈顶。当池子被销毁时，栈里的所有对象都会收到一次 release 消息。
我记得有一次排查内存泄漏，发现某个页面退出后内存没降下来。用 Instruments 一查，原来是某个循环里创建了大量临时对象，但没及时释放。嗯，这里要注意：自动释放池不是万能的，它只是延迟释放，不是不释放。
核心要点：自动释放池的释放时机由 RunLoop 决定。主线程的 RunLoop 在每次事件循环结束时，会自动销毁和重建自动释放池。
3.2 RunLoop 与自动释放池的协作
RunLoop 是 iOS 应用的事件处理循环。它每处理完一个事件源（比如触摸事件、定时器回调），就会执行一次自动释放池的 pop 操作。具体流程是这样的：
- RunLoop 进入休眠前，创建新的自动释放池
- 处理事件期间，所有 autorelease 对象都加入当前池
- 事件处理完毕，RunLoop 唤醒后，销毁旧池并创建新池
为什么会这样设计？说白了就是为了保证事件处理期间的对象能存活到事件结束。比如你处理一个按钮点击，中间创建了几个临时字符串，如果立刻释放，那后续代码就访问不到了。
个人经验：我在做 IM 聊天列表优化时，发现每条消息的富文本渲染会创建大量临时对象。如果不做处理，一次刷新就能让内存飙升 50MB。后来我在 cellForRow 的外层加了一个手动自动释放池，峰值直接降到了 10MB 以内。
3.3 内存峰值控制的实战技巧
内存峰值，就是一瞬间内存占用达到的最高点。自动释放池控制峰值的核心思路是：把大块的内存释放拆成小块，避免一次性堆积。
来看一个典型场景：循环创建大量图片对象。
// 问题代码：内存峰值会很高
for (int i = 0; i < 1000; i++) {
UIImage *image = [UIImage imageNamed:[NSString stringWithFormat:@"img_%d", i]];
// 处理 image...
}
// 优化代码：手动添加自动释放池
for (int i = 0; i < 1000; i++) {
@autoreleasepool {
UIImage *image = [UIImage imageNamed:[NSString stringWithFormat:@"img_%d", i]];
// 处理 image...
}
}第一段代码里，1000 个 UIImage 对象全部堆积在同一个自动释放池里，直到循环结束才释放。第二段代码每处理一个就释放一个，内存峰值自然就降下来了。
注意：自动释放池不是越细越好。每创建一个池子都有开销，如果循环体非常轻量（比如就创建几个小对象），加池子反而会降低性能。我建议在循环体内创建的对象超过 100 个，或者单个对象占用内存超过 1MB 时，才考虑加池子。
3.4 子线程与自动释放池
很多开发者容易忽略一点：子线程默认没有自动释放池。如果你在子线程里创建了 autorelease 对象，又没有手动创建池子，这些对象就会泄漏。
我曾经接手过一个项目，后台下载任务处理图片时，内存只增不减。查了半天发现是子线程的 autorelease 对象没人管。解决方案很简单：
// 子线程的正确写法
dispatch_async(dispatch_get_global_queue(0, 0), ^{
@autoreleasepool {
// 你的业务代码
for (int i = 0; i < 100; i++) {
// 创建临时对象...
}
}
});嗯，这里要记住：只要是子线程的长时间任务，最外层一定要包一个 @autoreleasepool。
3.5 常见误区与避坑指南
| 误区 | 正确理解 |
|---|---|
| 自动释放池能解决所有内存问题 | 它只解决延迟释放问题，循环引用、大对象等问题仍需其他手段 |
| 池子嵌套越多越好 | 嵌套会增加管理开销，一般两层就够 |
| ARC 下不需要关心自动释放池 | ARC 只是帮你插入了 retain/release，autorelease 机制依然存在 |
| @autoreleasepool 只用于循环 | 任何需要控制内存峰值的场景都适用，比如大图解码、数据解析 |
避坑指南：我曾经在某个版本里，为了追求极致性能，在 tableView 的 cellForRow 里嵌套了多层自动释放池。结果发现滑动反而变卡了。后来用 Instruments 一测，池子的创建销毁开销比对象释放节省的内存还大。所以，适度使用，不要过度优化。
3.6 性能监控与调优建议
怎么判断你的自动释放池用得对不对？我一般用两个指标：
- 内存峰值：用 Xcode 的 Memory Report 或 Instruments 的 Allocations 工具，观察单次事件处理期间的内存增长
- 对象存活时间：在 Allocations 里勾选「Record Reference Counts」，看 autorelease 对象的释放时机
如果发现某个事件处理期间内存暴涨超过 20MB，那大概率是自动释放池没用好。这时候可以尝试在关键位置插入手动池子，或者把大任务拆分成多个小任务，让 RunLoop 有机会在中间释放内存。
我的习惯：在开发阶段，我会在 viewDidLoad 和 viewDidDisappear 里各加一个断点，观察内存变化。如果退出页面后内存没回到进入前的水平，那肯定有对象没释放。这时候先检查是不是自动释放池的问题，再查循环引用。
最后说一句：自动释放池是 iOS 内存管理的基石之一。理解它和 RunLoop 的协作关系，你就能在内存峰值控制上游刃有余。别把它当成黑盒，把它当成你工具箱里的一把精密螺丝刀。