iOS RunLoop（二）使用场景、性能优化与避坑

引言

RunLoop 是 iOS 线程并发模型的核心组件，负责线程的休眠唤醒、事件分发和定时器调度。深刻理解 RunLoop 的运行机制，不仅有助于写出高性能的应用，更是卡顿监控、线程保活等进阶操作的基石。本文将系统梳理 RunLoop 的常见使用场景、性能优化手段以及容易被忽略的细节。

一、RunLoop 的核心使用场景

1. 线程保活与常驻线程

子线程任务执行完毕后会自动销毁。若要复用同一线程处理多个异步回调（如网络响应、端口消息），就需要通过 RunLoop “保活”。

典型做法：获取子线程的 currentRunLoop，向其中添加一个 NSPort（Source1）或 NSTimer，再调用 run。此时线程无事则休眠，有事则唤醒。

退出控制：保活线程必须提供退出机制——调用 CFRunLoopStop 或移除所有输入源/Timer，否则线程永不释放，造成内存泄漏。

实例：AFNetworking 2.x 就利用这一方式使网络回调始终在同一个后台线程执行。

2. 定时器调度（NSTimer / CADisplayLink）

• NSTimer 必须加入一个 RunLoop 的特定 Mode 才会触发。
  默认添加至 NSDefaultRunLoopMode，当用户滑动（进入 UITrackingRunLoopMode）时计时器会暂停；添加至 NSRunLoopCommonModes 则不受滑动影响。
• CADisplayLink 是与屏幕刷新率绑定的特殊定时器，同样依赖 RunLoop。若一次回调耗时超过刷新间隔，就会掉帧，产生卡顿。

3. UI 事件分发与响应链

主线程 RunLoop 是事件的中枢：

• 硬件触摸通过 mach port（Source1）唤醒 RunLoop，再由 UIKit 进行 hit‑testing 和响应链分发。
• 手势识别、setNeedsLayout 等 UI 更新都耦合在当前循环中被处理。
• performSelector:withObject:afterDelay: 及 performSelectorOnMainThread:... 内部正是通过向 RunLoop 注册 Timer 或 Source 实现的。若线程没有运行的 RunLoop，这些方法将不会执行。

4. 滑动性能优化（Mode 隔离）

利用 RunLoop 的 Mode 隔离特性，可将耗时任务推迟到空闲时执行，保障手势的优先级：

// 耗时任务仅在 DefaultMode 执行，TrackingMode 下不会抢占资源
[self performSelector:@selector(decodeImage:)
           withObject:image
           afterDelay:0
              inModes:@[NSDefaultRunLoopMode]];

图片解码、复杂文本排版、JSON 解析等重任务均可如此处理，大幅减少滑动时的掉帧。

5. 空闲时段任务调度

通过监听 kCFRunLoopBeforeWaiting（即将休眠）状态，在两次唤醒间隙插入低优先级任务（预渲染、缓存清理、日志上报）。既不阻塞主线程，又能保证任务最终被执行。AsyncDisplayKit 就利用该机制进行异步布局与渲染。

6. 卡顿监控与自动堆栈收集

向主线程 RunLoop 注册 CFRunLoopObserver，持续监控两个关键耗时区间：

• kCFRunLoopBeforeSources → kCFRunLoopBeforeWaiting（处理 Source0 等）
• kCFRunLoopAfterWaiting → kCFRunLoopBeforeTimers（处理 Timer、Source1、GCD 主队列 block）

任一区间耗时超过阈值（例如 50ms）即可判定为一次卡顿。此时抓取主线程调用栈并上报，即可精准定位问题代码。微信等大型 App 均部署了这一方案。

7. AutoreleasePool 生命周期管理

主线程 RunLoop 内部注册了两个 Observer：

• Entry 时创建 AutoreleasePool
• BeforeWaiting 时释放旧池并创建新池，Exit 时最终释放

所有在一次循环中由回调创建的对象都会被自动包裹在池中，开发者通常无需手动干预。

8. GCD 与 RunLoop 的协作

dispatch_async(dispatch_get_main_queue(), block) 提交的任务由 RunLoop 中的 GCD 专用 Source1 管理。RunLoop 在被唤醒后，会在处理完 Timer 和 Source0 之后执行这些 block。这解释了为何某些主队列任务会存在微小延迟。

9. NSStream 异步 I/O

NSInputStream / NSOutputStream 必须添加到指定 RunLoop 的 Mode 上，才能触发代理回调 stream:handleEvent:。否则流事件不会被传递，线程收不到数据。这是实现非阻塞 I/O 的基础。

