7-8.【OC】【RunLoop】CFRunLoopMode / NSRunLoopMode 的 Mode 切换是如何影响事件调度的？

RunLoop 的 Mode 切换本质上是一场事件源的“物理隔离” 。它通过在运行时动态切换数据集合，强制让线程只关注当前模式下的任务。

我们可以从底层数据结构和调度逻辑两个维度来剖析这一过程：

1. 底层数据结构：多集合并存

在 CFRunLoop.c 的源码中，一个 CFRunLoop 结构体并不直接包含事件源，而是包含一个名为 _modes 的集合（Set）。

Mode 的独立性：每个 CFRunLoopMode 内部都维护着自己独立的 _sources0、_sources1、_timers 和 _observers。
切换的本质：所谓的“Mode 切换”，就是 RunLoop 在执行 do-while 循环的下一次迭代前，将一个名为 _currentMode 的指针从 Mode A 指向 Mode B。

Mode 的切换并不是平滑过渡的，而是伴随着循环的重新启动。

以 UITableView 滑动为例：

Default 状态：主线程 RunLoop 在 kCFRunLoopDefaultMode 中循环。
触发触摸：系统内核通过 Mach Port 发送 Source1 消息。
模式切换：
- RunLoop 收到切换请求。
- 通知 Observer：即将退出当前 Mode (kCFRunLoopExit)。
- 切换指针：_currentMode 变为 UITrackingRunLoopMode。
- 通知 Observer：即将进入新 Mode (kCFRunLoopEntry)。
重新迭代：RunLoop 重新开始执行循环逻辑，但此时它只去查 UITrackingRunLoopMode 下的任务列表。

这种机制导致了以下三种典型的调度行为：

如果一个任务（如 NSURLConnection 的回调或 NSTimer）注册在 Default Mode，而当前处于 Tracking Mode，那么：

由于 CommonModes 实际上是一个标签（Item 标记），当你把一个 Timer 加入 Common 时：

由于 UITrackingRunLoopMode 下的任务通常很少（只负责处理触摸和简单的 UI 刷新），Mode 切换有效地清空了那些杂乱的后台 Source0 任务，使得主线程能以接近 100% 的精力处理每秒 60/120 帧的渲染。

CADisplayLink 是一个特殊的 Timer，它与屏幕刷新率同步。

意外行为：如果你直接把它加到 Default Mode，滑动列表时动画会立刻卡死（停止）。
调度真相：此时 GPU 仍在刷新，但因为 RunLoop 切换到了 Tracking Mode，它不再调用 CADisplayLink 的回调方法，导致下一帧的动画数据无法提交。