深入理解RunLoop
原文地址：http://blog.ibireme.com/2015/05/18/runloop/
RunLoop 是 iOS 和 OSX 開發中非常基礎的一個概念，這篇文章將從 CFRunLoop 的源碼入手，介紹 RunLoop 的概念以及底層實現原理。之後會介紹一下在 iOS 中，蘋果是如何利用 RunLoop 實現自動釋放池、延遲迴調、觸摸事件、屏幕刷新等功能的。
Index
RunLoop 的概念
RunLoop 與線程的關係
RunLoop 對外的接口
RunLoop 的 Mode
RunLoop 的內部邏輯
RunLoop 的底層實現
蘋果用 RunLoop 實現的功能
AutoreleasePool
事件響應
手勢識別
界面更新
定時器
PerformSelecter
關於GCD
關於網絡請求
RunLoop 的實際應用舉例
AFNetworking
AsyncDisplayKit
RunLoop 的概念
一般來講，一個線程一次只能執行一個任務，執行完成後線程就會退出。如果我們需要一個機制，讓線程能隨時處理事件但並不退出，通常的代碼邏輯是這樣的：
|
|
functionloop(){
initialize();
do{
varmessage
=get_next_message();
process_message(message);
}while
(message!=
quit);
}
|
這種模型通常被稱作
Event Loop。 Event Loop 在很多系統和框架裏都有實現，比如 Node.js 的事件處理，比如 Windows 程序的消息循環，再比如 OSX/iOS 裏的 RunLoop。實現這種模型的關鍵點在於：如何管理事件/消息，如何讓線程在沒有處理消息時休眠以避免資源佔用、在有消息到來時立刻被喚醒。
所以，RunLoop 實際上就是一個對象，這個對象管理了其需要處理的事件和消息，並提供了一個入口函數來執行上面 Event Loop 的邏輯。線程執行了這個函數後，就會一直處於這個函數內部 "接受消息->等待->處理" 的循環中，直到這個循環結束（比如傳入 quit 的消息），函數返回。
OSX/iOS 系統中，提供了兩個這樣的對象：NSRunLoop 和 CFRunLoopRef。
CFRunLoopRef 是在 CoreFoundation 框架內的，它提供了純 C 函數的 API，所有這些 API 都是線程安全的。
NSRunLoop 是基於 CFRunLoopRef 的封裝，提供了面向對象的 API，但是這些 API 不是線程安全的。
CFRunLoopRef 的代碼是開源的，你可以在這裏http://opensource.apple.com/tarballs/CF/
下載到整個 CoreFoundation 的源碼來查看。
(Update: Swift 開源後，蘋果又維護了一個跨平臺的 CoreFoundation 版本：https://github.com/apple/swift-corelibs-foundation/，這個版本的源碼可能和現有 iOS 系統中的實現略不一樣，但更容易編譯，而且已經適配了 Linux/Windows。)
RunLoop 與線程的關係
首先，iOS 開發中能遇到兩個線程對象: pthread_t 和 NSThread。過去蘋果有份文檔標明瞭 NSThread 只是 pthread_t 的封裝，但那份文檔已經失效了，現在它們也有可能都是直接包裝自最底層的
mach thread。蘋果並沒有提供這兩個對象相互轉換的接口，但不管怎麼樣，可以肯定的是 pthread_t 和 NSThread 是一一對應的。比如，你可以通過 pthread_main_thread_np() 或 [NSThread mainThread] 來獲取主線程；也可以通過 pthread_self() 或 [NSThread currentThread] 來獲取當前線程。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
staticCFMutableDictionaryRef
loopsDic;
/// 訪問 loopsDic 時的鎖
staticCFSpinLock_t
loopsLock;
/// 獲取一個 pthread 對應的 RunLoop。
CFRunLoopRef_CFRunLoopGet(pthread_tthread){
OSSpinLockLock(&loopsLock);
if(!loopsDic){
// 第一次進入時，初始化全局Dic，並先爲主線程創建一個 RunLoop。
loopsDic=
CFDictionaryCreateMutable();
CFRunLoopRefmainLoop
=_CFRunLoopCreate();
CFDictionarySetValue(loopsDic,pthread_main_thread_np(),mainLoop);
}
/// 直接從 Dictionary 裏獲取。
CFRunLoopRefloop
=CFDictionaryGetValue(loopsDic,thread));
if(!loop){
/// 取不到時，創建一個
loop=
_CFRunLoopCreate();
CFDictionarySetValue(loopsDic,thread,loop);
/// 註冊一個回調，當線程銷燬時，順便也銷燬其對應的 RunLoop。
_CFSetTSD(...,thread,loop,__CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
returnloop;
}
CFRunLoopRefCFRunLoopGetMain(){
return_CFRunLoopGet(pthread_main_thread_np());
}
CFRunLoopRefCFRunLoopGetCurrent(){
return_CFRunLoopGet(pthread_self());
}
|
從上面的代碼可以看出，線程和 RunLoop 之間是一一對應的，其關係是保存在一個全局的 Dictionary 裏。線程剛創建時並沒有 RunLoop，如果你不主動獲取，那它一直都不會有。RunLoop 的創建是發生在第一次獲取時，RunLoop 的銷燬是發生在線程結束時。你只能在一個線程的內部獲取其 RunLoop（主線程除外）。
RunLoop 對外的接口
在 CoreFoundation 裏面關於 RunLoop 有5個類:
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef
其中 CFRunLoopModeRef 類並沒有對外暴露，只是通過 CFRunLoopRef 的接口進行了封裝。他們的關係如下:
![RunLoop_0]()
一個 RunLoop 包含若干個 Mode，每個 Mode 又包含若干個 Source/Timer/Observer。每次調用 RunLoop 的主函數時，只能指定其中一個 Mode，這個Mode被稱作 CurrentMode。如果需要切換 Mode，只能退出 Loop，再重新指定一個 Mode 進入。這樣做主要是爲了分隔開不同組的 Source/Timer/Observer，讓其互不影響。
CFRunLoopSourceRef 是事件產生的地方。Source有兩個版本：Source0 和 Source1。
• Source0 只包含了一個回調（函數指針），它並不能主動觸發事件。使用時，你需要先調用 CFRunLoopSourceSignal(source)，將這個 Source 標記爲待處理，然後手動調用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop，讓其處理這個事件。
• Source1 包含了一個 mach_port 和一個回調（函數指針），被用於通過內核和其他線程相互發送消息。這種 Source 能主動喚醒 RunLoop 的線程，其原理在下面會講到。
CFRunLoopTimerRef 是基於時間的觸發器，它和 NSTimer 是toll-free bridged 的，可以混用。其包含一個時間長度和一個回調（函數指針）。當其加入到 RunLoop 時，RunLoop會註冊對應的時間點，當時間點到時，RunLoop會被喚醒以執行那個回調。
CFRunLoopObserverRef 是觀察者，每個 Observer 都包含了一個回調（函數指針），當 RunLoop 的狀態發生變化時，觀察者就能通過回調接受到這個變化。可以觀測的時間點有以下幾個：
|
|
typedefCF_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 會直接退出，不進入循環。
RunLoop 的 Mode
CFRunLoopMode 和 CFRunLoop 的結構大致如下：
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"：一個 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 會得到重複回調，但此時滑動一個TableView時，RunLoop 會將 mode 切換爲
TrackingRunLoopMode，這時 Timer 就不會被回調，並且也不會影響到滑動操作。
有時你需要一個 Timer，在兩個 Mode 中都能得到回調，一種辦法就是將這個 Timer 分別加入這兩個 Mode。還有一種方式，就是將 Timer 加入到頂層的 RunLoop 的 "commonModeItems" 中。"commonModeItems" 被 RunLoop 自動更新到所有具有"Common"屬性的 Mode 裏去。
CFRunLoop對外暴露的管理 Mode 接口只有下面2個:
|
|
CFRunLoopAddCommonMode(CFRunLoopRefrunloop,CFStringRef
modeName);
CFRunLoopRunInMode(CFStringRefmodeName,...);
|
Mode 暴露的管理 mode item 的接口有下面幾個：
|
|
CFRunLoopAddSource(CFRunLoopRefrl,CFRunLoopSourceRef
source,CFStringRef
modeName);
CFRunLoopAddObserver(CFRunLoopRefrl,CFRunLoopObserverRef
observer,CFStringRef
modeName);
CFRunLoopAddTimer(CFRunLoopRefrl,CFRunLoopTimerRef
timer,CFStringRef
mode);
CFRunLoopRemoveSource(CFRunLoopRefrl,CFRunLoopSourceRef
source,CFStringRef
modeName);
CFRunLoopRemoveObserver(CFRunLoopRefrl,CFRunLoopObserverRef
observer,CFStringRef
modeName);
CFRunLoopRemoveTimer(CFRunLoopRefrl,CFRunLoopTimerRef
timer,CFStringRef
mode);
|
你只能通過 mode name 來操作內部的 mode，當你傳入一個新的 mode name 但 RunLoop 內部沒有對應 mode 時，RunLoop會自動幫你創建對應的 CFRunLoopModeRef。對於一個 RunLoop 來說，其內部的 mode 只能增加不能刪除。
蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode，你可以用這兩個 Mode Name 來操作其對應的 Mode。
同時蘋果還提供了一個操作 Common 標記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，你可以用這個字符串來操作 Common Items，或標記一個 Mode 爲 "Common"。使用時注意區分這個字符串和其他 mode name。
RunLoop 的內部邏輯
根據蘋果在文檔裏的說明，RunLoop 內部的邏輯大致如下:
![RunLoop_1]()
其內部代碼整理如下 （太長了不想看可以直接跳過去，後面會有說明）：
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啓動
voidCFRunLoopRun(void){
CFRunLoopRunSpecific(CFRunLoopGetCurrent(),kCFRunLoopDefaultMode,1.0e10,false);
}
/// 用指定的Mode啓動，允許設置RunLoop超時時間
intCFRunLoopRunInMode(CFStringRefmodeName,CFTimeInterval
seconds,Boolean
stopAfterHandle){
returnCFRunLoopRunSpecific(CFRunLoopGetCurrent(),modeName,seconds,returnAfterSourceHandled);
}
/// RunLoop的實現
intCFRunLoopRunSpecific(runloop,modeName,seconds,stopAfterHandle){
/// 首先根據modeName找到對應mode
CFRunLoopModeRefcurrentMode
=__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){
BooleansourceHandledThisLoop=
NO;
intretVal
=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){
BooleanhasMsg
=__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。
elseif
(msg_is_dispatch){
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
}
/// 9.3 如果一個 Source1 (基於port) 發出事件了，處理這個事件
else{
CFRunLoopSourceRefsource1
=__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 的，其進入休眠時調用的函數是 mach_msg()。爲了解釋這個邏輯，下面稍微介紹一下 OSX/iOS 的系統架構。
![RunLoop_3]()
蘋果官方將整個系統大致劃分爲上述4個層次：
應用層包括用戶能接觸到的圖形應用，例如 Spotlight、Aqua、SpringBoard 等。
應用框架層即開發人員接觸到的 Cocoa 等框架。
核心框架層包括各種核心框架、OpenGL 等內容。
Darwin 即操作系統的核心，包括系統內核、驅動、Shell 等內容，這一層是開源的，其所有源碼都可以在
opensource.apple.com 裏找到。
我們在深入看一下 Darwin 這個核心的架構：
![RunLoop_4]()
其中，在硬件層上面的三個組成部分：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
|
typedefstruct
{
mach_msg_header_theader;
mach_msg_body_tbody;
}mach_msg_base_t;
typedefstruct
{
mach_msg_bits_tmsgh_bits;
mach_msg_size_tmsgh_size;
mach_port_tmsgh_remote_port;
mach_port_tmsgh_local_port;
mach_port_name_tmsgh_voucher_port;
mach_msg_id_tmsgh_id;
}mach_msg_header_t;
|
一條 Mach 消息實際上就是一個二進制數據包 (BLOB)，其頭部定義了當前端口 local_port 和目標端口 remote_port，
發送和接受消息是通過同一個 API 進行的，其 option 標記了消息傳遞的方向：
|
|
mach_msg_return_tmach_msg(
mach_msg_header_t *msg,
mach_msg_option_toption,
mach_msg_size_tsend_size,
mach_msg_size_trcv_size,
mach_port_name_trcv_name,
mach_msg_timeout_ttimeout,
mach_port_name_tnotify);
|
爲了實現消息的發送和接收，mach_msg() 函數實際上是調用了一個 Mach 陷阱 (trap)，即函數mach_msg_trap()，陷阱這個概念在 Mach 中等同於系統調用。當你在用戶態調用 mach_msg_trap() 時會觸發陷阱機制，切換到內核態；內核態中內核實現的 mach_msg() 函數會完成實際的工作，如下圖：
![RunLoop_5]()
這些概念可以參考維基百科: System_call、Trap_(computing)。
RunLoop 的核心就是一個 mach_msg() (見上面代碼的第7步)，RunLoop 調用這個函數去接收消息，如果沒有別人發送 port 消息過來，內核會將線程置於等待狀態。例如你在模擬器裏跑起一個 iOS 的 App，然後在 App 靜止時點擊暫停，你會看到主線程調用棧是停留在 mach_msg_trap() 這個地方。
關於具體的如何利用 mach port 發送信息，可以看看 NSHipster 這一篇文章，或者這裏的中文翻譯 。
關於Mach的歷史可以看看這篇很有趣的文章：Mac OS X 背後的故事（三）Mach 之父 Avie Tevanian。
蘋果用 RunLoop 實現的功能
首先我們可以看一下 App 啓動後 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
|
CFRunLoop{
currentmode
=kCFRunLoopDefaultMode
commonmodes
={
UITrackingRunLoopMode
kCFRunLoopDefaultMode
}
commonmode
items=
{
// source0 (manual)
CFRunLoopSource{order=-1,{
callout=
_UIApplicationHandleEventQueue}}
CFRunLoopSource{order=-1,{
callout=
PurpleEventSignalCallback}}
CFRunLoopSource{order=
0,{
callout=
FBSSerialQueueRunLoopSourceHandler}}
// source1 (mach port)
CFRunLoopSource{order=
0, {port=
17923}}
CFRunLoopSource{order=
0, {port=
12039}}
CFRunLoopSource{order=
0, {port=
16647}}
CFRunLoopSource{order=-1,{
callout=
PurpleEventCallback}}
CFRunLoopSource{order=
0,{port=
2407,
callout=
_ZL20notify_port_callbackP12__CFMachPortPvlS1_}}
CFRunLoopSource{order=
0,{port=
1c03,
callout=
__IOHIDEventSystemClientAvailabilityCallback}}
CFRunLoopSource{order=
0,{port=
1b03,
callout=
__IOHIDEventSystemClientQueueCallback}}
CFRunLoopSource{order=
1,{port=
1903,
callout=
__IOMIGMachPortPortCallback}}
// Ovserver
CFRunLoopObserver{order=
-2147483647,activities
=0x1,// Entry
callout=
_wrapRunLoopWithAutoreleasePoolHandler}
CFRunLoopObserver{order=
0,activities
=0x20, // BeforeWaiting
callout=
_UIGestureRecognizerUpdateObserver}
CFRunLoopObserver{order=
1999000,activities
=0xa0, // BeforeWaiting | Exit
callout=
_afterCACommitHandler}
CFRunLoopObserver{order=
2000000,activities
=0xa0, // BeforeWaiting | Exit
callout=
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}
CFRunLoopObserver{order=
2147483647,activities
=0xa0,// BeforeWaiting | Exit
callout=
_wrapRunLoopWithAutoreleasePoolHandler}
// Timer
CFRunLoopTimer{firing=
No,interval
=3.1536e+09,tolerance
=0,
nextfire
date=
453098071(-4421.76019@
96223387169499),
callout=
_ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv(QuartzCore.framework)}
},
modes＝
{
CFRunLoopMode {
sources0= {/*
same as 'common mode items' */},
sources1= {/*
same as 'common mode items' */},
observers=
{/* same as 'common mode items' */},
timers= {/*
same as 'common mode items' */},
},
CFRunLoopMode {
sources0= {/*
same as 'common mode items' */},
sources1= {/*
same as 'common mode items' */},
observers=
{/* same as 'common mode items' */},
timers= {/*
same as 'common mode items' */},
},
CFRunLoopMode {
sources0=
{
CFRunLoopSource{order=
0,{
callout=
FBSSerialQueueRunLoopSourceHandler}}
},
sources1=
(null),
observers=
{
CFRunLoopObserver>{activities=
0xa0,order
=2000000,
callout=
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}
)},
timers=
(null),
},
CFRunLoopMode {
sources0=
{
CFRunLoopSource{order=
-1,{
callout=
PurpleEventSignalCallback}}
},
sources1=
{
CFRunLoopSource{order=
-1,{
callout=
PurpleEventCallback}}
},
observers=
(null),
timers=
(null),
},
CFRunLoopMode {
sources0=
(null),
sources1=
(null),
observers=
(null),
timers=
(null),
}
}
}
|
可以看到，系統默認註冊了5個Mode:
1. kCFRunLoopDefaultMode: App的默認 Mode，通常主線程是在這個 Mode 下運行的。
2. UITrackingRunLoopMode: 界面跟蹤 Mode，用於 ScrollView 追蹤觸摸滑動，保證界面滑動時不受其他 Mode 影響。
3. UIInitializationRunLoopMode: 在剛啓動 App 時第進入的第一個 Mode，啓動完成後就不再使用。
4: GSEventReceiveRunLoopMode: 接受系統事件的內部 Mode，通常用不到。
5: kCFRunLoopCommonModes: 這是一個佔位的 Mode，沒有實際作用。
你可以在這裏看到更多的蘋果內部的 Mode，但那些 Mode 在開發中就很難遇到了。
當 RunLoop 進行回調時，一般都是通過一個很長的函數調用出去 (call out), 當你在你的代碼中下斷點調試時，通常能在調用棧上看到這些函數。下面是這幾個函數的整理版本，如果你在調用棧中看到這些長函數名，在這裏查找一下就能定位到具體的調用地點了：
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
|
{
/// 1. 通知Observers，即將進入RunLoop
/// 此處有Observer會創建AutoreleasePool: _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
do{
/// 2. 通知 Observers: 即將觸發 Timer 回調。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: 即將觸發 Source (非基於port的,Source0) 回調。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 4. 觸發 Source0 (非基於port的) 回調。
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 6. 通知Observers，即將進入休眠
/// 此處有Observer釋放並新建AutoreleasePool: _objc_autoreleasePoolPop(); _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeWaiting);
/// 7. sleep to wait msg.
mach_msg()->
mach_msg_trap();
/// 8. 通知Observers，線程被喚醒
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopAfterWaiting);
/// 9. 如果是被Timer喚醒的，回調Timer
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);
/// 9. 如果是被dispatch喚醒的，執行所有調用 dispatch_async 等方法放入main queue 的 block
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(dispatched_block);
/// 9. 如果如果Runloop是被 Source1 (基於port的) 的事件喚醒了，處理這個事件
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__(source1);
}while
(...);
/// 10. 通知Observers，即將退出RunLoop
/// 此處有Observer釋放AutoreleasePool: _objc_autoreleasePoolPop();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopExit);
}
|
AutoreleasePool
App啓動後，蘋果在主線程 RunLoop 裏註冊了兩個 Observer，其回調都是 _wrapRunLoopWithAutoreleasePoolHandler()。
第一個 Observer 監視的事件是 Entry(即將進入Loop)，其回調內會調用 _objc_autoreleasePoolPush() 創建自動釋放池。其 order 是-2147483647，優先級最高，保證創建釋放池發生在其他所有回調之前。
第二個 Observer 監視了兩個事件： BeforeWaiting(準備進入休眠) 時調用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池並創建新池；Exit(即將退出Loop) 時調用 _objc_autoreleasePoolPop() 來釋放自動釋放池。這個 Observer 的 order 是 2147483647，優先級最低，保證其釋放池子發生在其他所有回調之後。
在主線程執行的代碼，通常是寫在諸如事件回調、Timer回調內的。這些回調會被 RunLoop 創建好的 AutoreleasePool 環繞着，所以不會出現內存泄漏，開發者也不必顯示創建 Pool 了。
事件響應
蘋果註冊了一個 Source1 (基於 mach port 的) 用來接收系統事件，其回調函數爲 __IOHIDEventSystemClientQueueCallback()。
當一個硬件事件(觸摸/鎖屏/搖晃等)發生後，首先由 IOKit.framework 生成一個 IOHIDEvent 事件並由 SpringBoard 接收。這個過程的詳細情況可以參考這裏。SpringBoard 只接收按鍵(鎖屏/靜音等)，觸摸，加速，接近傳感器等幾種 Event，隨後用 mach port 轉發給需要的App進程。隨後蘋果註冊的那個
Source1 就會觸發回調，並調用 _UIApplicationHandleEventQueue() 進行應用內部的分發。
_UIApplicationHandleEventQueue() 會把 IOHIDEvent 處理幷包裝成 UIEvent 進行處理或分發，其中包括識別 UIGesture/處理屏幕旋轉/發送給 UIWindow 等。通常事件比如 UIButton 點擊、touchesBegin/Move/End/Cancel 事件都是在這個回調中完成的。
手勢識別
當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會調用 Cancel 將當前的 touchesBegin/Move/End 系列回調打斷。隨後系統將對應的 UIGestureRecognizer 標記爲待處理。
蘋果註冊了一個 Observer 監測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回調函數是 _UIGestureRecognizerUpdateObserver()，其內部會獲取所有剛被標記爲待處理的 GestureRecognizer，並執行GestureRecognizer的回調。
當有 UIGestureRecognizer 的變化(創建/銷燬/狀態改變)時，這個回調都會進行相應處理。
界面更新
當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動調用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法後，這個 UIView/CALayer 就被標記爲待處理，並被提交到一個全局的容器去。
蘋果註冊了一個 Observer 監聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調去執行一個很長的函數：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數裏會遍歷所有待處理的 UIView/CAlayer 以執行實際的繪製和調整，並更新 UI 界面。
這個函數內部的調用棧大概是這樣的：
|
|
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
QuartzCore:CA::Transaction::observer_callback:
CA::Transaction::commit();
CA::Context::commit_transaction();
CA::Layer::layout_and_display_if_needed();
CA::Layer::layout_if_needed();
[CALayerlayoutSublayers];
[UIViewlayoutSubviews];
CA::Layer::display_if_needed();
[CALayerdisplay];
[UIViewdrawRect];
|
定時器
NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 註冊到 RunLoop 後，RunLoop 會爲其重複的時間點註冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop爲了節省資源，並不會在非常準確的時間點回調這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到後，容許有多少最大誤差。
如果某個時間點被錯過了，例如執行了一個很長的任務，則那個時間點的回調也會跳過去，不會延後執行。就比如等公交，如果 10:10 時我忙着玩手機錯過了那個點的公交，那我只能等 10:20 這一趟了。
CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現原理更復雜，和 NSTimer 並不一樣，其內部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執行了一個長任務，那其中就會有一幀被跳過去（和 NSTimer 相似），造成界面卡頓的感覺。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是爲了解決界面卡頓的問題，其內部也用到了 RunLoop，這個稍後我會再單獨寫一頁博客來分析。
PerformSelecter
當調用 NSObject 的 performSelecter:afterDelay: 後，實際上其內部會創建一個 Timer 並添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop，則這個方法會失效。
當調用 performSelector:onThread: 時，實際上其會創建一個 Timer 加到對應的線程去，同樣的，如果對應線程沒有 RunLoop 該方法也會失效。
關於GCD
實際上 RunLoop 底層也會用到 GCD 的東西，比如 RunLoop 是用 dispatch_source_t 實現的 Timer（評論中有人提醒，NSTimer 是用了 XNU 內核的 mk_timer，我也仔細調試了一下，發現 NSTimer 確實是由 mk_timer 驅動，而非 GCD 驅動的）。但同時 GCD 提供的某些接口也用到了 RunLoop， 例如 dispatch_async()。
當調用 dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主線程的 RunLoop 發送消息，RunLoop會被喚醒，並從消息中取得這個 block，並在回調 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 裏執行這個 block。但這個邏輯僅限於 dispatch 到主線程，dispatch 到其他線程仍然是由 libDispatch 處理的。
關於網絡請求
iOS 中，關於網絡請求的接口自下至上有如下幾層:
|
|
CFSocket
CFNetwork ->ASIHttpRequest
NSURLConnection->AFNetworking
NSURLSession ->AFNetworking2,Alamofire
|
• CFSocket 是最底層的接口，只負責 socket 通信。
• CFNetwork 是基於 CFSocket 等接口的上層封裝，ASIHttpRequest 工作於這一層。
• NSURLConnection 是基於 CFNetwork 的更高層的封裝，提供面向對象的接口，AFNetworking 工作於這一層。
• NSURLSession 是 iOS7 中新增的接口，表面上是和 NSURLConnection 並列的，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)，AFNetworking2 和 Alamofire 工作於這一層。
下面主要介紹下 NSURLConnection 的工作過程。
通常使用 NSURLConnection 時，你會傳入一個 Delegate，當調用了 [connection start] 後，這個 Delegate 就會不停收到事件回調。實際上，start 這個函數的內部會會獲取 CurrentRunLoop，然後在其中的 DefaultMode 添加了4個 Source0 (即需要手動觸發的Source)。CFMultiplexerSource 是負責各種 Delegate 回調的，CFHTTPCookieStorage 是處理各種 Cookie 的。
當開始網絡傳輸時，我們可以看到 NSURLConnection 創建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的。NSURLConnectionLoader 這個線程內部會使用 RunLoop 來接收底層 socket 的事件，並通過之前添加的 Source0 通知到上層的 Delegate。
![RunLoop_network]()
NSURLConnectionLoader 中的 RunLoop 通過一些基於 mach port 的 Source 接收來自底層 CFSocket 的通知。當收到通知後，其會在合適的時機向 CFMultiplexerSource 等 Source0 發送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執行實際的回調。
RunLoop 的實際應用舉例
AFNetworking
AFURLConnectionOperation 這個類是基於 NSURLConnection 構建的，其希望能在後臺線程接收 Delegate 回調。爲此 AFNetworking 單獨創建了一個線程，並在這個線程中啓動了一個
RunLoop：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
+(void)networkRequestThreadEntryPoint:(id)__unusedobject
{
@autoreleasepool{
[[NSThreadcurrentThread]setName:@"AFNetworking"];
NSRunLoop *runLoop=
[NSRunLoopcurrentRunLoop];
[runLoopaddPort:[NSMachPortport]forMode:NSDefaultRunLoopMode];
[runLooprun];
}
}
+(NSThread *)networkRequestThread{
staticNSThread *_networkRequestThread=
nil;
staticdispatch_once_t
oncePredicate;
dispatch_once(&oncePredicate,^{
_networkRequestThread=
[[NSThreadalloc]initWithTarget:selfselector:@selector(networkRequestThreadEntryPoint:)object:nil];
[_networkRequestThreadstart];
});
return_networkRequestThread;
}
|
RunLoop 啓動前內部必須要有至少一個 Timer/Observer/Source，所以 AFNetworking 在 [runLoop run] 之前先創建了一個新的 NSMachPort 添加進去了。通常情況下，調用者需要持有這個 NSMachPort (mach_port) 並在外部線程通過這個 port 發送消息到 loop 內；但此處添加 port 只是爲了讓 RunLoop 不至於退出，並沒有用於實際的發送消息。
|
|
-(void)start{
[self.locklock];
if([selfisCancelled]){
[selfperformSelector:@selector(cancelConnection)onThread:[[selfclass]networkRequestThread]withObject:nilwaitUntilDone:NOmodes:[self.runLoopModesallObjects]];
}else
if([selfisReady]){
self.state=
AFOperationExecutingState;
[selfperformSelector:@selector(operationDidStart)onThread:[[selfclass]networkRequestThread]withObject:nilwaitUntilDone:NOmodes:[self.runLoopModesallObjects]];
}
[self.lockunlock];
}
|
當需要這個後臺線程執行任務時，AFNetworking 通過調用 [NSObject performSelector:onThread:..] 將這個任務扔到了後臺線程的 RunLoop 中。
AsyncDisplayKit
AsyncDisplayKit 是 Facebook 推出的用於保持界面流暢性的框架，其原理大致如下：
UI 線程中一旦出現繁重的任務就會導致界面卡頓，這類任務通常分爲3類：排版，繪製，UI對象操作。
排版通常包括計算視圖大小、計算文本高度、重新計算子式圖的排版等操作。
繪製一般有文本繪製 (例如 CoreText)、圖片繪製 (例如預先解壓)、元素繪製 (Quartz)等操作。
UI對象操作通常包括 UIView/CALayer 等 UI 對象的創建、設置屬性和銷燬。
其中前兩類操作可以通過各種方法扔到後臺線程執行，而最後一類操作只能在主線程完成，並且有時後面的操作需要依賴前面操作的結果 （例如TextView創建時可能需要提前計算出文本的大小）。ASDK 所做的，就是儘量將能放入後臺的任務放入後臺，不能的則儘量推遲 (例如視圖的創建、屬性的調整)。
爲此，ASDK 創建了一個名爲 ASDisplayNode 的對象，並在內部封裝了 UIView/CALayer，它具有和 UIView/CALayer 相似的屬性，例如 frame、backgroundColor等。所有這些屬性都可以在後臺線程更改，開發者可以只通過 Node 來操作其內部的 UIView/CALayer，這樣就可以將排版和繪製放入了後臺線程。但是無論怎麼操作，這些屬性總需要在某個時刻同步到主線程的 UIView/CALayer 去。
ASDK 仿照 QuartzCore/UIKit 框架的模式，實現了一套類似的界面更新的機制：即在主線程的 RunLoop 中添加一個 Observer，監聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件，在收到回調時，遍歷所有之前放入隊列的待處理的任務，然後一一執行。
具體的代碼可以看這裏：_ASAsyncTransactionGroup。
2016-4-16更新
網上找的相關視頻：
視頻: iOS線下分享《RunLoop》by 孫源@sunnyxx
http://v.youku.com/v_show/id_XODgxODkzODI0.html
