首先我們可以看一下 App 啟動后 RunLoop 的狀態：
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),
}
}
}
可以看到，系統默認注冊了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.?通知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();
[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為了節省資源，并不會在非常準確的時間點回調這個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。但同時 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。
NSURLConnectionLoader 中的 RunLoop 通過一些基于 mach port 的 Source 接收來自底層 CFSocket 的通知。當收到通知后，其會在合適的時機向 CFMultiplexerSource 等 Source0 發送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執行實際的回調。
RunLoop 的實際應用舉例
AFNetworking
AFURLConnectionOperation這個類是基于 NSURLConnection 構建的，其希望能在后臺線程接收 Delegate 回調。為此 AFNetworking 單獨創建了一個線程，并在這個線程中啟動了一個 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] 之前先創建了一個新的 NSMachPort 添加進去了。通常情況下，調用者需要持有這個 NSMachPort (mach_port) 并在外部線程通過這個 port 發送消息到 loop 內；但此處添加 port 只是為了讓 RunLoop 不至于退出，并沒有用于實際的發送消息。
-?(void)start?{
[self.lock?lock];
if([self?isCancelled])?{
[self?performSelector:@selector(cancelConnection)?onThread:[[self?class]?networkRequestThread]?withObject:nil?waitUntilDone:NO?modes:[self.runLoopModes?allObjects]];
}elseif([self?isReady])?{
self.state?=?AFOperationExecutingState;
[self?performSelector:@selector(operationDidStart)?onThread:[[self?class]?networkRequestThread]?withObject:nil?waitUntilDone:NO?modes:[self.runLoopModes?allObjects]];
}
[self.lock?unlock];
}
當需要這個后臺線程執行任務時，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。
