注：本篇博客只在 ibireme 的 深入理解RunLoop 基礎(chǔ)上做了點(diǎn)方便自己復(fù)習(xí)該知識(shí)點(diǎn)的修改蚂且，能力有限纹安，如果有理解的不對(duì)的地方陆淀，還希望能幫忙指出考余。
首先了解一下程序、進(jìn)程和線程
程序本身只是指令轧苫、數(shù)據(jù)及其組織形式的描述楚堤，進(jìn)程才是程序（那些指令和數(shù)據(jù)）的真正運(yùn)行實(shí)例。而線程是操作系統(tǒng)能夠進(jìn)行運(yùn)算調(diào)度的最小單位含懊。它被包含在進(jìn)程之中身冬，是進(jìn)程中的實(shí)際運(yùn)作單位。一條線程指的是進(jìn)程中一個(gè)單一順序的控制流岔乔，一個(gè)進(jìn)程中可以并發(fā)多個(gè)線程酥筝，每條線程并行執(zhí)行不同的任務(wù)。
一般來說雏门，一個(gè)線程一次只能執(zhí)行一個(gè)任務(wù)嘿歌，執(zhí)行完成后線程就會(huì)退出。所以程序運(yùn)行的時(shí)候茁影，需要一個(gè)機(jī)制宙帝，讓線程能隨時(shí)處理事件但不退出。
以前寫游戲的時(shí)候就寫過這樣的東西募闲，通常是一個(gè) do while 循環(huán)步脓，讓程序一直運(yùn)轉(zhuǎn)，直到接收到退出信息浩螺。
而 RunLoop 就是讓線程在沒有處理消息時(shí)休眠以避免資源占用靴患，在有消息到來時(shí)立刻被喚醒。
線程和 RunLoop 之間是一一對(duì)應(yīng)的要出，其關(guān)系是保存在一個(gè)全局的 Dictionary 里蚁廓。線程剛創(chuàng)建時(shí)默認(rèn)是沒有 RunLoop，如果你不主動(dòng)獲取厨幻，那它一直都不會(huì)有相嵌。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時(shí)腿时，RunLoop 的銷毀是發(fā)生在線程結(jié)束時(shí)。你只能在一個(gè)線程的內(nèi)部獲取其 RunLoop（主線程除外）饭宾。
在 CoreFoundation 里面關(guān)于 RunLoop 有5個(gè)類:
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef
他們的層級(jí)關(guān)系為批糟，一個(gè) RunLoop 對(duì)象包含若干個(gè) Mode 對(duì)象，每個(gè) Mode 又包含若干個(gè) Source/Timer/Observer看铆，RunLoop 在運(yùn)作的時(shí)候徽鼎，一次只能運(yùn)作與一個(gè) Mode 之下，如果需要切換 Mode弹惦，需要退出 Loop 才能重新指定一個(gè) Mode否淤。這樣做主要是為了分隔開不同組的 Source/Timer/Observer，讓其互不影響棠隐。
而一個(gè) Source 對(duì)象是一個(gè)事件石抡，Source 有兩個(gè)版本：Source0 和 Source1，Source0 只包含一個(gè)函數(shù)指針助泽，并不能主動(dòng)觸發(fā)啰扛，需要將 Source0 標(biāo)記為待處理，在 RunLoop 運(yùn)轉(zhuǎn)的時(shí)候嗡贺，才會(huì)處理這個(gè)事件（如果 RunLoop 處于休眠狀態(tài)隐解，則不會(huì)被喚醒去處理），而 Source1 包含了一個(gè) mach_port 和一個(gè)函數(shù)指針诫睬，mach_port 是 iOS 系統(tǒng)提供的基于端口的輸入源煞茫，可用于線程或進(jìn)程間通訊。而 RunLoop 支持的輸入源類型中就包括基于端口的輸入源摄凡，可以做到對(duì) mach_port 端口源事件的監(jiān)聽溜嗜。所以監(jiān)聽到 source1 端口的消息時(shí)，RunLoop 就會(huì)自己醒來去執(zhí)行 Source1 事件（也能稱為被消息喚醒）架谎。也就是 Source0 是直接添加給 RunLoop 處理的事件炸宵，而 Source1 是基于端口的，進(jìn)程或線程之間傳遞消息觸發(fā)的事件（為什么要 0 和 1 來命名谷扣，每次都記不住土全，GG）。
Timer 是基于時(shí)間的觸發(fā)器会涎，CFRunLoopTimerRef 和 NSTimer 可以通過 Toll-free bridging 技術(shù)混用裹匙，Toll-free bridging 是一種允許某些 ObjC 類與其對(duì)應(yīng)的 CoreFoundation 類之間可以互換使用的機(jī)制，當(dāng)將 Timer 加入到 RunLoop 時(shí)末秃，RunLoop 會(huì)注冊(cè)對(duì)應(yīng)的時(shí)間點(diǎn)概页，當(dāng)時(shí)間點(diǎn)到時(shí)，RunLoop 會(huì)被喚醒以執(zhí)行 Timer 回調(diào)练慕。
Observer（觀察者）都包含了一個(gè)回調(diào)（函數(shù)指針）惰匙，當(dāng) RunLoop 的狀態(tài)發(fā)生變化時(shí)技掏，觀察者就能通過回調(diào)接受到這個(gè)變化∠罟恚可以觀測的時(shí)間點(diǎn)有以下幾個(gè)：
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 即將進(jìn)入Loop
kCFRunLoopBeforeTimers = (1UL << 1), // 即將處理 Timer
kCFRunLoopBeforeSources = (1UL << 2), // 即將處理 Source
kCFRunLoopBeforeWaiting = (1UL << 5), // 即將進(jìn)入休眠
kCFRunLoopAfterWaiting = (1UL << 6), // 剛從休眠中喚醒
kCFRunLoopExit = (1UL << 7), // 即將退出Loop
};
也就是可以在這幾個(gè)時(shí)機(jī)去安排 RunLoop 執(zhí)行一些其他的任務(wù)哑梳。
上面的 Source/Timer/Observer 被統(tǒng)稱為 mode item，一個(gè) item 可以被同時(shí)加入多個(gè) mode绘盟。但一個(gè) item 被重復(fù)加入同一個(gè) mode 時(shí)是不會(huì)有效果的鸠真。如果一個(gè) mode 中一個(gè) item 都沒有，則 RunLoop 會(huì)直接退出龄毡，不進(jìn)入循環(huán)吠卷。
RunLoop 的 CFRunLoopMode 和 CFRunLoop 的結(jié)構(gòu)大致如下：
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
...
};
這里有個(gè)概念叫 "CommonModes"：一個(gè) Mode 可以將自己標(biāo)記為"Common"屬性（通過將其 ModeName 添加到 RunLoop 的 "commonModes" 中）。每當(dāng) RunLoop 的內(nèi)容發(fā)生變化時(shí)沦零，RunLoop 都會(huì)自動(dòng)將 _commonModeItems 里的 Source/Observer/Timer 同步到具有 "Common" 標(biāo)記的所有Mode里祭隔。
如上文說的 RunLoop 一次循環(huán)只能運(yùn)行在一個(gè) Mode 下，是為了分隔開不同組的 Source/Timer/Observer蠢终，讓其互不影響。但如果一個(gè) Source/Timer/Observer 想在多個(gè) Mode 下運(yùn)作茴她，則可以分別加入到多個(gè) Mode寻拂，或者給兩個(gè) Mode 添加 "Common" 標(biāo)記，再將 Source/Timer/Observer 加入到 RunLoop 的 "commonModeItems" 丈牢。
應(yīng)用場景舉例：主線程的 RunLoop 里有兩個(gè)預(yù)置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode祭钉。這兩個(gè) Mode 都已經(jīng)被標(biāo)記為"Common"屬性。DefaultMode 是 App 平時(shí)所處的狀態(tài)己沛，TrackingRunLoopMode 是追蹤 ScrollView 滑動(dòng)時(shí)的狀態(tài)慌核。當(dāng)你創(chuàng)建一個(gè) Timer 并加到 DefaultMode 時(shí)，Timer 會(huì)得到重復(fù)回調(diào)申尼，但此時(shí)滑動(dòng)一個(gè)TableView時(shí)垮卓，RunLoop 會(huì)將 mode 切換為 TrackingRunLoopMode，這時(shí) Timer 就不會(huì)被回調(diào)师幕，如果想讓它回調(diào)則可以將這個(gè) Timer 分別加入這兩個(gè) Mode粟按。或?qū)?Timer 加入到頂層的 RunLoop 的 "commonModeItems" 霹粥。
CFRunLoop 對(duì)外暴露的管理 Mode 接口只有下面2個(gè):
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);
Mode 暴露的管理 mode item 的接口有下面幾個(gè)：
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 并不像 Source/Timer/Observer 一樣有 Remove 方法灭将，所以 mode 只能增加，不能減少后控。
當(dāng)你傳入一個(gè)新的 mode name 但 RunLoop 內(nèi)部沒有對(duì)應(yīng) mode 時(shí)庙曙，RunLoop會(huì)自動(dòng)幫你創(chuàng)建對(duì)應(yīng)的 CFRunLoopModeRef。
接下來看 RunLoop 的執(zhí)行邏輯
按 1 - 10 來理理浩淘，首先要知道 Observer 是觀察者捌朴，也就是下面這幾種狀態(tài)都會(huì)通知觀察者吴攒，開發(fā)者也添加一個(gè)觀察者，去在以下幾種狀態(tài)的時(shí)候男旗，執(zhí)行一些任務(wù)舶斧，比如將沒啥實(shí)時(shí)性要求的東西，在即將進(jìn)入休眠狀態(tài)時(shí)執(zhí)行察皇。
kCFRunLoopEntry = (1UL << 0), // 即將進(jìn)入Loop
kCFRunLoopBeforeTimers = (1UL << 1), // 即將處理 Timer
kCFRunLoopBeforeSources = (1UL << 2), // 即將處理 Source
kCFRunLoopBeforeWaiting = (1UL << 5), // 即將進(jìn)入休眠
kCFRunLoopAfterWaiting = (1UL << 6), // 剛從休眠中喚醒
kCFRunLoopExit = (1UL << 7), // 即將退出Loop
其中第 2 步雖然通知 Observer 即將處理 Timer茴厉，但其實(shí)并沒有真的即將處理 Timer 回調(diào)，這個(gè)通知每次 Loop 循環(huán)都會(huì)調(diào)用什荣，但 Timer 只有在注冊(cè)的時(shí)間到了才會(huì)在第 9 步去執(zhí)行矾缓，第 4 步處理運(yùn)行的 mode 里待處理的 Source0，其中第 5 步會(huì)判斷 mode item 里是否有 Source1 處于 ready 狀態(tài)（也就是 Source1 的端口已經(jīng)收到消息）稻爬，有的話跳到第 9 步嗜闻，處理 Source1 事件，然后進(jìn)入下一個(gè)循環(huán)桅锄，沒有的話說明 mode item 里的事件都處理完畢琉雳，線程進(jìn)入休眠狀態(tài)，等待 Source1友瘤，Timer 或者外部手動(dòng)將 RunLoop 喚醒（上文說 Source0 并不能喚醒 RunLoop翠肘，所以一般會(huì)通過手動(dòng)喚醒 RunLoop，來讓 RunLoop 處理新加入進(jìn)去的 Source0）辫秧。
可以看到束倍，實(shí)際上 RunLoop 就是這樣一個(gè)函數(shù)，其內(nèi)部是一個(gè) do-while 循環(huán)盟戏。當(dāng)你調(diào)用 CFRunLoopRun() 時(shí)绪妹，線程就會(huì)一直停留在這個(gè)循環(huán)里，去執(zhí)行加入到 RunLoop 里的 Source0柿究，Timer 的回調(diào)邮旷，以及 Observer 回調(diào)，以及用于線程或進(jìn)程間通訊的 Source1蝇摸，當(dāng)所有的都處理完之后廊移，結(jié)束一次循環(huán)，進(jìn)入休眠狀態(tài)探入，休眠的時(shí)候等待 Timer 注冊(cè)的時(shí)間點(diǎn)或者 Source1 喚醒 RunLoop（也可以手動(dòng)喚醒）狡孔。
從上面我們可以了解，線程和進(jìn)程之間的通訊是基于 mach port 傳遞消息實(shí)現(xiàn)的蜂嗽，這也是 RunLoop 的核心苗膝。有必要了解一下 mach port， OSX/iOS 的系統(tǒng)架構(gòu)分為 4 層植旧，從外到內(nèi)為應(yīng)用層辱揭，應(yīng)用框架層离唐，核心框架層，Darwin问窃。應(yīng)用層包括用戶能接觸到的圖形應(yīng)用亥鬓，應(yīng)用框架層即開發(fā)人員接觸到的 Cocoa 等框架，核心框架層包括各種核心框架域庇、OpenGL 等內(nèi)容嵌戈，Darwin 即操作系統(tǒng)的核心，包括系統(tǒng)內(nèi)核听皿、驅(qū)動(dòng)熟呛、Shell 等內(nèi)容。
Darwin 核心的架構(gòu)：
其中尉姨，在硬件層上面的三個(gè)組成部分：Mach庵朝、BSD、IOKit (還包括一些上面沒標(biāo)注的內(nèi)容)又厉，共同組成了 XNU 內(nèi)核九府。
XNU 內(nèi)核的內(nèi)環(huán)被稱作 Mach，其作為一個(gè)微內(nèi)核覆致，僅提供了諸如處理器調(diào)度侄旬、IPC (進(jìn)程間通信)等非常少量的基礎(chǔ)服務(wù)。
BSD 層可以看作圍繞 Mach 層的一個(gè)外環(huán)篷朵，其提供了諸如進(jìn)程管理勾怒、文件系統(tǒng)和網(wǎng)絡(luò)等功能婆排。
IOKit 層是為設(shè)備驅(qū)動(dòng)提供了一個(gè)面向?qū)ο?C++)的一個(gè)框架声旺。
在 Mach 中，進(jìn)程段只、線程和虛擬內(nèi)存都被稱為"對(duì)象"腮猖。Mach 的對(duì)象間不能直接調(diào)用，只能通過消息傳遞的方式實(shí)現(xiàn)對(duì)象間的通信赞枕。"消息"是 Mach 中最基礎(chǔ)的概念澈缺，消息在兩個(gè)端口 (port) 之間傳遞，這就是 Mach 的 IPC (進(jìn)程間通信) 的核心炕婶。
Mach 中的對(duì)象通過一個(gè) Mach 端口發(fā)送一個(gè)消息姐赡，消息中會(huì)攜帶目標(biāo)端口，這個(gè)消息會(huì)從用戶空間傳遞到內(nèi)核空間柠掂，再由內(nèi)核空間傳遞到目標(biāo)端口项滑，實(shí)現(xiàn)線程或進(jìn)程之間的通訊。（也就是線程或進(jìn)程之間的通訊不能繞過系統(tǒng)內(nèi)核）涯贞。目標(biāo)端口接收到消息枪狂，因?yàn)?RunLoop 會(huì)對(duì) mach_port 端口源進(jìn)行監(jiān)聽危喉，如果 RunLoop 此時(shí)處于休眠狀態(tài)，則被喚醒州疾，便可以處理已經(jīng)接收到消息的 source1 事件辜限。
RunLoop 實(shí)現(xiàn)了很多功能
啟動(dòng)后，系統(tǒng)默認(rèn)注冊(cè)了5個(gè)Mode:
1：kCFRunLoopDefaultMode: App的默認(rèn) Mode严蓖，通常主線程是在這個(gè) Mode 下運(yùn)行的薄嫡。
2：UITrackingRunLoopMode: 界面跟蹤 Mode，用于 ScrollView 追蹤觸摸滑動(dòng)谈飒，保證界面滑動(dòng)時(shí)不受其他 Mode 影響岂座。
3：UIInitializationRunLoopMode: 在剛啟動(dòng) App 時(shí)第進(jìn)入的第一個(gè) Mode，啟動(dòng)完成后就不再使用杭措。
4：GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內(nèi)部 Mode费什，通常用不到。
5：kCFRunLoopCommonModes: 這是一個(gè)占位的 Mode手素，沒有實(shí)際作用鸳址。
AutoreleasePool
App啟動(dòng)后，蘋果在主線程 RunLoop 里注冊(cè)了兩個(gè) Observer泉懦，其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()（因?yàn)樾枰O(shè)置不同的優(yōu)先級(jí)稿黍，所以注冊(cè)兩個(gè)）。
第一個(gè) Observer 監(jiān)視的事件是 Entry(即將進(jìn)入Loop)崩哩，用來創(chuàng)建自動(dòng)釋放池巡球，且設(shè)置的優(yōu)先級(jí)最高，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前邓嘹。
第二個(gè) Observer 監(jiān)視了兩個(gè)事件： BeforeWaiting(準(zhǔn)備進(jìn)入休眠) 時(shí)去釋放舊的池并創(chuàng)建新池酣栈；Exit(即將退出Loop) 時(shí)釋放自動(dòng)釋放池。這個(gè) Observer 的優(yōu)先級(jí)最低汹押，保證其釋放池子發(fā)生在其他所有回調(diào)之后矿筝。
在主線程執(zhí)行的代碼，通常是寫在諸如事件回調(diào)棚贾、Timer 回調(diào)內(nèi)的窖维。這些回調(diào)會(huì)被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著，所以不會(huì)出現(xiàn)內(nèi)存泄漏妙痹。
事件響應(yīng)
蘋果注冊(cè)了一個(gè) Source1 (基于 mach port 的) 用來接收系統(tǒng)事件铸史，其回調(diào)函數(shù)為 __IOHIDEventSystemClientQueueCallback()。
當(dāng)一個(gè)硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后怯伊，首先由 IOKit.framework 生成一個(gè) IOHIDEvent 事件并由 SpringBoard 接收琳轿。隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進(jìn)程。隨后蘋果注冊(cè)的那個(gè) Source1 就會(huì)觸發(fā)回調(diào)，并調(diào)用 _UIApplicationHandleEventQueue() 進(jìn)行應(yīng)用內(nèi)部的事件傳遞利赋。
_UIApplicationHandleEventQueue() 會(huì)把 IOHIDEvent 處理并包裝成 UIEvent 進(jìn)行處理或分發(fā)水评，其中包括識(shí)別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等。通常事件比如 UIButton 點(diǎn)擊媚送、touchesBegin/Move/End/Cancel 事件都是在這個(gè)回調(diào)中完成的中燥。
手勢識(shí)別
當(dāng)上面的 _UIApplicationHandleEventQueue() 識(shí)別了一個(gè)手勢時(shí)，其首先會(huì)調(diào)用 Cancel 將當(dāng)前的 touchesBegin/Move/End 系列回調(diào)打斷塘偎。隨后系統(tǒng)將對(duì)應(yīng)的 UIGestureRecognizer 標(biāo)記為待處理疗涉。
蘋果注冊(cè)了一個(gè) Observer 監(jiān)測 BeforeWaiting (Loop即將進(jìn)入休眠) 事件，這個(gè) Observer 的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()吟秩，其內(nèi)部會(huì)獲取所有剛被標(biāo)記為待處理的 GestureRecognizer咱扣，并執(zhí)行 GestureRecognizer 的回調(diào)。
當(dāng)有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時(shí)涵防，這個(gè)回調(diào)都會(huì)進(jìn)行相應(yīng)處理闹伪。
界面更新
當(dāng)在操作 UI 時(shí)，比如改變了 Frame壮池、更新了 UIView/CALayer 的層次時(shí)偏瓤，或者手動(dòng)調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay 方法后，這個(gè) UIView/CALayer 就被標(biāo)記為待處理椰憋，并被提交到一個(gè)全局的容器去厅克。
蘋果注冊(cè)了一個(gè) Observer 監(jiān)聽 BeforeWaiting(即將進(jìn)入休眠) 和 Exit (即將退出Loop) 事件，回調(diào)去執(zhí)行一個(gè)很長的函數(shù)：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()橙依。這個(gè)函數(shù)里會(huì)遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實(shí)際的繪制和調(diào)整证舟，并更新 UI 界面。也就是 UI 是在界面 RunLoop 休眠之前更新的窗骑，所以如果想在 UI 更新之后做一些事情女责，可以注冊(cè)一個(gè) Observer 監(jiān)聽 kCFRunLoopAfterWaiting(剛從休眠中喚醒)。
定時(shí)器
NSTimer 其實(shí)就是 CFRunLoopTimerRef慧域，他們之間是 toll-free bridged 的鲤竹。一個(gè) NSTimer 注冊(cè)到 RunLoop 后浪读，RunLoop 會(huì)為其重復(fù)的時(shí)間點(diǎn)注冊(cè)好事件昔榴。例如 10:00, 10:10, 10:20 這幾個(gè)時(shí)間點(diǎn)。RunLoop為了節(jié)省資源碘橘，并不會(huì)在非常準(zhǔn)確的時(shí)間點(diǎn)回調(diào)這個(gè)Timer互订。Timer 有個(gè)屬性叫做 Tolerance (寬容度)，標(biāo)示了當(dāng)時(shí)間點(diǎn)到后痘拆，容許有多少最大誤差仰禽。
如果某個(gè)時(shí)間點(diǎn)被錯(cuò)過了，例如執(zhí)行了一個(gè)很長的任務(wù)，則那個(gè)時(shí)間點(diǎn)的回調(diào)也會(huì)跳過去吐葵，不會(huì)延后執(zhí)行规揪。
CADisplayLink 是一個(gè)和屏幕刷新率一致的定時(shí)器（但實(shí)際實(shí)現(xiàn)原理更復(fù)雜，和 NSTimer 并不一樣温峭，其內(nèi)部實(shí)際是操作了一個(gè) Source）猛铅。如果在兩次屏幕刷新之間執(zhí)行了一個(gè)長任務(wù)，那其中就會(huì)有一幀被跳過去（和 NSTimer 相似）凤藏，造成界面卡頓的感覺奸忽。
PerformSelecter
當(dāng)調(diào)用 NSObject 的 performSelecter:afterDelay: 后，實(shí)際上其內(nèi)部會(huì)創(chuàng)建一個(gè) Timer 并添加到當(dāng)前線程的 RunLoop 中揖庄。所以如果當(dāng)前線程沒有 RunLoop栗菜，則這個(gè)方法會(huì)失效。
當(dāng)調(diào)用 performSelector:onThread: 時(shí)蹄梢，實(shí)際上其會(huì)創(chuàng)建一個(gè) Timer 加到對(duì)應(yīng)的線程去疙筹，同樣的，如果對(duì)應(yīng)線程沒有 RunLoop 該方法也會(huì)失效禁炒。
GCD
當(dāng)調(diào)用 dispatch_async(dispatch_get_main_queue(), block) 時(shí)腌歉，libDispatch 會(huì)向主線程的 RunLoop 發(fā)送消息，RunLoop會(huì)被喚醒齐苛，并從消息中取得這個(gè) block翘盖，并在回調(diào) CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里執(zhí)行這個(gè) block。但這個(gè)邏輯僅限于 dispatch 到主線程凹蜂，dispatch 到其他線程仍然是由 libDispatch 處理的馍驯。
網(wǎng)絡(luò)請(qǐng)求
iOS 中，關(guān)于網(wǎng)絡(luò)請(qǐng)求的接口自下至上有如下幾層:
CFSocket
CFNetwork ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession ->AFNetworking2, Alamofire
通常使用 NSURLConnection 時(shí)玛痊，你會(huì)傳入一個(gè) Delegate汰瘫，當(dāng)調(diào)用了 [connection start] 后，這個(gè) Delegate 就會(huì)不停收到事件回調(diào)擂煞。實(shí)際上混弥，start 這個(gè)函數(shù)的內(nèi)部會(huì)會(huì)獲取 CurrentRunLoop，然后在其中的 DefaultMode 添加了多個(gè)需要手動(dòng)觸發(fā)的 Source0对省。
當(dāng)開始網(wǎng)絡(luò)傳輸時(shí)蝗拿，NSURLConnection 創(chuàng)建了兩個(gè)新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的蒿涎。NSURLConnectionLoader 這個(gè)線程內(nèi)部會(huì)使用 RunLoop 基于 mach port 的 Source1 接收來自底層 CFSocket 的消息哀托，當(dāng)收到消息后，其會(huì)在合適的時(shí)機(jī)將 Source0 標(biāo)記為待處理劳秋，同時(shí)喚醒 Delegate 線程的 RunLoop 來讓其處理 Source0仓手。完成一個(gè)由 CFSocket 線程到網(wǎng)絡(luò)請(qǐng)求所在線程的數(shù)據(jù)處理胖齐。
AFNetworking
AFURLConnectionOperation 這個(gè)類是基于 NSURLConnection 構(gòu)建的，其希望能在后臺(tái)線程接收 Delegate 回調(diào)嗽冒。為此 AFNetworking 創(chuàng)建了一個(gè)線程呀伙，并在這個(gè)線程中啟動(dòng)了一個(gè) RunLoop，RunLoop 啟動(dòng)前內(nèi)部必須要有至少一個(gè) Timer/Observer/Source添坊，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個(gè)新的 NSMachPort 添加進(jìn)去了区匠。只是為了讓 RunLoop 不至于退出，并沒有用于實(shí)際的發(fā)送消息帅腌。當(dāng)需要這個(gè)后臺(tái)線程執(zhí)行網(wǎng)絡(luò)請(qǐng)求任務(wù)時(shí)驰弄，AFNetworking 通過調(diào)用 [NSObject performSelector:onThread:..] 將這個(gè)任務(wù)扔到了該線程的 RunLoop 中。
AsyncDisplayKit
AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架速客，其原理大致如下：
UI 線程中一旦出現(xiàn)繁重的任務(wù)就會(huì)導(dǎo)致界面卡頓戚篙，這類任務(wù)通常分為3類：排版，繪制溺职，UI對(duì)象操作岔擂。
排版通常包括計(jì)算視圖大小、計(jì)算文本高度浪耘、重新計(jì)算子式圖的排版等操作乱灵。
繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預(yù)先解壓)七冲、元素繪制 (Quartz)等操作痛倚。
UI對(duì)象操作通常包括 UIView/CALayer 等 UI 對(duì)象的創(chuàng)建、設(shè)置屬性和銷毀澜躺。
其中前兩類操作可以通過各種方法扔到后臺(tái)線程執(zhí)行蝉稳，而最后一類操作只能在主線程完成，并且有時(shí)后面的操作需要依賴前面操作的結(jié)果 （例如TextView創(chuàng)建時(shí)可能需要提前計(jì)算出文本的大芯虮伞）耘戚。ASDK 所做的，就是盡量將能放入后臺(tái)的任務(wù)放入后臺(tái)操漠，不能的則盡量推遲 (例如視圖的創(chuàng)建收津、屬性的調(diào)整)。
為此浊伙，ASDK 創(chuàng)建了一個(gè)名為 ASDisplayNode 的對(duì)象撞秋，并在內(nèi)部封裝了 UIView/CALayer，它具有和 UIView/CALayer 相似的屬性吧黄，例如 frame部服、backgroundColor 等唆姐。所有這些屬性都可以在后臺(tái)線程更改拗慨，開發(fā)者可以只通過 Node 來操作其內(nèi)部的 UIView/CALayer，這樣就可以將排版和繪制放入了后臺(tái)線程。但是無論怎么操作赵抢，這些屬性總需要在某個(gè)時(shí)刻同步到主線程的 UIView/CALayer 去剧蹂。
ASDK 仿照 QuartzCore/UIKit 框架的模式，實(shí)現(xiàn)了一套類似的界面更新的機(jī)制：即在主線程的 RunLoop 中添加一個(gè) Observer烦却，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件宠叼，在收到回調(diào)時(shí)，遍歷所有之前放入隊(duì)列的待處理的任務(wù)（需要將 Node 的屬性同步到主線程的 UIView/CALayer 去的任務(wù)）其爵，然后一一執(zhí)行冒冬。
總結(jié)：
ibireme 的 深入理解RunLoop 前前后后我看了好幾遍，每次都看的不深入摩渺，總是瞬時(shí)了解简烤，睡一覺就記不清楚細(xì)節(jié)了，這次自己逐行去理解摇幻，并寫下來横侦，加上點(diǎn)自己的理解，也寫了點(diǎn)代碼去觀察 RunLoop绰姻，算是對(duì) RunLoop 的理解更加深入了枉侧。
