轉自bireme，原地址：https://blog.ibireme.com/2015/05/18/runloop/
RunLoop 是 iOS 和 OSX 開發(fā)中非车嫉郏基礎的一個概念虚缎，這篇文章將從 CFRunLoop 的源碼入手，介紹 RunLoop 的概念以及底層實現(xiàn)原理钓株。之后會介紹一下在 iOS 中实牡，蘋果是如何利用 RunLoop 實現(xiàn)自動釋放池、延遲回調轴合、觸摸事件创坞、屏幕刷新等功能的。
RunLoop 的概念
一般來講受葛，一個線程一次只能執(zhí)行一個任務题涨，執(zhí)行完成后線程就會退出。如果我們需要一個機制总滩，讓線程能隨時處理事件但并不退出纲堵，通常的代碼邏輯是這樣的：
function loop() {
????initialize();
????do {
????????var message = 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)這種模型的關鍵點在于：如何管理事件/消息茂附，如何讓線程在沒有處理消息時休眠以避免資源占用、在有消息到來時立刻被喚醒督弓。
所以营曼，RunLoop 實際上就是一個對象，這個對象管理了其需要處理的事件和消息愚隧，并提供了一個入口函數(shù)來執(zhí)行上面 Event Loop 的邏輯蒂阱。線程執(zhí)行了這個函數(shù)后，就會一直處于這個函數(shù)內部 “接受消息->等待->處理” 的循環(huán)中狂塘，直到這個循環(huán)結束（比如傳入 quit 的消息）蒜危，函數(shù)返回。
OSX/iOS 系統(tǒng)中睹耐，提供了兩個這樣的對象：NSRunLoop 和 CFRunLoopRef辐赞。
CFRunLoopRef 是在 CoreFoundation 框架內的，它提供了純 C 函數(shù)的 API硝训，所有這些 API 都是線程安全的响委。
NSRunLoop 是基于 CFRunLoopRef 的封裝新思，提供了面向對象的 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 與線程的關系
首先，iOS 開發(fā)中能遇到兩個線程對象: pthread_t 和 NSThread肪虎。過去蘋果有份文檔標明了 NSThread 只是 pthread_t 的封裝劣砍，但那份文檔已經(jīng)失效了，現(xiàn)在它們也有可能都是直接包裝自最底層的 mach thread扇救。蘋果并沒有提供這兩個對象相互轉換的接口刑枝，但不管怎么樣，可以肯定的是 pthread_t 和 NSThread 是一一對應的迅腔。比如装畅，你可以通過 pthread_main_thread_np() 或 [NSThread mainThread] 來獲取主線程；也可以通過 pthread_self() 或 [NSThread currentThread] 來獲取當前線程沧烈。CFRunLoop 是基于 pthread 來管理的洁灵。
蘋果不允許直接創(chuàng)建 RunLoop，它只提供了兩個自動獲取的函數(shù)：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()掺出。 這兩個函數(shù)內部的邏輯大概是下面這樣:
/// 全局的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，并先為主線程創(chuàng)建一個 RunLoop闲礼。
????????loopsDic = CFDictionaryCreateMutable();
????????CFRunLoopRef mainLoop = _CFRunLoopCreate();
????????CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
????}
????/// 直接從 Dictionary 里獲取牍汹。
????CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));
????if (!loop) {
????????/// 取不到時，創(chuàng)建一個
????????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 之間是一一對應的露该，其關系是保存在一個全局的 Dictionary 里。線程剛創(chuàng)建時并沒有 RunLoop第煮，如果你不主動獲取解幼，那它一直都不會有抑党。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時，RunLoop 的銷毀是發(fā)生在線程結束時撵摆。你只能在一個線程的內部獲取其 RunLoop（主線程除外）底靠。
RunLoop 對外的接口
在 CoreFoundation 里面關于 RunLoop 有5個類:
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef
其中 CFRunLoopModeRef 類并沒有對外暴露，只是通過 CFRunLoopRef 的接口進行了封裝特铝。他們的關系如下:
一個 RunLoop 包含若干個 Mode暑中，每個 Mode 又包含若干個 Source/Timer/Observer。每次調用 RunLoop 的主函數(shù)時鲫剿，只能指定其中一個 Mode鳄逾，這個Mode被稱作 CurrentMode。如果需要切換 Mode牵素，只能退出 Loop，再重新指定一個 Mode 進入澄者。這樣做主要是為了分隔開不同組的 Source/Timer/Observer笆呆，讓其互不影響。
CFRunLoopSourceRef?是事件產(chǎn)生的地方粱挡。Source有兩個版本：Source0 和 Source1赠幕。
? Source0 只包含了一個回調（函數(shù)指針），它并不能主動觸發(fā)事件询筏。使用時榕堰，你需要先調用 CFRunLoopSourceSignal(source)，將這個 Source 標記為待處理嫌套，然后手動調用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop逆屡，讓其處理這個事件。
? Source1 包含了一個 mach_port 和一個回調（函數(shù)指針）踱讨，被用于通過內核和其他線程相互發(fā)送消息魏蔗。這種 Source 能主動喚醒 RunLoop 的線程，其原理在下面會講到痹筛。
CFRunLoopTimerRef?是基于時間的觸發(fā)器莺治，它和 NSTimer 是toll-free bridged 的，可以混用帚稠。其包含一個時間長度和一個回調（函數(shù)指針）谣旁。當其加入到 RunLoop 時，RunLoop會注冊對應的時間點滋早，當時間點到時榄审，RunLoop會被喚醒以執(zhí)行那個回調。
CFRunLoopObserverRef?是觀察者杆麸，每個 Observer 都包含了一個回調（函數(shù)指針）瘟判，當 RunLoop 的狀態(tài)發(fā)生變化時怨绣，觀察者就能通過回調接受到這個變化】交瘢可以觀測的時間點有以下幾個：
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 被統(tǒng)稱為?mode item篮撑，一個 item 可以被同時加入多個 mode。但一個 item 被重復加入同一個 mode 時是不會有效果的匆瓜。如果一個 mode 中一個 item 都沒有赢笨，則 RunLoop 會直接退出，不進入循環(huán)驮吱。
RunLoop 的 Mode
CFRunLoopMode 和 CFRunLoop 的結構大致如下：
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 的內容發(fā)生變化時，RunLoop 都會自動將 _commonModeItems 里的 Source/Observer/Timer 同步到具有 “Common” 標記的所有Mode里左冬。
應用場景舉例：主線程的 RunLoop 里有兩個預置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode桐筏。這兩個 Mode 都已經(jīng)被標記為”Common”屬性。DefaultMode 是 App 平時所處的狀態(tài)拇砰，TrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態(tài)梅忌。當你創(chuàng)建一個 Timer 并加到 DefaultMode 時，Timer 會得到重復回調除破，但此時滑動一個TableView時牧氮，RunLoop 會將 mode 切換為 TrackingRunLoopMode，這時 Timer 就不會被回調瑰枫，并且也不會影響到滑動操作踱葛。
有時你需要一個 Timer，在兩個 Mode 中都能得到回調光坝，一種辦法就是將這個 Timer 分別加入這兩個 Mode尸诽。還有一種方式，就是將 Timer 加入到頂層的 RunLoop 的 “commonModeItems” 中盯另⊙纺保”commonModeItems” 被 RunLoop 自動更新到所有具有”Common”屬性的 Mode 里去。
CFRunLoop對外暴露的管理 Mode 接口只有下面2個:
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);
Mode 暴露的管理 mode item 的接口有下面幾個：
CFRunLoopAddSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopAddObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopAddTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
CFRunLoopRemoveSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopRemoveObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopRemoveTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
你只能通過 mode name 來操作內部的 mode土铺，當你傳入一個新的 mode name 但 RunLoop 內部沒有對應 mode 時胶滋，RunLoop會自動幫你創(chuàng)建對應的 CFRunLoopModeRef。對于一個 RunLoop 來說悲敷，其內部的 mode 只能增加不能刪除究恤。
蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode，你可以用這兩個 Mode Name 來操作其對應的 Mode后德。
同時蘋果還提供了一個操作 Common 標記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)部宿，你可以用這個字符串來操作 Common Items，或標記一個 Mode 為 “Common”。使用時注意區(qū)分這個字符串和其他 mode name理张。
RunLoop 的內部邏輯
根據(jù)蘋果在文檔里的說明赫蛇，RunLoop 內部的邏輯大致如下:
其內部代碼整理如下 （太長了不想看可以直接跳過去，后面會有說明）：
/// 用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的實現(xiàn)
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
????/// 首先根據(jù)modeName找到對應mode
????CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
????/// 如果mode里沒有source/timer/observer, 直接返回悟耘。
????if (__CFRunLoopModeIsEmpty(currentMode)) return;
????/// 1. 通知 Observers: RunLoop 即將進入 loop。
????__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);
????/// 內部函數(shù)织狐，進入loop
????__CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {
????????Boolean sourceHandledThisLoop = NO;
????????int retVal = 0;
????????do {
????????????/// 2. 通知 Observers: RunLoop 即將觸發(fā) Timer 回調暂幼。
????????????__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
????????????/// 3. 通知 Observers: RunLoop 即將觸發(fā) Source0 (非port) 回調。
????????????__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
????????????/// 執(zhí)行被加入的block
????????????__CFRunLoopDoBlocks(runloop, currentMode);
????????????/// 4. RunLoop 觸發(fā) Source0 (非port) 回調移迫。
????????????sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
????????????/// 執(zhí)行被加入的block
????????????__CFRunLoopDoBlocks(runloop, currentMode);
????????????/// 5. 如果有 Source1 (基于port) 處于 ready 狀態(tài)旺嬉，直接處理這個 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 到時間了设易，觸發(fā)這個Timer的回調逗柴。
????????????if (msg_is_timer) {
????????????????__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
????????????}
????????????/// 9.2 如果有dispatch到main_queue的block蛹头，執(zhí)行block。
????????????else if (msg_is_dispatch) {
????????????????__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
????????????}
????????????/// 9.3 如果一個 Source1 (基于port) 發(fā)出事件了戏溺，處理這個事件
????????????else {
????????????????CFRunLoopSourceRef source1 = __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;
????????????} else if (timeout) {
????????????????/// 超出傳入?yún)?shù)標記的超時時間了
????????????????retVal = kCFRunLoopRunTimedOut;
????????????} else if (__CFRunLoopIsStopped(runloop)) {
????????????????/// 被外部調用者強制停止了
????????????????retVal = kCFRunLoopRunStopped;
????????????} else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
????????????????/// source/timer/observer一個都沒有了
????????????????retVal = kCFRunLoopRunFinished;
????????????}
????????????/// 如果沒超時，mode里沒空旷祸，loop也沒被停止耕拷，那繼續(xù)loop。
????????} while (retVal == 0);
????}
????/// 10. 通知 Observers: RunLoop 即將退出托享。
????__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}
可以看到骚烧，實際上 RunLoop 就是這樣一個函數(shù)，其內部是一個 do-while 循環(huán)闰围。當你調用 CFRunLoopRun() 時赃绊，線程就會一直停留在這個循環(huán)里；直到超時或被手動停止羡榴，該函數(shù)才會返回碧查。
RunLoop 的底層實現(xiàn)
從上面代碼可以看到，RunLoop 的核心是基于 mach port 的，其進入休眠時調用的函數(shù)是 mach_msg()忠售。為了解釋這個邏輯传惠，下面稍微介紹一下 OSX/iOS 的系統(tǒng)架構。
蘋果官方將整個系統(tǒng)大致劃分為上述4個層次：
應用層包括用戶能接觸到的圖形應用稻扬，例如 Spotlight卦方、Aqua、SpringBoard 等腐螟。
應用框架層即開發(fā)人員接觸到的 Cocoa 等框架愿汰。
核心框架層包括各種核心框架、OpenGL 等內容乐纸。
Darwin 即操作系統(tǒng)的核心衬廷，包括系統(tǒng)內核、驅動汽绢、Shell 等內容吗跋，這一層是開源的，其所有源碼都可以在?opensource.apple.com?里找到宁昭。
我們在深入看一下 Darwin 這個核心的架構：
其中跌宛，在硬件層上面的三個組成部分：Mach、BSD积仗、IOKit (還包括一些上面沒標注的內容)疆拘，共同組成了 XNU 內核。
XNU 內核的內環(huán)被稱作 Mach寂曹，其作為一個微內核哎迄，僅提供了諸如處理器調度、IPC (進程間通信)等非常少量的基礎服務隆圆。
BSD 層可以看作圍繞 Mach 層的一個外環(huán)漱挚，其提供了諸如進程管理、文件系統(tǒng)和網(wǎng)絡等功能。
IOKit 層是為設備驅動提供了一個面向對象(C++)的一個框架。
Mach 本身提供的 API 非常有限稽寒，而且蘋果也不鼓勵使用 Mach 的 API，但是這些API非嘲谆基礎，如果沒有這些API的話贩耐，其他任何工作都無法實施弧腥。在 Mach 中，所有的東西都是通過自己的對象實現(xiàn)的憔杨，進程鸟赫、線程和虛擬內存都被稱為”對象”。和其他架構不同， Mach 的對象間不能直接調用抛蚤，只能通過消息傳遞的方式實現(xiàn)對象間的通信台谢。”消息”是 Mach 中最基礎的概念岁经，消息在兩個端口 (port) 之間傳遞朋沮，這就是 Mach 的 IPC (進程間通信) 的核心。
Mach 的消息定義是在 <mach/message.h> 頭文件的缀壤，很簡單：
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 消息實際上就是一個二進制數(shù)據(jù)包 (BLOB)樊拓，其頭部定義了當前端口 local_port 和目標端口 remote_port，
發(fā)送和接受消息是通過同一個 API 進行的塘慕，其 option 標記了消息傳遞的方向：
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);
為了實現(xiàn)消息的發(fā)送和接收筋夏，mach_msg() 函數(shù)實際上是調用了一個 Mach 陷阱 (trap)，即函數(shù)mach_msg_trap()图呢，陷阱這個概念在 Mach 中等同于系統(tǒng)調用条篷。當你在用戶態(tài)調用 mach_msg_trap() 時會觸發(fā)陷阱機制，切換到內核態(tài)蛤织；內核態(tài)中內核實現(xiàn)的 mach_msg() 函數(shù)會完成實際的工作赴叹，如下圖：
這些概念可以參考維基百科:System_call、Trap_(computing)指蚜。
RunLoop 的核心就是一個 mach_msg() (見上面代碼的第7步)乞巧，RunLoop 調用這個函數(shù)去接收消息，如果沒有別人發(fā)送 port 消息過來摊鸡，內核會將線程置于等待狀態(tài)绽媒。例如你在模擬器里跑起一個 iOS 的 App，然后在 App 靜止時點擊暫停柱宦，你會看到主線程調用棧是停留在 mach_msg_trap() 這個地方些椒。
關于具體的如何利用 mach port 發(fā)送信息播瞳，可以看看?NSHipster 這一篇文章掸刊，或者這里的中文翻譯 。
關于Mach的歷史可以看看這篇很有趣的文章：Mac OS X 背后的故事（三）Mach 之父 Avie Tevanian赢乓。
蘋果用 RunLoop 實現(xiàn)的功能
首先我們可以看一下 App 啟動后 RunLoop 的狀態(tài)：
CFRunLoop {
????current mode = kCFRunLoopDefaultMode
????common modes = {
????????UITrackingRunLoopMode
????????kCFRunLoopDefaultMode
????}
????common mode 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,
????????????next fire 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),
????????}
????}
}
可以看到忧侧，系統(tǒng)默認注冊了5個Mode:
1. kCFRunLoopDefaultMode: App的默認 Mode，通常主線程是在這個 Mode 下運行的牌芋。
2. UITrackingRunLoopMode: 界面跟蹤 Mode蚓炬，用于 ScrollView 追蹤觸摸滑動，保證界面滑動時不受其他 Mode 影響躺屁。
3. UIInitializationRunLoopMode: 在剛啟動 App 時第進入的第一個 Mode肯夏，啟動完成后就不再使用。
4: GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內部 Mode，通常用不到驯击。
5: kCFRunLoopCommonModes: 這是一個占位的 Mode烁兰，沒有實際作用。
你可以在這里看到更多的蘋果內部的 Mode徊都，但那些 Mode 在開發(fā)中就很難遇到了沪斟。
當 RunLoop 進行回調時，一般都是通過一個很長的函數(shù)調用出去 (call out), 當你在你的代碼中下斷點調試時暇矫，通常能在調用棧上看到這些函數(shù)主之。下面是這幾個函數(shù)的整理版本，如果你在調用棧中看到這些長函數(shù)名李根，在這里查找一下就能定位到具體的調用地點了：
{
????/// 1. 通知Observers槽奕，即將進入RunLoop
????/// 此處有Observer會創(chuàng)建AutoreleasePool: _objc_autoreleasePoolPush();
????__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
????do {
????????/// 2. 通知 Observers: 即將觸發(fā) Timer 回調。
????????__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
????????/// 3. 通知 Observers: 即將觸發(fā) Source (非基于port的,Source0) 回調房轿。
????????__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
????????__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
????????/// 4. 觸發(fā) 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喚醒的，執(zhí)行所有調用 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 監(jiān)視的事件是 Entry(即將進入Loop)，其回調內會調用 _objc_autoreleasePoolPush() 創(chuàng)建自動釋放池粒蜈。其 order 是-2147483647顺献，優(yōu)先級最高，保證創(chuàng)建釋放池發(fā)生在其他所有回調之前枯怖。
第二個 Observer 監(jiān)視了兩個事件： BeforeWaiting(準備進入休眠) 時調用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池并創(chuàng)建新池注整；Exit(即將退出Loop) 時調用 _objc_autoreleasePoolPop() 來釋放自動釋放池。這個 Observer 的 order 是 2147483647度硝，優(yōu)先級最低肿轨，保證其釋放池子發(fā)生在其他所有回調之后。
在主線程執(zhí)行的代碼蕊程，通常是寫在諸如事件回調椒袍、Timer回調內的。這些回調會被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著藻茂，所以不會出現(xiàn)內存泄漏驹暑，開發(fā)者也不必顯示創(chuàng)建 Pool 了玫恳。
事件響應
蘋果注冊了一個 Source1 (基于 mach port 的) 用來接收系統(tǒng)事件，其回調函數(shù)為 __IOHIDEventSystemClientQueueCallback()优俘。
當一個硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后纽窟，首先由 IOKit.framework 生成一個 IOHIDEvent 事件并由 SpringBoard 接收。這個過程的詳細情況可以參考這里兼吓。SpringBoard 只接收按鍵(鎖屏/靜音等)臂港，觸摸，加速视搏，接近傳感器等幾種 Event审孽，隨后用 mach port 轉發(fā)給需要的App進程。隨后蘋果注冊的那個 Source1 就會觸發(fā)回調浑娜，并調用 _UIApplicationHandleEventQueue() 進行應用內部的分發(fā)佑力。
_UIApplicationHandleEventQueue() 會把 IOHIDEvent 處理并包裝成 UIEvent 進行處理或分發(fā)，其中包括識別 UIGesture/處理屏幕旋轉/發(fā)送給 UIWindow 等筋遭。通常事件比如 UIButton 點擊打颤、touchesBegin/Move/End/Cancel 事件都是在這個回調中完成的。
手勢識別
當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時漓滔，其首先會調用 Cancel 將當前的 touchesBegin/Move/End 系列回調打斷编饺。隨后系統(tǒng)將對應的 UIGestureRecognizer 標記為待處理。
蘋果注冊了一個 Observer 監(jiān)測 BeforeWaiting (Loop即將進入休眠) 事件响驴，這個Observer的回調函數(shù)是 _UIGestureRecognizerUpdateObserver()透且，其內部會獲取所有剛被標記為待處理的 GestureRecognizer，并執(zhí)行GestureRecognizer的回調豁鲤。
當有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時秽誊，這個回調都會進行相應處理。
界面更新
當在操作 UI 時琳骡，比如改變了 Frame锅论、更新了 UIView/CALayer 的層次時，或者手動調用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后楣号，這個 UIView/CALayer 就被標記為待處理最易，并被提交到一個全局的容器去。
蘋果注冊了一個 Observer 監(jiān)聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件竖席，回調去執(zhí)行一個很長的函數(shù)：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()耘纱。這個函數(shù)里會遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實際的繪制和調整敬肚，并更新 UI 界面毕荐。
這個函數(shù)內部的調用棧大概是這樣的：
_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();
????????????????????????[CALayer layoutSublayers];
????????????????????????????[UIView layoutSubviews];
????????????????????CA::Layer::display_if_needed();
????????????????????????[CALayer display];
????????????????????????????[UIView drawRect];
定時器
NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的艳馒。一個 NSTimer 注冊到 RunLoop 后憎亚，RunLoop 會為其重復的時間點注冊好事件员寇。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節(jié)省資源第美，并不會在非常準確的時間點回調這個Timer蝶锋。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到后什往，容許有多少最大誤差扳缕。
如果某個時間點被錯過了，例如執(zhí)行了一個很長的任務别威，則那個時間點的回調也會跳過去躯舔，不會延后執(zhí)行。就比如等公交省古，如果 10:10 時我忙著玩手機錯過了那個點的公交粥庄，那我只能等 10:20 這一趟了。
CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復雜豺妓，和 NSTimer 并不一樣惜互，其內部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執(zhí)行了一個長任務琳拭，那其中就會有一幀被跳過去（和 NSTimer 相似）训堆，造成界面卡頓的感覺。在快速滑動TableView時白嘁，即使一幀的卡頓也會讓用戶有所察覺蔫慧。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題，其內部也用到了 RunLoop权薯，這個稍后我會再單獨寫一頁博客來分析姑躲。
PerformSelecter
當調用 NSObject 的 performSelecter:afterDelay: 后，實際上其內部會創(chuàng)建一個 Timer 并添加到當前線程的 RunLoop 中盟蚣。所以如果當前線程沒有 RunLoop黍析，則這個方法會失效。
當調用 performSelector:onThread: 時屎开，實際上其會創(chuàng)建一個 Timer 加到對應的線程去阐枣，同樣的，如果對應線程沒有 RunLoop 該方法也會失效奄抽。
關于GCD
實際上 RunLoop 底層也會用到 GCD 的東西蔼两，比如 RunLoop 是用 dispatch_source_t 實現(xiàn)的 Timer（評論中有人提醒，NSTimer 是用了 XNU 內核的 mk_timer逞度，我也仔細調試了一下额划，發(fā)現(xiàn) NSTimer 確實是由 mk_timer 驅動，而非 GCD 驅動的）档泽。但同時 GCD 提供的某些接口也用到了 RunLoop俊戳， 例如 dispatch_async()揖赴。
當調用 dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主線程的 RunLoop 發(fā)送消息抑胎，RunLoop會被喚醒燥滑，并從消息中取得這個 block，并在回調 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 里執(zhí)行這個 block阿逃。但這個邏輯僅限于 dispatch 到主線程铭拧，dispatch 到其他線程仍然是由 libDispatch 處理的。
關于網(wǎng)絡請求
iOS 中恃锉，關于網(wǎng)絡請求的接口自下至上有如下幾層:
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 這個函數(shù)的內部會會獲取 CurrentRunLoop吭练，然后在其中的 DefaultMode 添加了4個 Source0 (即需要手動觸發(fā)的Source)诫龙。CFMultiplexerSource 是負責各種 Delegate 回調的，CFHTTPCookieStorage 是處理各種 Cookie 的鲫咽。
當開始網(wǎng)絡傳輸時签赃，我們可以看到 NSURLConnection 創(chuàng)建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的分尸。NSURLConnectionLoader 這個線程內部會使用 RunLoop 來接收底層 socket 的事件锦聊，并通過之前添加的 Source0 通知到上層的 Delegate。
NSURLConnectionLoader 中的 RunLoop 通過一些基于 mach port 的 Source 接收來自底層 CFSocket 的通知箩绍。當收到通知后孔庭，其會在合適的時機向 CFMultiplexerSource 等 Source0 發(fā)送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知伶选。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執(zhí)行實際的回調史飞。
RunLoop 的實際應用舉例
AFNetworking
AFURLConnectionOperation這個類是基于 NSURLConnection 構建的尖昏，其希望能在后臺線程接收 Delegate 回調仰税。為此 AFNetworking 單獨創(chuàng)建了一個線程构资，并在這個線程中啟動了一個 RunLoop：
+ (void)networkRequestThreadEntryPoint:(id)__unused object {
????@autoreleasepool {
????????[[NSThread currentThread] setName:@"AFNetworking"];
????????NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
????????[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
????????[runLoop run];
????}
}
+ (NSThread *)networkRequestThread {
????static NSThread *_networkRequestThread = nil;
????static dispatch_once_t oncePredicate;
????dispatch_once(&oncePredicate, ^{
????????_networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
????????[_networkRequestThread start];
????});
????return _networkRequestThread;
}
RunLoop 啟動前內部必須要有至少一個 Timer/Observer/Source，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個新的 NSMachPort 添加進去了陨簇。通常情況下吐绵，調用者需要持有這個 NSMachPort (mach_port) 并在外部線程通過這個 port 發(fā)送消息到 loop 內；但此處添加 port 只是為了讓 RunLoop 不至于退出河绽，并沒有用于實際的發(fā)送消息己单。
- (void)start {
????[self.lock lock];
????if ([self isCancelled]) {
????????[self performSelector:@selector(cancelConnection) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
????} else if ([self isReady]) {
????????self.state = AFOperationExecutingState;
????????[self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
????}
????[self.lock unlock];
}
當需要這個后臺線程執(zhí)行任務時，AFNetworking 通過調用 [NSObject performSelector:onThread:..] 將這個任務扔到了后臺線程的 RunLoop 中耙饰。
AsyncDisplayKit
AsyncDisplayKit?是 Facebook 推出的用于保持界面流暢性的框架纹笼，其原理大致如下：
UI 線程中一旦出現(xiàn)繁重的任務就會導致界面卡頓，這類任務通常分為3類：排版苟跪，繪制廷痘，UI對象操作。
排版通常包括計算視圖大小件已、計算文本高度笋额、重新計算子式圖的排版等操作。
繪制一般有文本繪制 (例如 CoreText)篷扩、圖片繪制 (例如預先解壓)兄猩、元素繪制 (Quartz)等操作。
UI對象操作通常包括 UIView/CALayer 等 UI 對象的創(chuàng)建鉴未、設置屬性和銷毀枢冤。
其中前兩類操作可以通過各種方法扔到后臺線程執(zhí)行，而最后一類操作只能在主線程完成铜秆，并且有時后面的操作需要依賴前面操作的結果 （例如TextView創(chuàng)建時可能需要提前計算出文本的大刑偷肌）。ASDK 所做的羽峰，就是盡量將能放入后臺的任務放入后臺趟咆，不能的則盡量推遲 (例如視圖的創(chuàng)建、屬性的調整)梅屉。
為此值纱，ASDK 創(chuàng)建了一個名為 ASDisplayNode 的對象，并在內部封裝了 UIView/CALayer坯汤，它具有和 UIView/CALayer 相似的屬性虐唠，例如 frame、backgroundColor等惰聂。所有這些屬性都可以在后臺線程更改疆偿，開發(fā)者可以只通過 Node 來操作其內部的 UIView/CALayer咱筛，這樣就可以將排版和繪制放入了后臺線程。但是無論怎么操作杆故，這些屬性總需要在某個時刻同步到主線程的 UIView/CALayer 去迅箩。
ASDK 仿照 QuartzCore/UIKit 框架的模式，實現(xiàn)了一套類似的界面更新的機制：即在主線程的 RunLoop 中添加一個 Observer处铛，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件饲趋，在收到回調時，遍歷所有之前放入隊列的待處理的任務撤蟆，然后一一執(zhí)行奕塑。
具體的代碼可以看這里：_ASAsyncTransactionGroup。
