在 iOS 中，RunLoop 的核心作用就是监听、接收并处理各类事件，它是线程的「事件循环管理器」：没有事件时线程休眠（节省 CPU），有事件时立即唤醒处理。
苹果官方定义 RunLoop 监听 5 大类核心事件 ，这也是开发中最常接触的事件类型，我结合实际开发场景给你讲清楚：
iOS RunLoop 监听的 5 类核心事件
-
Source0 事件（用户交互核心事件）
最常用、最贴近业务的事件，由用户手动触发，无系统内核直接唤醒，需要手动标记为待处理。
典型场景UI 点击：UIButton 点击、UIControl 事件
手势：UITapGestureRecognizer 等所有手势
触摸事件：touchesBegan/Moved/Ended
自定义业务事件
特点
纯用户层事件，是我们日常开发中接触最多的事件类型。
2. Source1 事件（系统内核底层事件）
系统内核触发的底层事件，基于 Mach 端口（iOS 内核通信机制），内核会自动唤醒 RunLoop。
典型场景
系统底层硬件事件（屏幕触摸的底层捕获）
进程间通信（IPC）
网络请求的底层接收
系统内核通知
关键关联
我们的屏幕点击，第一步是 Source1 捕获，然后转发成 Source0 交给业务层处理（这是触摸事件的底层流程）。
3. Timer 事件（定时事件）
基于时间触发的事件，NSTimer / CADisplayLink 的底层就是 RunLoop Timer 事件。
典型场景
倒计时、定时轮询
列表自动滚动、动画刷新
延迟执行任务
注意
RunLoop 繁忙时，Timer 会延迟触发，无法做到绝对精准定时。
4. Observer 事件（RunLoop 状态监听事件）
不处理业务，只监听 RunLoop 自身生命周期的事件，属于「监控型事件」。
RunLoop 有 6 种状态，Observer 可以监听所有状态：
即将进入 RunLoop
即将处理 Timer 事件
即将处理 Source 事件
即将休眠（核心状态）
即将被唤醒
即将退出 RunLoop
典型场景
卡顿监控、性能检测
系统自动释放池（AutoreleasePool）：系统自带 Observer 管理创建和销毁
RunLoop 生命周期监听
- Block 事件（异步提交的任务）
手动提交到 RunLoop 执行的 Block 任务，是轻量级的事件处理方式。
典型场景
CFRunLoopPerformBlock 提交任务
performSelector:onThread: 跨线程执行
主线程刷新 UI 的异步任务
RunLoop 事件处理优先级（固定顺序）
RunLoop 每次循环，会按固定顺序处理事件：
先通知 Observer：「要开始处理事件了」
处理 Source0 事件
处理 Timer 事件
处理 Source1 事件
处理 Block 事件
所有事件处理完毕 → RunLoop 休眠，等待下一个事件唤醒
核心总结
Source0：用户交互（点击、手势）→ 业务层核心
Source1：系统内核（触摸底层、网络）→ 底层驱动
Timer：定时任务 → 倒计时、动画
Observer：监听 RunLoop 状态 → 卡顿监控、自动释放池
Block：异步提交任务 → 轻量级线程任务
总结
RunLoop 只处理以上 5 类事件，覆盖了 iOS 所有线程任务、UI 交互、系统通信；
主线程 RunLoop 默认启动，子线程需要手动启动；
无事件时休眠，有事件立即唤醒，是 iOS 流畅运行的核心机制。