iOS開發教程之Runloop提示，iosrunloop提示

iOS開發教程之Runloop提示，iosrunloop提示

在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() 時，線程就會一直停留在這個迴圈裡；直到逾時或被手動停止，該函數才會返回。<