https://blog.ibireme.com/2015/05/18/runloop/
RunLoop 是 iOS 和 OSX 開發(fā)中非常基礎(chǔ)的一個概念馅而，這篇文章將從 CFRunLoop 的源碼入手，介紹 RunLoop 的概念以及底層實現(xiàn)原理撑柔。之后會介紹一下在 iOS 中跪帝，蘋果是如何利用 RunLoop 實現(xiàn)自動釋放池顶别、延遲回調(diào)、觸摸事件檩咱、屏幕刷新等功能的揭措。
Index
RunLoop 的概念
一般來講，一個線程一次只能執(zhí)行一個任務(wù)刻蚯，執(zhí)行完成后線程就會退出绊含。如果我們需要一個機制，讓線程能隨時處理事件但并不退出炊汹，通常的代碼邏輯是這樣的：
functionloop(){
initialize();
do{
varmessage=get_next_message();
process_message(message);
}while(message!=quit);
}
這種模型通常被稱作Event Loop躬充。 Event Loop 在很多系統(tǒng)和框架里都有實現(xiàn)，比如 Node.js 的事件處理讨便，比如 Windows 程序的消息循環(huán)充甚，再比如 OSX/iOS 里的 RunLoop。實現(xiàn)這種模型的關(guān)鍵點在于：如何管理事件/消息器钟，如何讓線程在沒有處理消息時休眠以避免資源占用、在有消息到來時立刻被喚醒妙蔗。
所以傲霸，RunLoop 實際上就是一個對象，這個對象管理了其需要處理的事件和消息眉反，并提供了一個入口函數(shù)來執(zhí)行上面 Event Loop 的邏輯昙啄。線程執(zhí)行了這個函數(shù)后，就會一直處于這個函數(shù)內(nèi)部 “接受消息->等待->處理” 的循環(huán)中寸五，直到這個循環(huán)結(jié)束（比如傳入 quit 的消息）梳凛，函數(shù)返回。
OSX/iOS 系統(tǒng)中梳杏，提供了兩個這樣的對象：NSRunLoop 和 CFRunLoopRef韧拒。
CFRunLoopRef 是在 CoreFoundation 框架內(nèi)的淹接，它提供了純 C 函數(shù)的 API，所有這些 API 都是線程安全的叛溢。
NSRunLoop 是基于 CFRunLoopRef 的封裝塑悼，提供了面向?qū)ο蟮?API，但是這些 API 不是線程安全的楷掉。
CFRunLoopRef 的代碼是開源的厢蒜，你可以在這里http://opensource.apple.com/tarballs/CF/下載到整個 CoreFoundation 的源碼來查看。
(Update: Swift 開源后烹植，蘋果又維護了一個跨平臺的 CoreFoundation 版本：https://github.com/apple/swift-corelibs-foundation/斑鸦，這個版本的源碼可能和現(xiàn)有 iOS 系統(tǒng)中的實現(xiàn)略不一樣，但更容易編譯草雕，而且已經(jīng)適配了 Linux/Windows巷屿。)
RunLoop 與線程的關(guān)系
首先，iOS 開發(fā)中能遇到兩個線程對象: pthread_t 和 NSThread促绵。過去蘋果有份文檔標(biāo)明了 NSThread 只是 pthread_t 的封裝攒庵，但那份文檔已經(jīng)失效了，現(xiàn)在它們也有可能都是直接包裝自最底層的 mach thread败晴。蘋果并沒有提供這兩個對象相互轉(zhuǎn)換的接口浓冒，但不管怎么樣，可以肯定的是 pthread_t 和 NSThread 是一一對應(yīng)的尖坤。比如稳懒，你可以通過 pthread_main_thread_np() 或 [NSThread mainThread] 來獲取主線程；也可以通過 pthread_self() 或 [NSThread currentThread] 來獲取當(dāng)前線程慢味。CFRunLoop 是基于 pthread 來管理的场梆。
蘋果不允許直接創(chuàng)建 RunLoop，它只提供了兩個自動獲取的函數(shù)：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()纯路。 這兩個函數(shù)內(nèi)部的邏輯大概是下面這樣:
1/// 全局的Dictionary或油，key 是 pthread_t， value 是 CFRunLoopRef
staticCFMutableDictionaryRefloopsDic;
/// 訪問 loopsDic 時的鎖
staticCFSpinLock_tloopsLock;
/// 獲取一個 pthread 對應(yīng)的 RunLoop驰唬。
CFRunLoopRef_CFRunLoopGet(pthread_tthread){
OSSpinLockLock(&loopsLock);
if(!loopsDic){
// 第一次進入時顶岸，初始化全局Dic，并先為主線程創(chuàng)建一個 RunLoop叫编。
loopsDic=CFDictionaryCreateMutable();
CFRunLoopRefmainLoop=_CFRunLoopCreate();
CFDictionarySetValue(loopsDic,pthread_main_thread_np(),mainLoop);
}
/// 直接從 Dictionary 里獲取辖佣。
CFRunLoopRefloop=CFDictionaryGetValue(loopsDic,thread));
if(!loop){
/// 取不到時，創(chuàng)建一個
loop=_CFRunLoopCreate();
CFDictionarySetValue(loopsDic,thread,loop);
/// 注冊一個回調(diào)搓逾，當(dāng)線程銷毀時卷谈，順便也銷毀其對應(yīng)的 RunLoop。
_CFSetTSD(...,thread,loop,__CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
returnloop;
}
CFRunLoopRefCFRunLoopGetMain(){
return_CFRunLoopGet(pthread_main_thread_np());
}
CFRunLoopRefCFRunLoopGetCurrent(){
return_CFRunLoopGet(pthread_self());
}
從上面的代碼可以看出霞篡，線程和 RunLoop 之間是一一對應(yīng)的世蔗，其關(guān)系是保存在一個全局的 Dictionary 里端逼。線程剛創(chuàng)建時并沒有 RunLoop，如果你不主動獲取凸郑，那它一直都不會有裳食。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時，RunLoop 的銷毀是發(fā)生在線程結(jié)束時芙沥。你只能在一個線程的內(nèi)部獲取其 RunLoop（主線程除外）诲祸。
RunLoop 對外的接口
在 CoreFoundation 里面關(guān)于 RunLoop 有5個類:
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef
其中 CFRunLoopModeRef 類并沒有對外暴露，只是通過 CFRunLoopRef 的接口進行了封裝而昨。他們的關(guān)系如下:
一個 RunLoop 包含若干個 Mode救氯，每個 Mode 又包含若干個 Source/Timer/Observer。每次調(diào)用 RunLoop 的主函數(shù)時歌憨，只能指定其中一個 Mode镇防，這個Mode被稱作 CurrentMode肩狂。如果需要切換 Mode，只能退出 Loop，再重新指定一個 Mode 進入售淡。這樣做主要是為了分隔開不同組的 Source/Timer/Observer俘枫，讓其互不影響译断。
CFRunLoopSourceRef是事件產(chǎn)生的地方谦炒。Source有兩個版本：Source0 和 Source1。
? Source0 只包含了一個回調(diào)（函數(shù)指針）去扣，它并不能主動觸發(fā)事件柱衔。使用時，你需要先調(diào)用 CFRunLoopSourceSignal(source)愉棱，將這個 Source 標(biāo)記為待處理唆铐，然后手動調(diào)用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop，讓其處理這個事件奔滑。
? Source1 包含了一個 mach_port 和一個回調(diào)（函數(shù)指針）艾岂，被用于通過內(nèi)核和其他線程相互發(fā)送消息。這種 Source 能主動喚醒 RunLoop 的線程朋其，其原理在下面會講到王浴。
CFRunLoopTimerRef是基于時間的觸發(fā)器，它和 NSTimer 是toll-free bridged 的令宿，可以混用叼耙。其包含一個時間長度和一個回調(diào)（函數(shù)指針）腕窥。當(dāng)其加入到 RunLoop 時粒没，RunLoop會注冊對應(yīng)的時間點，當(dāng)時間點到時簇爆，RunLoop會被喚醒以執(zhí)行那個回調(diào)癞松。
CFRunLoopObserverRef是觀察者爽撒，每個 Observer 都包含了一個回調(diào)（函數(shù)指針），當(dāng) RunLoop 的狀態(tài)發(fā)生變化時响蓉，觀察者就能通過回調(diào)接受到這個變化硕勿。可以觀測的時間點有以下幾個：
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 被統(tǒng)稱為mode item枫甲，一個 item 可以被同時加入多個 mode源武。但一個 item 被重復(fù)加入同一個 mode 時是不會有效果的。如果一個 mode 中一個 item 都沒有想幻，則 RunLoop 會直接退出粱栖，不進入循環(huán)。
RunLoop 的 Mode
CFRunLoopMode 和 CFRunLoop 的結(jié)構(gòu)大致如下：
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
CFRunLoopModeRef_currentMode;// Current Runloop Mode
CFMutableSetRef_modes;// Set
...
};
這里有個概念叫 “CommonModes”：一個 Mode 可以將自己標(biāo)記為”Common”屬性（通過將其 ModeName 添加到 RunLoop 的 “commonModes” 中）脏毯。每當(dāng) RunLoop 的內(nèi)容發(fā)生變化時闹究，RunLoop 都會自動將 _commonModeItems 里的 Source/Observer/Timer 同步到具有 “Common” 標(biāo)記的所有Mode里。
應(yīng)用場景舉例：主線程的 RunLoop 里有兩個預(yù)置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode食店。這兩個 Mode 都已經(jīng)被標(biāo)記為”Common”屬性渣淤。DefaultMode 是 App 平時所處的狀態(tài)，TrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態(tài)吉嫩。當(dāng)你創(chuàng)建一個 Timer 并加到 DefaultMode 時价认，Timer 會得到重復(fù)回調(diào)，但此時滑動一個TableView時率挣，RunLoop 會將 mode 切換為 TrackingRunLoopMode刻伊，這時 Timer 就不會被回調(diào)，并且也不會影響到滑動操作椒功。
有時你需要一個 Timer捶箱，在兩個 Mode 中都能得到回調(diào)，一種辦法就是將這個 Timer 分別加入這兩個 Mode动漾。還有一種方式丁屎，就是將 Timer 加入到頂層的 RunLoop 的 “commonModeItems” 中『得校”commonModeItems” 被 RunLoop 自動更新到所有具有”Common”屬性的 Mode 里去晨川。
CFRunLoop對外暴露的管理 Mode 接口只有下面2個:
1
2
CFRunLoopAddCommonMode(CFRunLoopRefrunloop,CFStringRefmodeName);
CFRunLoopRunInMode(CFStringRefmodeName,...);
Mode 暴露的管理 mode item 的接口有下面幾個：
1
2
3
4
5
6
CFRunLoopAddSource(CFRunLoopRefrl,CFRunLoopSourceRefsource,CFStringRefmodeName);
CFRunLoopAddObserver(CFRunLoopRefrl,CFRunLoopObserverRefobserver,CFStringRefmodeName);
CFRunLoopAddTimer(CFRunLoopRefrl,CFRunLoopTimerReftimer,CFStringRefmode);
CFRunLoopRemoveSource(CFRunLoopRefrl,CFRunLoopSourceRefsource,CFStringRefmodeName);
CFRunLoopRemoveObserver(CFRunLoopRefrl,CFRunLoopObserverRefobserver,CFStringRefmodeName);
CFRunLoopRemoveTimer(CFRunLoopRefrl,CFRunLoopTimerReftimer,CFStringRefmode);
你只能通過 mode name 來操作內(nèi)部的 mode，當(dāng)你傳入一個新的 mode name 但 RunLoop 內(nèi)部沒有對應(yīng) mode 時删豺，RunLoop會自動幫你創(chuàng)建對應(yīng)的 CFRunLoopModeRef共虑。對于一個 RunLoop 來說，其內(nèi)部的 mode 只能增加不能刪除呀页。
蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode妈拌，你可以用這兩個 Mode Name 來操作其對應(yīng)的 Mode。
同時蘋果還提供了一個操作 Common 標(biāo)記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)蓬蝶，你可以用這個字符串來操作 Common Items尘分，或標(biāo)記一個 Mode 為 “Common”猜惋。使用時注意區(qū)分這個字符串和其他 mode name。
RunLoop 的內(nèi)部邏輯
根據(jù)蘋果在文檔里的說明培愁，RunLoop 內(nèi)部的邏輯大致如下:
其內(nèi)部代碼整理如下 （太長了不想看可以直接跳過去著摔，后面會有說明）：
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啟動，允許設(shè)置RunLoop超時時間
intCFRunLoopRunInMode(CFStringRefmodeName,CFTimeIntervalseconds,BooleanstopAfterHandle){
returnCFRunLoopRunSpecific(CFRunLoopGetCurrent(),modeName,seconds,returnAfterSourceHandled);
}
/// RunLoop的實現(xiàn)
intCFRunLoopRunSpecific(runloop,modeName,seconds,stopAfterHandle){
/// 首先根據(jù)modeName找到對應(yīng)mode
CFRunLoopModeRefcurrentMode=__CFRunLoopFindMode(runloop,modeName,false);
/// 如果mode里沒有source/timer/observer, 直接返回定续。
if(__CFRunLoopModeIsEmpty(currentMode))return;
/// 1. 通知 Observers: RunLoop 即將進入 loop谍咆。
__CFRunLoopDoObservers(runloop,currentMode,kCFRunLoopEntry);
/// 內(nèi)部函數(shù)，進入loop
__CFRunLoopRun(runloop,currentMode,seconds,returnAfterSourceHandled){
BooleansourceHandledThisLoop=NO;
intretVal=0;
do{
/// 2. 通知 Observers: RunLoop 即將觸發(fā) Timer 回調(diào)私股。
__CFRunLoopDoObservers(runloop,currentMode,kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: RunLoop 即將觸發(fā) Source0 (非port) 回調(diào)卧波。
__CFRunLoopDoObservers(runloop,currentMode,kCFRunLoopBeforeSources);
/// 執(zhí)行被加入的block
__CFRunLoopDoBlocks(runloop,currentMode);
/// 4. RunLoop 觸發(fā) Source0 (非port) 回調(diào)。
sourceHandledThisLoop=__CFRunLoopDoSources0(runloop,currentMode,stopAfterHandle);
/// 執(zhí)行被加入的block
__CFRunLoopDoBlocks(runloop,currentMode);
/// 5. 如果有 Source1 (基于port) 處于 ready 狀態(tài)庇茫，直接處理這個 Source1 然后跳轉(zhuǎn)去處理消息港粱。
if(__Source0DidDispatchPortLastTime){
BooleanhasMsg=__CFRunLoopServiceMachPort(dispatchPort,&msg)
if(hasMsg)gotohandle_msg;
}
/// 通知 Observers: RunLoop 的線程即將進入休眠(sleep)。
if(!sourceHandledThisLoop){
__CFRunLoopDoObservers(runloop,currentMode,kCFRunLoopBeforeWaiting);
}
/// 7. 調(diào)用 mach_msg 等待接受 mach_port 的消息旦签。線程將進入休眠, 直到被下面某一個事件喚醒查坪。
/// ? 一個基于 port 的Source 的事件。
/// ? 一個 Timer 到時間了
/// ? RunLoop 自身的超時時間到了
/// ? 被其他什么調(diào)用者手動喚醒
__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 到時間了羔巢，觸發(fā)這個Timer的回調(diào)望忆。
if(msg_is_timer){
__CFRunLoopDoTimers(runloop,currentMode,mach_absolute_time())
}
/// 9.2 如果有dispatch到main_queue的block，執(zhí)行block竿秆。
elseif(msg_is_dispatch){
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
}
/// 9.3 如果一個 Source1 (基于port) 發(fā)出事件了启摄，處理這個事件
else{
CFRunLoopSourceRefsource1=__CFRunLoopModeFindSourceForMachPort(runloop,currentMode,livePort);
sourceHandledThisLoop=__CFRunLoopDoSource1(runloop,currentMode,source1,msg);
if(sourceHandledThisLoop){
mach_msg(reply,MACH_SEND_MSG,reply);
}
}
/// 執(zhí)行加入到Loop的block
__CFRunLoopDoBlocks(runloop,currentMode);
if(sourceHandledThisLoop&&stopAfterHandle){
/// 進入loop時參數(shù)說處理完事件就返回。
retVal=kCFRunLoopRunHandledSource;
}elseif(timeout){
/// 超出傳入?yún)?shù)標(biāo)記的超時時間了
retVal=kCFRunLoopRunTimedOut;
}elseif(__CFRunLoopIsStopped(runloop)){
/// 被外部調(diào)用者強制停止了
retVal=kCFRunLoopRunStopped;
}elseif(__CFRunLoopModeIsEmpty(runloop,currentMode)){
/// source/timer/observer一個都沒有了
retVal=kCFRunLoopRunFinished;
}
/// 如果沒超時幽钢，mode里沒空歉备，loop也沒被停止，那繼續(xù)loop匪燕。
}while(retVal==0);
}
/// 10. 通知 Observers: RunLoop 即將退出蕾羊。
__CFRunLoopDoObservers(rl,currentMode,kCFRunLoopExit);
}
可以看到，實際上 RunLoop 就是這樣一個函數(shù)帽驯，其內(nèi)部是一個 do-while 循環(huán)龟再。當(dāng)你調(diào)用 CFRunLoopRun() 時，線程就會一直停留在這個循環(huán)里尼变；直到超時或被手動停止利凑，該函數(shù)才會返回。
RunLoop 的底層實現(xiàn)
從上面代碼可以看到，RunLoop 的核心是基于 mach port 的截碴，其進入休眠時調(diào)用的函數(shù)是 mach_msg()。為了解釋這個邏輯蛉威，下面稍微介紹一下 OSX/iOS 的系統(tǒng)架構(gòu)日丹。
蘋果官方將整個系統(tǒng)大致劃分為上述4個層次：
應(yīng)用層包括用戶能接觸到的圖形應(yīng)用，例如 Spotlight蚯嫌、Aqua哲虾、SpringBoard 等。
應(yīng)用框架層即開發(fā)人員接觸到的 Cocoa 等框架择示。
核心框架層包括各種核心框架束凑、OpenGL 等內(nèi)容。
Darwin 即操作系統(tǒng)的核心栅盲，包括系統(tǒng)內(nèi)核汪诉、驅(qū)動、Shell 等內(nèi)容谈秫，這一層是開源的扒寄，其所有源碼都可以在opensource.apple.com里找到。
我們在深入看一下 Darwin 這個核心的架構(gòu)：
其中拟烫，在硬件層上面的三個組成部分：Mach该编、BSD、IOKit (還包括一些上面沒標(biāo)注的內(nèi)容)硕淑，共同組成了 XNU 內(nèi)核课竣。
XNU 內(nèi)核的內(nèi)環(huán)被稱作 Mach，其作為一個微內(nèi)核置媳，僅提供了諸如處理器調(diào)度于樟、IPC (進程間通信)等非常少量的基礎(chǔ)服務(wù)。
BSD 層可以看作圍繞 Mach 層的一個外環(huán)拇囊，其提供了諸如進程管理隔披、文件系統(tǒng)和網(wǎng)絡(luò)等功能。
IOKit 層是為設(shè)備驅(qū)動提供了一個面向?qū)ο?C++)的一個框架寂拆。
Mach 本身提供的 API 非常有限奢米，而且蘋果也不鼓勵使用 Mach 的 API，但是這些API非尘烙溃基礎(chǔ)鬓长，如果沒有這些API的話，其他任何工作都無法實施尝江。在 Mach 中涉波，所有的東西都是通過自己的對象實現(xiàn)的，進程、線程和虛擬內(nèi)存都被稱為”對象”啤覆。和其他架構(gòu)不同苍日， Mach 的對象間不能直接調(diào)用，只能通過消息傳遞的方式實現(xiàn)對象間的通信窗声∠嗍眩”消息”是 Mach 中最基礎(chǔ)的概念，消息在兩個端口 (port) 之間傳遞笨觅，這就是 Mach 的 IPC (進程間通信) 的核心拦耐。
Mach 的消息定義是在 頭文件的，很簡單：
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 消息實際上就是一個二進制數(shù)據(jù)包 (BLOB)见剩，其頭部定義了當(dāng)前端口 local_port 和目標(biāo)端口 remote_port杀糯，
發(fā)送和接受消息是通過同一個 API 進行的，其 option 標(biāo)記了消息傳遞的方向：
1
2
3
4
5
6
7
8
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);
為了實現(xiàn)消息的發(fā)送和接收苍苞，mach_msg() 函數(shù)實際上是調(diào)用了一個 Mach 陷阱 (trap)固翰，即函數(shù)mach_msg_trap()，陷阱這個概念在 Mach 中等同于系統(tǒng)調(diào)用羹呵。當(dāng)你在用戶態(tài)調(diào)用 mach_msg_trap() 時會觸發(fā)陷阱機制倦挂，切換到內(nèi)核態(tài)；內(nèi)核態(tài)中內(nèi)核實現(xiàn)的 mach_msg() 函數(shù)會完成實際的工作担巩，如下圖：
這些概念可以參考維基百科:System_call方援、Trap_(computing)。
RunLoop 的核心就是一個 mach_msg() (見上面代碼的第7步)涛癌，RunLoop 調(diào)用這個函數(shù)去接收消息犯戏，如果沒有別人發(fā)送 port 消息過來，內(nèi)核會將線程置于等待狀態(tài)拳话。例如你在模擬器里跑起一個 iOS 的 App先匪，然后在 App 靜止時點擊暫停，你會看到主線程調(diào)用棧是停留在 mach_msg_trap() 這個地方弃衍。
關(guān)于具體的如何利用 mach port 發(fā)送信息呀非，可以看看NSHipster 這一篇文章，或者這里的中文翻譯 镜盯。
關(guān)于Mach的歷史可以看看這篇很有趣的文章：Mac OS X 背后的故事（三）Mach 之父 Avie Tevanian岸裙。
蘋果用 RunLoop 實現(xiàn)的功能
首先我們可以看一下 App 啟動后 RunLoop 的狀態(tài)：
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
}
commonmodeitems={
// 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,
nextfiredate=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),
}
}
}
可以看到，系統(tǒng)默認注冊了5個Mode:
1. kCFRunLoopDefaultMode: App的默認 Mode速缆，通常主線程是在這個 Mode 下運行的降允。
2. UITrackingRunLoopMode: 界面跟蹤 Mode，用于 ScrollView 追蹤觸摸滑動艺糜，保證界面滑動時不受其他 Mode 影響剧董。
3. UIInitializationRunLoopMode: 在剛啟動 App 時第進入的第一個 Mode幢尚，啟動完成后就不再使用。
4: GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內(nèi)部 Mode翅楼，通常用不到尉剩。
5: kCFRunLoopCommonModes: 這是一個占位的 Mode，沒有實際作用毅臊。
你可以在這里看到更多的蘋果內(nèi)部的 Mode理茎，但那些 Mode 在開發(fā)中就很難遇到了。
當(dāng) RunLoop 進行回調(diào)時褂微，一般都是通過一個很長的函數(shù)調(diào)用出去 (call out), 當(dāng)你在你的代碼中下斷點調(diào)試時，通常能在調(diào)用棧上看到這些函數(shù)园爷。下面是這幾個函數(shù)的整理版本宠蚂，如果你在調(diào)用棧中看到這些長函數(shù)名，在這里查找一下就能定位到具體的調(diào)用地點了：
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會創(chuàng)建AutoreleasePool: _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
do{
/// 2. 通知 Observers: 即將觸發(fā) Timer 回調(diào)求厕。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: 即將觸發(fā) Source (非基于port的,Source0) 回調(diào)。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 4. 觸發(fā) Source0 (非基于port的) 回調(diào)扰楼。
__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喚醒的弦赖，回調(diào)Timer
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);
/// 9. 如果是被dispatch喚醒的项栏，執(zhí)行所有調(diào)用 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，其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()币厕。
第一個 Observer 監(jiān)視的事件是 Entry(即將進入Loop)列另，其回調(diào)內(nèi)會調(diào)用 _objc_autoreleasePoolPush() 創(chuàng)建自動釋放池。其 order 是-2147483647旦装，優(yōu)先級最高页衙，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前。
第二個 Observer 監(jiān)視了兩個事件： BeforeWaiting(準(zhǔn)備進入休眠) 時調(diào)用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池并創(chuàng)建新池阴绢；Exit(即將退出Loop) 時調(diào)用 _objc_autoreleasePoolPop() 來釋放自動釋放池店乐。這個 Observer 的 order 是 2147483647，優(yōu)先級最低呻袭，保證其釋放池子發(fā)生在其他所有回調(diào)之后响巢。
在主線程執(zhí)行的代碼，通常是寫在諸如事件回調(diào)棒妨、Timer回調(diào)內(nèi)的踪古。這些回調(diào)會被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著含长，所以不會出現(xiàn)內(nèi)存泄漏，開發(fā)者也不必顯示創(chuàng)建 Pool 了伏穆。
事件響應(yīng)
蘋果注冊了一個 Source1 (基于 mach port 的) 用來接收系統(tǒng)事件拘泞，其回調(diào)函數(shù)為 __IOHIDEventSystemClientQueueCallback()。
當(dāng)一個硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后枕扫，首先由 IOKit.framework 生成一個 IOHIDEvent 事件并由 SpringBoard 接收陪腌。這個過程的詳細情況可以參考這里。SpringBoard 只接收按鍵(鎖屏/靜音等)烟瞧，觸摸诗鸭，加速，接近傳感器等幾種 Event参滴，隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進程强岸。隨后蘋果注冊的那個 Source1 就會觸發(fā)回調(diào)，并調(diào)用 _UIApplicationHandleEventQueue() 進行應(yīng)用內(nèi)部的分發(fā)砾赔。
_UIApplicationHandleEventQueue() 會把 IOHIDEvent 處理并包裝成 UIEvent 進行處理或分發(fā)蝌箍，其中包括識別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等。通常事件比如 UIButton 點擊暴心、touchesBegin/Move/End/Cancel 事件都是在這個回調(diào)中完成的妓盲。
手勢識別
當(dāng)上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會調(diào)用 Cancel 將當(dāng)前的 touchesBegin/Move/End 系列回調(diào)打斷专普。隨后系統(tǒng)將對應(yīng)的 UIGestureRecognizer 標(biāo)記為待處理悯衬。
蘋果注冊了一個 Observer 監(jiān)測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()檀夹，其內(nèi)部會獲取所有剛被標(biāo)記為待處理的 GestureRecognizer甚亭，并執(zhí)行GestureRecognizer的回調(diào)。
當(dāng)有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時击胜，這個回調(diào)都會進行相應(yīng)處理亏狰。
界面更新
當(dāng)在操作 UI 時，比如改變了 Frame偶摔、更新了 UIView/CALayer 的層次時暇唾，或者手動調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，這個 UIView/CALayer 就被標(biāo)記為待處理辰斋，并被提交到一個全局的容器去策州。
蘋果注冊了一個 Observer 監(jiān)聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調(diào)去執(zhí)行一個很長的函數(shù)：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()宫仗。這個函數(shù)里會遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實際的繪制和調(diào)整够挂，并更新 UI 界面。
這個函數(shù)內(nèi)部的調(diào)用棧大概是這樣的：
1
2
3
4
5
6
7
8
9
10
11
_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 會為其重復(fù)的時間點注冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點办悟。RunLoop為了節(jié)省資源尘奏，并不會在非常準(zhǔn)確的時間點回調(diào)這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)病蛉，標(biāo)示了當(dāng)時間點到后炫加，容許有多少最大誤差。
如果某個時間點被錯過了铺然，例如執(zhí)行了一個很長的任務(wù)俗孝，則那個時間點的回調(diào)也會跳過去，不會延后執(zhí)行魄健。就比如等公交赋铝，如果 10:10 時我忙著玩手機錯過了那個點的公交，那我只能等 10:20 這一趟了诀艰。
CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復(fù)雜柬甥，和 NSTimer 并不一樣饮六，其內(nèi)部實際是操作了一個 Source）其垄。如果在兩次屏幕刷新之間執(zhí)行了一個長任務(wù)，那其中就會有一幀被跳過去（和 NSTimer 相似）卤橄，造成界面卡頓的感覺绿满。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺窟扑。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題喇颁，其內(nèi)部也用到了 RunLoop，這個稍后我會再單獨寫一頁博客來分析嚎货。
PerformSelecter
當(dāng)調(diào)用 NSObject 的 performSelecter:afterDelay: 后橘霎，實際上其內(nèi)部會創(chuàng)建一個 Timer 并添加到當(dāng)前線程的 RunLoop 中。所以如果當(dāng)前線程沒有 RunLoop殖属，則這個方法會失效姐叁。
當(dāng)調(diào)用 performSelector:onThread: 時，實際上其會創(chuàng)建一個 Timer 加到對應(yīng)的線程去洗显，同樣的外潜，如果對應(yīng)線程沒有 RunLoop 該方法也會失效。
關(guān)于GCD
實際上 RunLoop 底層也會用到 GCD 的東西挠唆，比如 RunLoop 是用 dispatch_source_t 實現(xiàn)的 Timer（評論中有人提醒处窥，NSTimer 是用了 XNU 內(nèi)核的 mk_timer，我也仔細調(diào)試了一下玄组，發(fā)現(xiàn) NSTimer 確實是由 mk_timer 驅(qū)動滔驾，而非 GCD 驅(qū)動的）谒麦。但同時 GCD 提供的某些接口也用到了 RunLoop， 例如 dispatch_async()嵌灰。
當(dāng)調(diào)用 dispatch_async(dispatch_get_main_queue(), block) 時弄匕，libDispatch 會向主線程的 RunLoop 發(fā)送消息，RunLoop會被喚醒沽瞭，并從消息中取得這個 block迁匠，并在回調(diào) __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 里執(zhí)行這個 block。但這個邏輯僅限于 dispatch 到主線程驹溃，dispatch 到其他線程仍然是由 libDispatch 處理的城丧。
關(guān)于網(wǎng)絡(luò)請求
iOS 中，關(guān)于網(wǎng)絡(luò)請求的接口自下至上有如下幾層:
1
2
3
4
CFSocket
CFNetwork->ASIHttpRequest
NSURLConnection->AFNetworking
NSURLSession->AFNetworking2,Alamofire
? CFSocket 是最底層的接口豌鹤，只負責(zé) socket 通信亡哄。
? CFNetwork 是基于 CFSocket 等接口的上層封裝，ASIHttpRequest 工作于這一層布疙。
? NSURLConnection 是基于 CFNetwork 的更高層的封裝蚊惯，提供面向?qū)ο蟮慕涌冢珹FNetworking 工作于這一層灵临。
? NSURLSession 是 iOS7 中新增的接口截型，表面上是和 NSURLConnection 并列的，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)儒溉，AFNetworking2 和 Alamofire 工作于這一層宦焦。
下面主要介紹下 NSURLConnection 的工作過程。
通常使用 NSURLConnection 時顿涣，你會傳入一個 Delegate波闹，當(dāng)調(diào)用了 [connection start] 后，這個 Delegate 就會不停收到事件回調(diào)涛碑。實際上精堕，start 這個函數(shù)的內(nèi)部會會獲取 CurrentRunLoop，然后在其中的 DefaultMode 添加了4個 Source0 (即需要手動觸發(fā)的Source)蒲障。CFMultiplexerSource 是負責(zé)各種 Delegate 回調(diào)的歹篓，CFHTTPCookieStorage 是處理各種 Cookie 的。
當(dāng)開始網(wǎng)絡(luò)傳輸時晌涕，我們可以看到 NSURLConnection 創(chuàng)建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private滋捶。其中 CFSocket 線程是處理底層 socket 連接的。NSURLConnectionLoader 這個線程內(nèi)部會使用 RunLoop 來接收底層 socket 的事件余黎，并通過之前添加的 Source0 通知到上層的 Delegate重窟。
NSURLConnectionLoader 中的 RunLoop 通過一些基于 mach port 的 Source 接收來自底層 CFSocket 的通知。當(dāng)收到通知后惧财，其會在合適的時機向 CFMultiplexerSource 等 Source0 發(fā)送通知巡扇，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知扭仁。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執(zhí)行實際的回調(diào)。
RunLoop 的實際應(yīng)用舉例
AFNetworking
AFURLConnectionOperation這個類是基于 NSURLConnection 構(gòu)建的厅翔，其希望能在后臺線程接收 Delegate 回調(diào)乖坠。為此 AFNetworking 單獨創(chuàng)建了一個線程，并在這個線程中啟動了一個 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_toncePredicate;
dispatch_once(&oncePredicate,^{
_networkRequestThread=[[NSThreadalloc]initWithTarget:selfselector:@selector(networkRequestThreadEntryPoint:)object:nil];
[_networkRequestThreadstart];
});
return_networkRequestThread;
}
RunLoop 啟動前內(nèi)部必須要有至少一個 Timer/Observer/Source刀闷，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個新的 NSMachPort 添加進去了熊泵。通常情況下，調(diào)用者需要持有這個 NSMachPort (mach_port) 并在外部線程通過這個 port 發(fā)送消息到 loop 內(nèi)甸昏；但此處添加 port 只是為了讓 RunLoop 不至于退出顽分，并沒有用于實際的發(fā)送消息。
1
2
3
4
5
6
7
8
9
10
-(void)start{
[self.locklock];
if([selfisCancelled]){
[selfperformSelector:@selector(cancelConnection)onThread:[[selfclass]networkRequestThread]withObject:nilwaitUntilDone:NOmodes:[self.runLoopModesallObjects]];
}elseif([selfisReady]){
self.state=AFOperationExecutingState;
[selfperformSelector:@selector(operationDidStart)onThread:[[selfclass]networkRequestThread]withObject:nilwaitUntilDone:NOmodes:[self.runLoopModesallObjects]];
}
[self.lockunlock];
}
當(dāng)需要這個后臺線程執(zhí)行任務(wù)時施蜜，AFNetworking 通過調(diào)用 [NSObject performSelector:onThread:..] 將這個任務(wù)扔到了后臺線程的 RunLoop 中卒蘸。
AsyncDisplayKit
AsyncDisplayKit是 Facebook 推出的用于保持界面流暢性的框架，其原理大致如下：
UI 線程中一旦出現(xiàn)繁重的任務(wù)就會導(dǎo)致界面卡頓翻默，這類任務(wù)通常分為3類：排版缸沃，繪制，UI對象操作修械。
排版通常包括計算視圖大小趾牧、計算文本高度、重新計算子式圖的排版等操作祠肥。
繪制一般有文本繪制 (例如 CoreText)武氓、圖片繪制 (例如預(yù)先解壓)梯皿、元素繪制 (Quartz)等操作仇箱。
UI對象操作通常包括 UIView/CALayer 等 UI 對象的創(chuàng)建、設(shè)置屬性和銷毀东羹。
其中前兩類操作可以通過各種方法扔到后臺線程執(zhí)行剂桥，而最后一類操作只能在主線程完成拿诸，并且有時后面的操作需要依賴前面操作的結(jié)果 （例如TextView創(chuàng)建時可能需要提前計算出文本的大锌覆Α）。ASDK 所做的捣染，就是盡量將能放入后臺的任務(wù)放入后臺冤议，不能的則盡量推遲 (例如視圖的創(chuàng)建斟薇、屬性的調(diào)整)。
為此恕酸，ASDK 創(chuàng)建了一個名為 ASDisplayNode 的對象堪滨，并在內(nèi)部封裝了 UIView/CALayer，它具有和 UIView/CALayer 相似的屬性蕊温，例如 frame袱箱、backgroundColor等遏乔。所有這些屬性都可以在后臺線程更改，開發(fā)者可以只通過 Node 來操作其內(nèi)部的 UIView/CALayer发笔，這樣就可以將排版和繪制放入了后臺線程盟萨。但是無論怎么操作，這些屬性總需要在某個時刻同步到主線程的 UIView/CALayer 去了讨。
ASDK 仿照 QuartzCore/UIKit 框架的模式捻激，實現(xiàn)了一套類似的界面更新的機制：即在主線程的 RunLoop 中添加一個 Observer，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件前计，在收到回調(diào)時铺罢，遍歷所有之前放入隊列的待處理的任務(wù)，然后一一執(zhí)行残炮。
具體的代碼可以看這里：_ASAsyncTransactionGroup韭赘。
最后
好長時間沒寫博客了喵～前幾天給博客搬了個家，從越來越慢的 AWS 遷到了 Linode势就，然后很認真的換了一套新的博客主題泉瞻，排版看著還說得過去吧～ ???
