何为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() 这个地方。