何为RunLoop
RunLoop就是一直运行的循环。程序的持续运行和即时反应依赖于RunLoop。我们知道，一个线程一次只能执行一个任务，执行完后线程就会退出，而RunLoop就是一个机制使我们的线程能够随时处理事件而不退出。其实它实现逻辑很简单，就是在内部开启一个死循环。
1
2
3
4
5
| -(void)loop{
do{
bool isRunning = SomeToDo();
}while(isRunning);
}
|
这种模型有个术语叫作Event Loop，实现这种模型的关键在于：
1、 如何管理事件；
2、 如何让线程在没有消息处理的时候休眠，在有事件响应的时候及时被唤醒；
RunLoop是一个对象
RunLoop管理着需要处理的事件和消息，并提供一个入口函数来执行上面Event Loop的逻辑。线程执行这个函数后就会处于“接受消息->等待->处理”的循环中,直到循环结束，函数返回。
Cocoa 中的 RunLoop
苹果为我们提供这样的两个对象：NSRunLoop 和 CFRunLoopRef 来实现RunLoop。
NSRunLoop是基于CFRunLoopRef封装的，提供面向对象API，但是它不是线程安全的。
CFRunLoopRef是CoreFoundation框架内的，它提供纯C的API，而且它是线程安全的。此外它是开源的。
我们这篇博客讲解也是主要基于CFRunLoopRef。
RunLoop与线程
pthread_t和NSThread都可以用于创建新线程，他们都是基于底层的mach thread封装的。且pthread_t与NSThread是一一对应的。CFRunLoop是基于pthread来管理的。
苹果不允许直接创建RunLoop，它提供两个自动获取函数：CFRunLoopGetMain()和CFRunLoopGetCurrent()。实现逻辑如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| // 全局的Dictionary，key 是 pthread_t， value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
// 访问 loopsDic 时的锁
static CFSpinLock_t loopsLock;
// 获取一个 pthread 对应的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {
OSSpinLockLock(&loopsLock);
if (!loopsDic) {
// 第一次进入时，初始化全局Dic，并先为主线程创建一个 RunLoop。
loopsDic = CFDictionaryCreateMutable();
CFRunLoopRef mainLoop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
}
// 直接从 Dictionary 里获取。
CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));
if (!loop) {
// 取不到时，创建一个
loop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic, thread, loop);
// 注册一个回调，当线程销毁时，顺便也销毁其对应的 RunLoop。
_CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
return loop;
}
CFRunLoopRef CFRunLoopGetMain() {
return _CFRunLoopGet(pthread_main_thread_np());
}
CFRunLoopRef CFRunLoopGetCurrent() {
return _CFRunLoopGet(pthread_self());
}
|
由上面的代码，可看出，线程与RunLoop是一一对应，而且他们以键值对的关系保存在一个全局的字典里面。线程刚创建时是没有RunLoop，如果你不主动获取，那它一直都不会有。RunLoop的创建发生在第一次获取时，RunLoop的销毁发生在线程结束时。
RunLoop对外提供的API
CoreFoundation的RunLoop提供以下5个类：
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRUNLoopObserverRef
他们的关系如下图：
一个RunLoop包含若干个Mode，每个Mode又包含若干个Source/Timer/Observer。每次调用RunLoop的主函数，只能指定其中一个Mode，这个Mode被称为Current Mode。如果要切换Mode，只能退出Loop，再重新指定一个Mode进入，这样做是为了分隔不同组的Source/Timer/Observer，让其互不影响。
CFRunLoopSourceRef
是事件产生的地方，它有两个版本：Source0 和 Source 1。
Source0 只包含一个回调（函数指针），它并不能主动触发事件，使用时，你需要先调用CFRunLoopSourceSignal(source)，将这个source标记为待处理，然后手动调用CFRunLoopWakeUp(source)来唤醒RunLoop，让其处理这个事件。
Source1 包含一个mach_port和一个回调，被用于通过内核和其他线程相互发送消息。这种Source能主动唤醒RunLoop线程。
CFRunLoopTimerRef
是基于时间的触发器，它与NSTimer是toll-free-bridged的，可以混用。它包含一个时间长度和一个回调。当其加入RunLoop时，RunLoop会注册对应的时间点，当时间点到时，RunLoop会被唤醒去执行那个回调。
CFRunLoopObserverRef
是观察者，每个Observer包含一个回调，当RunLoop的状态发生变化时，观察者能通过回调接收到这个变化。以下是观察者观察的时间点：
1
2
3
4
5
6
7
8
| typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 即将进入Loop
kCFRunLoopBeforeTimers = (1UL << 1), // 即将处理 Timer
kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6), // 刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7), // 即将退出Loop
};
|
上面的 Source/Timer/Observer 被统称为 mode item，一个 item 可以被同时加入多个 mode。但一个 item 被重复加入同一个 mode 时是不会有效果的。如果一个 mode 中一个 item 都没有，则 RunLoop 会直接退出，不进入循环。
CFRunLoopMode
有了以上的基础，来谈Mode比较容易理解。
我们看下CFRunLoop和CFRunLoopMode的结构：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| struct __CFRunLoopMode {
CFStringRef _name; // Mode Name, 例如 @"kCFRunLoopDefaultMode"
CFMutableSetRef _sources0; // Set
CFMutableSetRef _sources1; // Set
CFMutableArrayRef _observers; // Array
CFMutableArrayRef _timers; // Array
...
};
struct __CFRunLoop {
CFMutableSetRef _commonModes; // Set
CFMutableSetRef _commonModeItems; // Set<Source/Observer/Timer>
CFRunLoopModeRef _currentMode; // Current Runloop Mode
CFMutableSetRef _modes; // Set
...
};
|
这里解释下commonModes和comminModeItems：
一个Mode可以将自己标识为Common属性（通过将其ModeName添加到RunLoop的commonModes中）。每当RunLoop的内容发生变化时，RunLoop都会自动将commonModeItems里的Source/Observer/Timer同步到具有“Common”标识的所有Mode里。
举例说明下：主线程的RunLoop里有两个预设的Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。这两个Mode都已经被标志为“Common”属性。DefaultMode是App平时所处的状态，TrackingRunLoopMode是追踪ScrollView滑动时的状态。当你创建一个Timer并添加到DefaultMode时，Timer会得到重复回调，但当你滑动scrollView时，RunLoop会将Mode切换为TrackingRunLoopMode来保证滑动顺畅，这时Timer会停止回调。
如果你想Timer在滑动的时候也有回调的话，有两种做法：
一：将这个Timer分别加入这两个Mode；
二：这个做法用得比较多，就是将Timer加入到顶层的RunLoop的“commonModeItems”中。“commonModeItems”被RunLoop自动更新到所有具有“Common”属性的Mode里去。
我们只能通过 mode name 来操作内部的 mode，当你传入一个新的 mode name 但 RunLoop 内部没有对应 mode 时，RunLoop会自动帮你创建对应的 CFRunLoopModeRef。对于一个 RunLoop 来说，其内部的 mode 只能增加不能删除。
苹果公开提供Mode有两个：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode，我们可以通过这两个Mode Name来操作相应的Mode。
同时苹果还提供了一个操作Common标记的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，我们可以用这个字符串来操作Common Items 或标志一个Mode为“Common”。
RunLoop的内部逻辑
RunLoop内部实现逻辑大致如下图：
代码实现逻辑如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
| /// 用DefaultMode启动
void CFRunLoopRun(void) {
CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}
/// 用指定的Mode启动，允许设置RunLoop超时时间
int CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean stopAfterHandle) {
return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}
/// RunLoop的实现
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
/// 首先根据modeName找到对应mode
CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
/// 如果mode里没有source/timer/observer, 直接返回。
if (__CFRunLoopModeIsEmpty(currentMode)) return;
/// 1. 通知 Observers: RunLoop 即将进入 loop。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);
/// 内部函数，进入loop
__CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {
Boolean sourceHandledThisLoop = NO;
int retVal = 0;
do {
/// 2. 通知 Observers: RunLoop 即将触发 Timer 回调。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: RunLoop 即将触发 Source0 (非port) 回调。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
/// 执行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 4. RunLoop 触发 Source0 (非port) 回调。
sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
/// 执行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 5. 如果有 Source1 (基于port) 处于 ready 状态，直接处理这个 Source1 然后跳转去处理消息。
if (__Source0DidDispatchPortLastTime) {
Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
if (hasMsg) goto handle_msg;
}
/// 通知 Observers: RunLoop 的线程即将进入休眠(sleep)。
if (!sourceHandledThisLoop) {
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
}
/// 7. 调用 mach_msg 等待接受 mach_port 的消息。线程将进入休眠, 直到被下面某一个事件唤醒。
/// • 一个基于 port 的Source 的事件。
/// • 一个 Timer 到时间了
/// • RunLoop 自身的超时时间到了
/// • 被其他什么调用者手动唤醒
__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort) {
mach_msg(msg, MACH_RCV_MSG, port); // thread wait for receive msg
}
/// 8. 通知 Observers: RunLoop 的线程刚刚被唤醒了。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);
/// 收到消息，处理消息。
handle_msg:
/// 9.1 如果一个 Timer 到时间了，触发这个Timer的回调。
if (msg_is_timer) {
__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
}
/// 9.2 如果有dispatch到main_queue的block，执行block。
else if (msg_is_dispatch) {
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
}
/// 9.3 如果一个 Source1 (基于port) 发出事件了，处理这个事件
else {
CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
if (sourceHandledThisLoop) {
mach_msg(reply, MACH_SEND_MSG, reply);
}
}
/// 执行加入到Loop的block
__CFRunLoopDoBlocks(runloop, currentMode);
if (sourceHandledThisLoop && stopAfterHandle) {
/// 进入loop时参数说处理完事件就返回。
retVal = kCFRunLoopRunHandledSource;
} else if (timeout) {
/// 超出传入参数标记的超时时间了
retVal = kCFRunLoopRunTimedOut;
} else if (__CFRunLoopIsStopped(runloop)) {
/// 被外部调用者强制停止了
retVal = kCFRunLoopRunStopped;
} else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
/// source/timer/observer一个都没有了
retVal = kCFRunLoopRunFinished;
}
/// 如果没超时，mode里没空，loop也没被停止，那继续loop。
} while (retVal == 0);
}
/// 10. 通知 Observers: RunLoop 即将退出。
__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}
|
实际上RunLoop内部就是一个do-while循环，当你调用CFRunLoopRun（）时，线程就会一直停留在这个循环里，处于接受消息->等待->处理的循环中，直到超时或者手动停止，函数返回。
RunLoop底层实现
RunLoop的核心是基于mach port，在RunLoop进入休眠时，它调用mach_msg()等待mach port传消息过来，如果没有消息过来，内核会将线程置于等待状态。为了更好的了解mach port，我们先了解OSX/iOS的系统架构。
苹果官方将整个系统大致划分为上述4个层次：
应用层：包括用户能接触到的图形应用，例如 Spotlight、Aqua、SpringBoard 等。
应用框架层：即开发人员接触到的 Cocoa 等框架。
核心框架层：包括各种核心框架、OpenGL 等内容。
Darwin： 即操作系统的核心，包括系统内核、驱动、Shell 等内容，这一层是开源的，其所有源码都可以在 opensource.apple.com 里找到。
我们再深入看下Darwin：
其中，在硬件层上面由三部分组成：Mach、BSD、IOKit（还包括一些没标注的内容），共同组成XNU内核。
XNU内核的内环被称为Mach，它作为一个微内核，仅提供诸如处理器调度、IPC（进程间通信）等非常少量的基础服务。
BSD层可以看作围绕Mach层的一个外环，其提供了诸如进程管理、文件系统和网络等功能。
IOKit层为设备驱动提供一个面向对象的框架（C++）。
Mach 本身提供的 API 非常有限，而且苹果也不鼓励使用 Mach 的 API，但是这些API非常基础，如果没有这些API的话，其他任何工作都无法实施。在 Mach 中，所有的东西都是通过自己的对象实现的，进程、线程和虚拟内存都被称为"对象"。和其他架构不同， Mach 的对象间不能直接调用，只能通过消息传递的方式实现对象间的通信。"消息"是 Mach 中最基础的概念，消息在两个端口 (port) 之间传递，这就是 Mach 的 IPC (进程间通信) 的核心。
Mach 的消息定义是在 <mach/message.h> 头文件的，很简单：
1
2
3
4
5
6
7
8
9
10
11
12
13
| typedef struct {
mach_msg_header_t header;
mach_msg_body_t body;
} mach_msg_base_t;
typedef struct {
mach_msg_bits_t msgh_bits;
mach_msg_size_t msgh_size;
mach_port_t msgh_remote_port;
mach_port_t msgh_local_port;
mach_port_name_t msgh_voucher_port;
mach_msg_id_t msgh_id;
} mach_msg_header_t;
|
一条Mach消息实际上就是一个二进制数据包（BLOB），其头部定义了当前端口local_port和目标端口remote_port。
1
2
3
4
5
6
7
8
| mach_msg_return_t mach_msg(
mach_msg_header_t *msg,
mach_msg_option_t option,
mach_msg_size_t send_size,
mach_msg_size_t rcv_size,
mach_port_name_t rcv_name,
mach_msg_timeout_t timeout,
mach_port_name_t notify);
|
发送消息和接收消息是通过同个API进行的，其option标记了消息传递的方向。
为了实现消息的发送和接收，mach_msg()实际上是调用了一个Mach陷阱，即mach_msg_trap()，陷阱这个概念在Mach中等同于系统调用，当你在用户态调用mach_msg_trap()时会触发陷阱机制，切换到内核态，内核态中的内核实现的mach_msg()会完成实际的工作。例如你在在模拟器里跑起一个 iOS 的 App，然后在 App 静止时点击暂停，你会看到主线程调用栈是停留在 mach_msg_trap() 这个地方。