注：本篇部落格只在 ibireme 的 深入理解RunLoop 基礎上做了點方便自己複習該知識點的修改，能力有限，如果有理解的不對的地方，還希望能幫忙指出。
首先了解一下程式、程式和執行緒
程式本身只是指令、資料及其組織形式的描述，程式才是程式（那些指令和資料）的真正執行例項。而執行緒是作業系統能夠進行運算排程的最小單位。它被包含在程式之中，是程式中的實際運作單位。一條執行緒指的是程式中一個單一順序的控制流，一個程式中可以併發多個執行緒，每條執行緒並行執行不同的任務。
一般來說，一個執行緒一次只能執行一個任務，執行完成後執行緒就會退出。所以程式執行的時候，需要一個機制，讓執行緒能隨時處理事件但不退出。
以前寫遊戲的時候就寫過這樣的東西，通常是一個 do while 迴圈，讓程式一直運轉，直到接收到退出資訊。
而 RunLoop 就是讓執行緒在沒有處理訊息時休眠以避免資源佔用，在有訊息到來時立刻被喚醒。
執行緒和 RunLoop 之間是一一對應的，其關係是儲存在一個全域性的 Dictionary 裡。執行緒剛建立時預設是沒有 RunLoop，如果你不主動獲取，那它一直都不會有。RunLoop 的建立是發生在第一次獲取時，RunLoop 的銷燬是發生線上程結束時。你只能在一個執行緒的內部獲取其 RunLoop（主執行緒除外）。
在 CoreFoundation 裡面關於 RunLoop 有5個類:
|
1 2 3 4 5 |
CFRunLoopRef CFRunLoopModeRef CFRunLoopSourceRef CFRunLoopTimerRef CFRunLoopObserverRef |
他們的層級關係為，一個 RunLoop 物件包含若干個 Mode 物件，每個 Mode 又包含若干個 Source/Timer/Observer，RunLoop 在運作的時候，一次只能運作與一個 Mode 之下，如果需要切換 Mode，需要退出 Loop 才能重新指定一個 Mode。這樣做主要是為了分隔開不同組的 Source/Timer/Observer，讓其互不影響。
而一個 Source 物件是一個事件，Source 有兩個版本：Source0 和 Source1，Source0 只包含一個函式指標，並不能主動觸發，需要將 Source0 標記為待處理，在 RunLoop 運轉的時候，才會處理這個事件（如果 RunLoop 處於休眠狀態，則不會被喚醒去處理），而 Source1 包含了一個 mach_port 和一個函式指標，mach_port 是 iOS 系統提供的基於埠的輸入源，可用於執行緒或程式間通訊。而 RunLoop 支援的輸入源型別中就包括基於埠的輸入源，可以做到對 mach_port 埠源事件的監聽。所以監聽到 source1 埠的訊息時，RunLoop 就會自己醒來去執行 Source1 事件（也能稱為被訊息喚醒）。也就是 Source0 是直接新增給 RunLoop 處理的事件，而 Source1 是基於埠的，程式或執行緒之間傳遞訊息觸發的事件（為什麼要 0 和 1 來命名，每次都記不住，GG）。
Timer 是基於時間的觸發器，CFRunLoopTimerRef 和 NSTimer 可以通過 Toll-free bridging 技術混用，Toll-free bridging 是一種允許某些 ObjC 類與其對應的 CoreFoundation 類之間可以互換使用的機制，當將 Timer 加入到 RunLoop 時，RunLoop 會註冊對應的時間點，當時間點到時，RunLoop 會被喚醒以執行 Timer 回撥。
Observer（觀察者）都包含了一個回撥（函式指標），當 RunLoop 的狀態發生變化時，觀察者就能通過回撥接受到這個變化。可以觀測的時間點有以下幾個：
|
1 2 3 4 5 6 7 8 |
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) { kCFRunLoopEntry = (1UL << 0), // 即將進入Loop kCFRunLoopBeforeTimers = (1UL << 1), // 即將處理 Timer kCFRunLoopBeforeSources = (1UL << 2), // 即將處理 Source kCFRunLoopBeforeWaiting = (1UL << 5), // 即將進入休眠 kCFRunLoopAfterWaiting = (1UL << 6), // 剛從休眠中喚醒 kCFRunLoopExit = (1UL << 7), // 即將退出Loop }; |
也就是可以在這幾個時機去安排 RunLoop 執行一些其他的任務。
上面的 Source/Timer/Observer 被統稱為 mode item，一個 item 可以被同時加入多個 mode。但一個 item 被重複加入同一個 mode 時是不會有效果的。如果一個 mode 中一個 item 都沒有，則 RunLoop 會直接退出，不進入迴圈。
RunLoop 的 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 CFRunLoopModeRef _currentMode; // Current Runloop Mode CFMutableSetRef _modes; // Set ... }; |
這裡有個概念叫 “CommonModes”：一個 Mode 可以將自己標記為”Common”屬性（通過將其 ModeName 新增到 RunLoop 的 “commonModes” 中）。每當 RunLoop 的內容發生變化時，RunLoop 都會自動將 _commonModeItems 裡的 Source/Observer/Timer 同步到具有 “Common” 標記的所有Mode裡。
如上文說的 RunLoop 一次迴圈只能執行在一個 Mode 下，是為了分隔開不同組的 Source/Timer/Observer，讓其互不影響。但如果一個 Source/Timer/Observer 想在多個 Mode 下運作，則可以分別加入到多個 Mode，或者給兩個 Mode 新增 “Common” 標記，再將 Source/Timer/Observer 加入到 RunLoop 的 “commonModeItems” 。
應用場景舉例：主執行緒的 RunLoop 裡有兩個預置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。這兩個 Mode 都已經被標記為”Common”屬性。DefaultMode 是 App 平時所處的狀態，TrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態。當你建立一個 Timer 並加到 DefaultMode 時，Timer 會得到重複回撥，但此時滑動一個TableView時，RunLoop 會將 mode 切換為 TrackingRunLoopMode，這時 Timer 就不會被回撥，如果想讓它回撥則可以將這個 Timer 分別加入這兩個 Mode。或將 Timer 加入到頂層的 RunLoop 的 “commonModeItems” 。
CFRunLoop 對外暴露的管理 Mode 介面只有下面2個:
|
1 2 |
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName); CFRunLoopRunInMode(CFStringRef modeName, ...); |
Mode 暴露的管理 mode item 的介面有下面幾個：
|
1 2 3 4 5 6 |
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 只能增加，不能減少。
當你傳入一個新的 mode name 但 RunLoop 內部沒有對應 mode 時，RunLoop會自動幫你建立對應的 CFRunLoopModeRef。
接下來看 RunLoop 的執行邏輯
按 1 – 10 來理理，首先要知道 Observer 是觀察者，也就是下面這幾種狀態都會通知觀察者，開發者也新增一個觀察者，去在以下幾種狀態的時候，執行一些任務，比如將沒啥實時性要求的東西，在即將進入休眠狀態時執行。
|
1 2 3 4 5 6 |
kCFRunLoopEntry = (1UL << 0), // 即將進入Loop kCFRunLoopBeforeTimers = (1UL << 1), // 即將處理 Timer kCFRunLoopBeforeSources = (1UL << 2), // 即將處理 Source kCFRunLoopBeforeWaiting = (1UL << 5), // 即將進入休眠 kCFRunLoopAfterWaiting = (1UL << 6), // 剛從休眠中喚醒 kCFRunLoopExit = (1UL << 7), // 即將退出Loop |
其中第 2 步雖然通知 Observer 即將處理 Timer，但其實並沒有真的即將處理 Timer 回撥，這個通知每次 Loop 迴圈都會呼叫，但 Timer 只有在註冊的時間到了才會在第 9 步去執行，第 4 步處理執行的 mode 裡待處理的 Source0，其中第 5 步會判斷 mode item 裡是否有 Source1 處於 ready 狀態（也就是 Source1 的埠已經收到訊息），有的話跳到第 9 步，處理 Source1 事件，然後進入下一個迴圈，沒有的話說明 mode item 裡的事件都處理完畢，執行緒進入休眠狀態，等待 Source1，Timer 或者外部手動將 RunLoop 喚醒（上文說 Source0 並不能喚醒 RunLoop，所以一般會通過手動喚醒 RunLoop，來讓 RunLoop 處理新加入進去的 Source0）。
可以看到，實際上 RunLoop 就是這樣一個函式，其內部是一個 do-while 迴圈。當你呼叫 CFRunLoopRun() 時，執行緒就會一直停留在這個迴圈裡，去執行加入到 RunLoop 裡的 Source0，Timer 的回撥，以及 Observer 回撥，以及用於執行緒或程式間通訊的 Source1，當所有的都處理完之後，結束一次迴圈，進入休眠狀態，休眠的時候等待 Timer 註冊的時間點或者 Source1 喚醒 RunLoop（也可以手動喚醒）。
從上面我們可以瞭解，執行緒和程式之間的通訊是基於 mach port 傳遞訊息實現的，這也是 RunLoop 的核心。有必要了解一下 mach port， OSX/iOS 的系統架構分為 4 層，從外到內為應用層，應用框架層，核心框架層，Darwin。應用層包括使用者能接觸到的圖形應用，應用框架層即開發人員接觸到的 Cocoa 等框架，核心框架層包括各種核心框架、OpenGL 等內容，Darwin 即作業系統的核心，包括系統核心、驅動、Shell 等內容。
Darwin 核心的架構：
其中，在硬體層上面的三個組成部分：Mach、BSD、IOKit (還包括一些上面沒標註的內容)，共同組成了 XNU 核心。
XNU 核心的內環被稱作 Mach，其作為一個微核心，僅提供了諸如處理器排程、IPC (程式間通訊)等非常少量的基礎服務。
BSD 層可以看作圍繞 Mach 層的一個外環，其提供了諸如程式管理、檔案系統和網路等功能。
IOKit 層是為裝置驅動提供了一個物件導向(C++)的一個框架。
在 Mach 中，程式、執行緒和虛擬記憶體都被稱為”物件”。Mach 的物件間不能直接呼叫，只能通過訊息傳遞的方式實現物件間的通訊。”訊息”是 Mach 中最基礎的概念，訊息在兩個埠 (port) 之間傳遞，這就是 Mach 的 IPC (程式間通訊) 的核心。
Mach 中的物件通過一個 Mach 埠傳送一個訊息，訊息中會攜帶目標埠，這個訊息會從使用者空間傳遞到核心空間，再由核心空間傳遞到目標埠，實現執行緒或程式之間的通訊。（也就是執行緒或程式之間的通訊不能繞過系統核心）。目標埠接收到訊息，因為 RunLoop 會對 mach_port 埠源進行監聽，如果 RunLoop 此時處於休眠狀態，則被喚醒，便可以處理已經接收到訊息的 source1 事件。
RunLoop 實現了很多功能
啟動後，系統預設註冊了5個Mode:
1：kCFRunLoopDefaultMode: App的預設 Mode，通常主執行緒是在這個 Mode 下執行的。
2：UITrackingRunLoopMode: 介面跟蹤 Mode，用於 ScrollView 追蹤觸控滑動，保證介面滑動時不受其他 Mode 影響。
3：UIInitializationRunLoopMode: 在剛啟動 App 時第進入的第一個 Mode，啟動完成後就不再使用。
4：GSEventReceiveRunLoopMode: 接受系統事件的內部 Mode，通常用不到。
5：kCFRunLoopCommonModes: 這是一個佔位的 Mode，沒有實際作用。
AutoreleasePool
App啟動後，蘋果在主執行緒 RunLoop 裡註冊了兩個 Observer，其回撥都是 _wrapRunLoopWithAutoreleasePoolHandler()（因為需要設定不同的優先順序，所以註冊兩個）。
第一個 Observer 監視的事件是 Entry(即將進入Loop)，用來建立自動釋放池，且設定的優先順序最高，保證建立釋放池發生在其他所有回撥之前。
第二個 Observer 監視了兩個事件： BeforeWaiting(準備進入休眠) 時去釋放舊的池並建立新池；Exit(即將退出Loop) 時釋放自動釋放池。這個 Observer 的優先順序最低，保證其釋放池子發生在其他所有回撥之後。
在主執行緒執行的程式碼，通常是寫在諸如事件回撥、Timer 回撥內的。這些回撥會被 RunLoop 建立好的 AutoreleasePool 環繞著，所以不會出現記憶體洩漏。
事件響應
蘋果註冊了一個 Source1 (基於 mach port 的) 用來接收系統事件，其回撥函式為 __IOHIDEventSystemClientQueueCallback()。
當一個硬體事件(觸控/鎖屏/搖晃等)發生後，首先由 IOKit.framework 生成一個 IOHIDEvent 事件並由 SpringBoard 接收。隨後用 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 介面。也就是 UI 是在介面 RunLoop 休眠之前更新的，所以如果想在 UI 更新之後做一些事情，可以註冊一個 Observer 監聽 kCFRunLoopAfterWaiting(剛從休眠中喚醒)。
定時器
NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 註冊到 RunLoop 後，RunLoop 會為其重複的時間點註冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節省資源，並不會在非常準確的時間點回撥這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到後，容許有多少最大誤差。
如果某個時間點被錯過了，例如執行了一個很長的任務，則那個時間點的回撥也會跳過去，不會延後執行。
CADisplayLink 是一個和螢幕重新整理率一致的定時器（但實際實現原理更復雜，和 NSTimer 並不一樣，其內部實際是操作了一個 Source）。如果在兩次螢幕重新整理之間執行了一個長任務，那其中就會有一幀被跳過去（和 NSTimer 相似），造成介面卡頓的感覺。
PerformSelecter
當呼叫 NSObject 的 performSelecter:afterDelay: 後，實際上其內部會建立一個 Timer 並新增到當前執行緒的 RunLoop 中。所以如果當前執行緒沒有 RunLoop，則這個方法會失效。
當呼叫 performSelector:onThread: 時，實際上其會建立一個 Timer 加到對應的執行緒去，同樣的，如果對應執行緒沒有 RunLoop 該方法也會失效。
GCD
當呼叫 dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主執行緒的 RunLoop 傳送訊息，RunLoop會被喚醒，並從訊息中取得這個 block，並在回撥 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 裡執行這個 block。但這個邏輯僅限於 dispatch 到主執行緒，dispatch 到其他執行緒仍然是由 libDispatch 處理的。
網路請求
iOS 中，關於網路請求的介面自下至上有如下幾層:
|
1 2 3 4 |
CFSocket CFNetwork ->ASIHttpRequest NSURLConnection ->AFNetworking NSURLSession ->AFNetworking2, Alamofire |
通常使用 NSURLConnection 時，你會傳入一個 Delegate，當呼叫了 [connection start] 後，這個 Delegate 就會不停收到事件回撥。實際上，start 這個函式的內部會會獲取 CurrentRunLoop，然後在其中的 DefaultMode 新增了多個需要手動觸發的 Source0。
當開始網路傳輸時，NSURLConnection 建立了兩個新執行緒：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 執行緒是處理底層 socket 連線的。NSURLConnectionLoader 這個執行緒內部會使用 RunLoop 基於 mach port 的 Source1 接收來自底層 CFSocket 的訊息，當收到訊息後，其會在合適的時機將 Source0 標記為待處理，同時喚醒 Delegate 執行緒的 RunLoop 來讓其處理 Source0。完成一個由 CFSocket 執行緒到網路請求所線上程的資料處理。
AFNetworking
AFURLConnectionOperation 這個類是基於 NSURLConnection 構建的，其希望能在後臺執行緒接收 Delegate 回撥。為此 AFNetworking 建立了一個執行緒，並在這個執行緒中啟動了一個 RunLoop，RunLoop 啟動前內部必須要有至少一個 Timer/Observer/Source，所以 AFNetworking 在 [runLoop run] 之前先建立了一個新的 NSMachPort 新增進去了。只是為了讓 RunLoop 不至於退出，並沒有用於實際的傳送訊息。當需要這個後臺執行緒執行網路請求任務時，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 事件，在收到回撥時，遍歷所有之前放入佇列的待處理的任務（需要將 Node 的屬性同步到主執行緒的 UIView/CALayer 去的任務），然後一一執行。
總結：
ibireme 的 深入理解RunLoop 前前後後我看了好幾遍，每次都看的不深入，總是瞬時瞭解，睡一覺就記不清楚細節了，這次自己逐行去理解，並寫下來，加上點自己的理解，也寫了點程式碼去觀察 RunLoop，算是對 RunLoop 的理解更加深入了。