在iOS開發過程中，Runloop的使用也是不容小覷的，雖然也是不太常用，但是這部分對於iOS開發也是相當重要的，而且在面試找工作的時候也是面試官必考的部分。那麼下來就來談談Runloop的理論及使用。
一、Runloop概念
1.Runloop概念：Runloops是與線程相關的基礎框架的一部分。一個Runloop就是一個事件處理的循環，用來不停的調度工作以及處理輸入事件。其實它內部就是do－while循環，這個循環內部不斷地處理各種任務（比如Timer，Observer）。使用Runloop的目的是讓線程在有工作任務的時候忙於工作，在沒工作任務的時候處於休眠狀態。
2.NSRunLoop和CFRunLoopRef
在開發的時候我們不能在一個線程中去操作另外一個線程的Runloop對象，如果這樣做很可能會造成無法估量的後果。不過值得慶幸的是CoreFundation中的不透明類CFRunLoopRef是線程安全的，而且這兩種類型的Runloop完全可以混合使用。
Cocoa中的NSRunLoop類可以通過實例方法：- (CFRunLoopRef)getCFRunLoop;
獲取對應的CFRunLoopRef類，來達到線程安全的目的。
CFRunLoopRef是在CoreFoundation框架內的，它提供瞭C語言函數的API，所有這些API都是關於線程安全的。
NSRunLoop是基於CFRunLoopRef的封裝，提供瞭面向對象的API，但這些API不是線程安全的。
3.Runloop和線程的關系
Runloop，見名知意，loop表示某種循環，和run放在一起就表示一直在運行著的循環。實際上，Runloop和線程是密不可分的，可以說Runloop是為瞭線程而生，沒有線程，Runloop就沒有存在的必要。Runloops是線程的基礎架構部分，Cocoa和CoreFundation都提供瞭Runloop對象方便配置和管理線程的Runloop（以下都已Cocoa為例）。每個線程，包括程序的主線程（main thread）都有與之相應的Runloop對象。
4.主線程中的Runloop默認情況下是啟動的
iOS應用程序裡面，程序啟動後會有一個如下的main()函數：
int main(int argc,char *argv[]){
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([appDelegate class]));
}
}
重點是UIApplicationMain()函數，這個方法會為main thread設置一個NSRunLoop對象，這就詮釋瞭剛開始說的為啥我們的應用可以在無人操作的時候休息，需要讓它幹活的時候又能立馬響應。對於其它線程來說，Runloop默認是沒有啟動的，如果你需要更多的線程交互則可以手動配置和啟動，如果線程隻是去執行一個長時間的已確定的任務則不需要。
在任何一個Cocoa程序的線程中，都可以通過：NSRunLoop *runloop = [NSRunLoop currentRunLoop];來獲取到當前線程的Runloop。
5.Runloop的接口和幾個類
在 CoreFoundation 裡面關於 RunLoop 有5個類:CFRunLoopRef、CFRunLoopModeRef、CFRunLoopSourceRef、CFRunLoopTimerRef、CFRunLoopObserverRef，其中CFRunLoopModeRef類並沒有對外暴露，隻是通過CFRunLoopRef 的接口進行瞭封裝。它們的關系如下:
一個 RunLoop包含若幹個Mode，每個Mode又包含若幹個 Source/Timer/Observer。每次調用RunLoop 的主函數時，隻能指定其中一個Mode，這個Mode被稱作CurrentMode。如果需要切換Mode，隻能退出 Loop，再重新指定一個Mode進入。這樣做主要是為瞭分隔開不同組的 Source/Timer/Observer，讓其互不影響。
CFRunLoopSourceRef 是事件產生的地方。Source有兩個版本：Source0 和 Source1。
Source0 隻包含瞭一個回調（函數指針），它並不能主動觸發事件。使用時，你需要先調用 CFRunLoopSourceSignal(source)，將這個 Source 標記為待處理，然後手動調用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop，讓其處理這個事件。
Source1 包含瞭一個 mach_port和一個回調（函數指針），被用於通過內核和其他線程相互發送消息。這種 Source 能主動喚醒 RunLoop 的線程，其原理在下面會講到。
CFRunLoopTimerRef 是基於時間的觸發器，它和 NSTimer 是toll-free bridged 的，可以混用。其包含一個時間長度和一個回調（函數指針）。當其加入到 RunLoop 時，RunLoop會註冊對應的時間點，當時間點到時，RunLoop會被喚醒以執行那個回調。
CFRunLoopObserverRef 是觀察者，每個Observer 都包含瞭一個回調（函數指針），當 RunLoop的狀態發生變化時，觀察者就能通過回調接受到這個變化。可以觀測的時間點有以下幾個：
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被統稱為mode item，一個item可以被同時加入多個mode。但一個 item 被重復加入同一個mode時是不會有效果的。若一個mode中一個 item都沒有，則RunLoop會直接退出，不進入循環。
二、Runloop使用場景
1.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瞭。
2.定時器
NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 註冊到 RunLoop 後，RunLoop 會為其重復的時間點註冊好事件。eg：10:10, 10:20 這幾個時間點。RunLoop為瞭節省資源，並不會在非常準確的時間點回調這個Timer。Timer有個屬性叫做Tolerance (寬容度)，標示瞭當時間點到後，容許有多少最大誤差。
如果某個時間點被錯過瞭，例如執行瞭一個很長的任務，則那個時間點的回調也會跳過去，不會延後執行。就比如等公交，如果 10:10時我忙著玩手機錯過瞭那個點的公交，那我隻能等 10:20 這一趟瞭。
CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現原理更復雜，和 NSTimer 並不一樣，其內部實際是操作瞭一個 Source）。如果在兩次屏幕刷新之間執行瞭一個長任務，那其中就會有一幀被跳過去（和 NSTimer 相似），造成界面卡頓的感覺。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是為瞭解決界面卡頓的問題，其內部也用到瞭 RunLoop，這個稍後我會再單獨寫一頁博客來分析。
3.PerformSelecter
當調用 NSObject 的 performSelecter:afterDelay: 後，實際上其內部會創建一個 Timer 並添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop，則這個方法會失效。當調用 performSelector:onThread: 時，實際上其會創建一個 Timer 加到對應的線程去，同樣的，如果對應線程沒有 RunLoop 該方法也會失效。
4.事件響應
蘋果註冊瞭一個 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 事件都是在這個回調中完成的。
5.手勢識別
當上面的 _UIApplicationHandleEventQueue() 識別瞭一個手勢時，其首先會調用 Cancel 將當前的 touchesBegin/Move/End 系列回調打斷。隨後系統將對應的 UIGestureRecognizer 標記為待處理。蘋果註冊瞭一個 Observer 監測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回調函數是 _UIGestureRecognizerUpdateObserver()，其內部會獲取所有剛被標記為待處理的 GestureRecognizer，並執行GestureRecognizer的回調。當有 UIGestureRecognizer 的變化(創建/銷毀/狀態改變)時，這個回調都會進行相應處理。
6.界面更新
當在操作 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];
7.關於GCD
實際上 RunLoop 底層也會用到 GCD 的東西。但同時 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 處理的。
8.關於網絡請求
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內部邏輯
由上圖可以看到，實際上RunLoop就是這樣一個函數，其內部是一個 do-while 循環。當你調用CFRunLoopRun() 時，線程就會一直停留在這個循環裡；直到超時或被手動停止，該函數才會返回。<