iOS 底层深度解析:RunLoop 凭什么成为 App 的“心脏起搏器”?

很多 iOS 开发者写了几年代码，对 RunLoop 的印象可能还停留在：

“就是那个让程序不死的死循环。”

“滑动的时候 NSTimer 会停，加个 CommonModes 就好了。”

但这些理解太浅了。为什么 RunLoop 能让线程休眠却不占 CPU？它是如何优雅地处理触摸、网络、定时器的？为什么 AutoreleasePool 的释放时机和 RunLoop 有关？

今天，我们就把 RunLoop 从黑盒拆成白盒。

我们学编程的第一个 C 程序：

#include<stdio.h>intmain(){    printf("Hello, World!\n");    return 0; // 程序执行完毕，退出}

这段代码执行完 printf后，进程就结束了。这是典型的 “执行-退出” 模型。

但 iOS App 不一样。你点击 App 图标后，它不会自己退出，而是一直待在那里，等你触摸、滑动、输入。这是一个 “事件驱动” 模型。

打开任何一个 iOS 项目的 main.m 文件，你会看到：

int main(int argc, char * argv[]) {    @autoreleasepool {        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));    }}

      UIApplicationMain 函数做了三件核心事情：

1. 创建 UIApplication单例。

2. 创建 AppDelegate实例并赋值给 UIApplication。

3. 开启主线程的 RunLoop。

这个函数一旦调用，就永远不会返回（除非 App 被系统杀死）。它内部启动了一个 RunLoop，让主线程进入“等待-处理-休眠”的无限循环中。

我们做个实验：在子线程执行一个任务，任务结束后线程就销毁了。