10. 旧版 NSURLConnection 的调度

早年的 NSURLConnection 异步请求需要调度到 RunLoop 中：startInRunLoop:forMode:。虽然现已被 NSURLSession 取代，但理解这一点对维护遗留代码仍然有用。

11. 自定义事件源（CFRunLoopSource）线程通信

可创建 Source0 并手动标记信号、唤醒 RunLoop，实现任意线程间的事件传递。相比 GCD，它提供了更底层的控制，适用于某些高实时性跨线程通信场景（例如音视频处理）。

二、RunLoop 性能优化实战

1. 避免主线程阻塞

耗时任务（I/O、复杂计算、大量图片解码）绝不能放在主线程的一次 RunLoop 循环内，否则 UI 会被彻底冻住。必须移入后台线程，主线程只保留轻量级的视图配置。

2. 精细化 Mode 隔离

• 高优先级事件（Timer、网络回调、状态刷新）放入 NSRunLoopCommonModes，确保任何场景下都能触发。
• 可延迟重任务（预加载、格式转换）仅放入 NSDefaultRunLoopMode，滑动时自动挂起。
• 切勿将所有操作都塞进 CommonModes，否则滑动时大量无关任务争抢资源，反而掉帧。

3. 空闲任务分批执行

在 kCFRunLoopBeforeWaiting 回调中，或利用 performSelector:withObject:afterDelay:inModes: 分批执行低优任务。每批次耗时控制在 5~10ms 内，然后交还主线程，保证下一帧能及时渲染。适用于首屏外的预加载、数据库紧凑、缓存淘汰等。

4. 合并与降频定时器

• 减少 Timer 总数：合并多个周期相近的重复任务，由一个统一 Timer 管理。
• 非 UI 周期性工作优先使用 GCD 的 dispatch_source 或 dispatch_after，它们不依赖 RunLoop，管理开销更低。
• CADisplayLink 可设置 preferredFramesPerSecond 为 30，降低刷新率以节省 GPU/CPU。

5. 减少无效唤醒

每次唤醒 RunLoop 都伴随系统调用与上下文切换成本。

• 尽可能使用批量处理代替高频的逐一事件通知。
• 跨线程信号通知优先用 NSPort（Source1，内核管理效率高），而非频繁手动 CFRunLoopSourceSignal + CFRunLoopWakeUp（Source0 的唤醒开销更大）。

6. 正确选择事件源类型

• Source1（Port 源）：基于 mach port，由内核自动唤醒 RunLoop，适用于系统级或跨进程/跨线程的底层通信。
• Source0：需手动标记信号并显式唤醒，适用于自定义业务事件。不要裸用，建议封装成高层 API（如 CFMessagePort）或直接改用 GCD，以降低出错概率。

7. 线程生命周期管理

• RunLoop 与线程严格一一对应，退出前必须显式停止（CFRunLoopStop）并移除所有输入源，否则线程永远不会释放。
• 保活线程内部务必使用 @autoreleasepool 包裹循环体，否则局部对象会因自动释放池长期不刷新而堆积。
• 避免在 RunLoop Observer 回调内阻塞 RunLoop 或形成循环引用，导致无法正常退出。

8. 卡顿监控闭环

将卡顿监控集成至开发/线上环境，实时抓取超时堆栈并聚合分析。对高频卡顿路径做专项重构或移入后台线程，形成“监控 → 分析 → 优化”的流程闭环。

三、常见误区与注意事项

• 子线程默认没有开启 RunLoop，必须显式获取或创建。
• 模态对话框（runModalSession 等）会递归进入新的 RunLoop，可能导致原有 Timer 和 Source 被忽略，需要特别留意。
• CFRunLoopStop 只能停止当前一次 RunLoop 的执行。如果线程再次调用 CFRunLoopRun()，RunLoop 会重新启动。因此要彻底退出线程，必须同时移除所有输入源。
• 保活线程如果不休眠（如无限循环），AutoreleasePool 无法自动刷新，极易造成内存峰值过高。

结语

RunLoop 看似只负责“转圈”，实则是 iOS 事件调度、性能优化、线程管理的命脉。掌握好 Mode 隔离、空闲任务调度和卡顿监控这三板斧，就能在响应速度、资源占用与稳定性之间找到最佳平衡点。希望本文能为你的面试、架构设计和日常开发提供一份扎实的参考。