let thread = Thread {    print("子线程开始执行任务")    // 任务执行完毕    print("子线程任务结束")}thread.start()

输出：

子线程开始执行任务 子线程任务结束

线程完成任务后自动退出。如果我们想让这个线程一直活着，随时接收任务呢？

let thread = Thread {    print("子线程启动")    // 开启 RunLoop，让线程永远不退出    RunLoop.current.add(Port(), forMode: .default)    RunLoop.current.run()    print("这行代码永远不会执行")}thread.start()

这时候线程就不会退出了，它会一直等待消息。这就是 RunLoop 最核心的能力：线程保活。

RunLoop 并不是一个简单的 while 循环，它是一个由五个核心组件构成的精密系统。

// 获取当前线程的 RunLoop 的内部实现（简化版）CFRunLoopRef CFRunLoopGetCurrent(void) {    // 从线程局部存储（TLS）中获取 RunLoop 对象    CFRunLoopRef loop = (CFRunLoopRef)pthread_getspecific(__CFRunLoopKey);    if (!loop) {        // 如果不存在，则创建一个新的        loop = _CFRunLoopCreate();        pthread_setspecific(__CFRunLoopKey, loop);    }    return loop;}

RunLoop 在任一时刻只能运行在一个 Mode 下，切换 Mode 必须退出当前循环。

struct __CFRunLoopMode {    CFRuntimeBase _base;    pthread_mutex_t _lock;    CFStringRef _name;                      // Mode 名称    Boolean _stopped;    CFMutableSetRef _sources0;              // Source0 集合    CFMutableSetRef _sources1;              // Source1 集合    CFMutableArrayRef _observers;           // Observer 数组    CFMutableArrayRef _timers;              // Timer 数组    // ...};

苹果预定义了五种 Mode，但公开给我们用的主要是这几种：

源码实现：

void CFRunLoopAddCommonMode(CFRunLoopRef rl, CFStringRef modeName) {    // 将 modeName 添加到 _commonModes 集合中    CFSetAddValue(rl->_commonModes, modeName);    // 将该 Mode 下的所有 Item 同步到 _commonModeItems 中}

Source 是 RunLoop 的数据输入源，分为两类：

Source1 是 RunLoop 能够休眠并被唤醒的关键，因为它依赖 Mach Port与内核通信。

RunLoop 休眠时并不是调用 sleep()，而是调用 mach_msg()系统调用。

// CFRunLoopRun 的核心代码（简化）static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, ...) {    do {        // 1. 通知 Observer：即将处理 Timer/Source        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);        // 2. 处理 Blocks        __CFRunLoopDoBlocks(rl, rlm);        // 3. 处理 Source0        if (__CFRunLoopDoSources0(rl, rlm)) {            __CFRunLoopDoBlocks(rl, rlm);        }        // 4. 如果有 Source1 待处理，跳转到处理步骤        if (__CFRunLoopServiceMachPort(dispatchPort, &msg, ...)) {            goto handle_msg;        }        // 5. 通知 Observer：即将休眠        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);        // 6. 🔥 核心：调用 mach_msg 等待内核消息，线程在此休眠        //    当没有消息时，线程被挂起，CPU 占用为 0        __CFRunLoopServiceMachPort(waitSet, &msg, ...);        // 7. 被唤醒后，通知 Observer：结束休眠        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopAfterWaiting);    handle_msg:        // 8. 处理唤醒事件        if (msg是Timer) {            __CFRunLoopDoTimers(rl, rlm);        } else if (msg是GCD) {            __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__();        } else if (msg是Source1) {            __CFRunLoopDoSource1(rl, rlm, source);        }        // 9. 处理 Blocks        __CFRunLoopDoBlocks(rl, rlm);        // 10. 判断是否继续循环    } while (结果不为0 && 未停止);}

mach_msg() 是一个系统调用，它会让当前线程从用户态切换到内核态。内核会检查 Mach Port 的消息队列：

• 如果有消息：立即返回，线程继续执行。

• 如果没有消息：将线程挂起，CPU 时间片分配给其他线程，当前线程几乎不耗电。

这就是 RunLoop 能做到“有活干，没活睡”的底层原理。

NSTimer其实就是 CFRunLoopTimerRef的上层封装。当我们创建一个 Timer 并添加到 RunLoop 时：

let timer = Timer(timeInterval: 1.0, repeats: true) { _ in    print("Timer fired")}RunLoop.current.add(timer, forMode: .default)

RunLoop 内部会计算所有 Timer 的下一次触发时间，然后在调用 mach_msg() 时，设置一个超时时间（timeout）。这个超时时间等于距离最近一个 Timer 触发的时间间隔。

// 计算休眠时长CFTimeInterval sleepInterval = __CFRunLoopGetNextTimerFireDate(rl, rlm);// 调用 mach_msg，最多等待 sleepInterval 秒__CFRunLoopServiceMachPort(waitSet, &msg, sleepInterval, ...);

这样，即使没有任何 Source1 事件，RunLoop 也会在 Timer 触发时被内核准时唤醒。

Observer 可以监听 RunLoop 的七个状态变化：

结合上面的源码分析，我们可以画出 RunLoop 一次完整循环的详细流程：

AFNetworking2.x版本曾使用 RunLoop 实现常驻线程，用于后台网络回调处理。

class PermanentThread: NSObject {    private var thread: Thread?    private var runLoop: RunLoop?    override init() {        super.init()        thread = Thread(block: { [weak self] in            // 必须添加一个 Source/Timer/Observer，否则 RunLoop 会立即退出            self?.runLoop = RunLoop.current            self?.runLoop?.add(Port(), forMode: .default)            // 开启 RunLoop            while !Thread.current.isCancelled {                self?.runLoop?.run(mode: .default, before: Date.distantFuture)            }            print("线程退出")        })        thread?.start()    }    func executeTask(_ task: @escaping () -> Void) {        guard let runLoop = runLoop else { return }        DispatchQueue.main.async {            // 将任务提交到常驻线程执行            CFRunLoopPerformBlock(runLoop.getCFRunLoop(), .default, task)            CFRunLoopWakeUp(runLoop.getCFRunLoop())        }    }    func stop() {        thread?.cancel()        CFRunLoopStop(runLoop?.getCFRunLoop())    }}// 使用示例let permanentThread = PermanentThread()permanentThread.executeTask {    print("在常驻线程中执行耗时任务")    // 这里的代码在子线程执行}

注意：在现代 iOS 开发中，GCD 已经能很好地管理线程生命周期，除非有特殊需求（如需要精确控制线程生命周期、处理特定端口的回调），否则不建议手动保活线程。

performSelector:withObject:afterDelay:的本质是创建一个 Timer 并添加到当前线程的 RunLoop。

// 延迟 2 秒执行perform(#selector(delayedMethod), with: nil, afterDelay: 2.0)// 取消延迟执行NSObject.cancelPreviousPerformRequests(withTarget: self, selector: #selector(delayedMethod), object: nil)

陷阱：如果当前线程没有开启RunLoop，afterDelay系列方法是无效的。

DispatchQueue.global().async {    // 子线程默认没有 RunLoop    self.perform(#selector(self.method), with: nil, afterDelay: 1.0)    // 这个方法永远不会被调用！    // 如果要生效，需要手动开启 RunLoop    RunLoop.current.run()}

在 UITableView 滑动时，不加载图片，等滑动停止后再加载，可以显著提升滑动流畅度。

// 利用 RunLoop 的 Mode 特性func scrollViewDidScroll(_ scrollView: UIScrollView) {    // 滑动时不加载图片}func scrollViewDidEndDragging(_ scrollView: UIScrollView, willDecelerate decelerate: Bool) {    if !decelerate {        // 滑动停止，开始加载可见区域的图片        loadImagesForVisibleCells()    }}func scrollViewDidEndDecelerating(_ scrollView: UIScrollView) {    // 减速停止，开始加载可见区域的图片    loadImagesForVisibleCells()}func loadImagesForVisibleCells() {    // 获取可见 cell，加载图片}

更优雅的实现：利用CFRunLoopPerfo-rmBlock 在 RunLoop 空闲时执行任务。

// 在 RunLoop 即将休眠前执行低优先级任务CFRunLoopPerformBlock(CFRunLoopGetMain(), .default) {    // 加载图片、预计算高度等耗时但不紧急的任务    self.loadImagesForVisibleCells()}

苹果在主线程 RunLoop 中注册了两个 Observer，用于管理自动释放池：

1. Entry Observer（优先级最高）：在 RunLoop 进入时创建 AutoreleasePool。

2. BeforeWaiting Observer（优先级最低）：在 RunLoop 休眠前销毁旧的 AutoreleasePool，并创建一个新的。

// 简化代码演示void setupAutoreleasePoolForRunLoop() {    CFRunLoopObserverRef entryObserver = CFRunLoopObserverCreate(..., kCFRunLoopEntry, ...);    CFRunLoopAddObserver(runloop, entryObserver, kCFRunLoopCommonModes);    CFRunLoopObserverRef beforeWaitingObserver = CFRunLoopObserverCreate(..., kCFRunLoopBeforeWaiting, ...);    CFRunLoopAddObserver(runloop, beforeWaitingObserver, kCFRunLoopCommonModes);}

因此，Autorelease 对象的释放时机是

 RunLoop 即将休眠时。这也是为什么我们在 viewDidLoad 中创建的大量临时对象，不会立即释放，而是等到本次 RunLoop 循环结束。

在 Xcode 断点中，使用 lldb 命令查看 RunLoop 状态：

# 打印主线程 RunLoop(lldb) po [NSRunLoop mainRunLoop]# 打印当前 RunLoop 的 Mode(lldb) po [[NSRunLoop currentRunLoop] currentMode]# 查看 RunLoop 中的所有 Timer(lldb) po [[NSRunLoop currentRunLoop] timers]# 查看 RunLoop 中的所有 Source(lldb) po [[NSRunLoop currentRunLoop] sources]

输出示例：

<CFRunLoop 0x6000001f0300 [0x10a8c7c50]> {    current mode = kCFRunLoopDefaultMode,    common modes = {        UITrackingRunLoopMode,        kCFRunLoopDefaultMode    },    common mode items = {        Source0 { ... },        Source1 { ... },        Timer { ... },        Observer { ... }    },    modes = {        UITrackingRunLoopMode { ... },        GSEventReceiveRunLoopMode { ... },        kCFRunLoopDefaultMode { ... },        UIInitializationRunLoopMode { ... }    }}

我们可以写一个调试工具，实时在控制台输出 RunLoop 状态变化：

class RunLoopDebugger {    static func start() {        let observer = CFRunLoopObserverCreateWithHandler(            kCFAllocatorDefault,            CFRunLoopActivity.allActivities.rawValue,            true,            0        ) { observer, activity in            let mode = RunLoop.current.currentMode?.rawValue ?? "nil"            var activityName = ""            switch activity {            case .entry: activityName = "Entry"            case .beforeTimers: activityName = "BeforeTimers"            case .beforeSources: activityName = "BeforeSources"            case .beforeWaiting: activityName = "BeforeWaiting"            case .afterWaiting: activityName = "AfterWaiting"            case .exit: activityName = "Exit"            default: activityName = "Unknown"            }            print("🔵 [RunLoop] 状态: \(activityName), Mode: \(mode)")        }        CFRunLoopAddObserver(CFRunLoopGetMain(), observer, .commonModes)    }}// 在 AppDelegate 中调用RunLoopDebugger.start()

运行 App 后，控制台会实时输出类似信息：

🔵 [RunLoop] 状态: Entry, Mode: UIInitializationRunLoopMode🔵 [RunLoop] 状态: BeforeTimers, Mode: kCFRunLoopDefaultMode🔵 [RunLoop] 状态: BeforeSources, Mode: kCFRunLoopDefaultMode🔵 [RunLoop] 状态: BeforeWaiting, Mode: kCFRunLoopDefaultMode😴 即将休眠...⏰ 被唤醒，原因：触摸事件🔵 [RunLoop] 状态: AfterWaiting, Mode: kCFRunLoopDefaultMode🔵 [RunLoop] 状态: BeforeTimers, Mode: UITrackingRunLoopMode...

使用Xcode Instruments的Time Profiler 工具，可以清晰地看到主线程 RunLoop 在不同状态下的耗时分布。在分析性能问题时，关注 CFRunLoopRun相关的调用栈，能快速定位卡顿原因。

A

A

A

A

A

总结与进阶建议