史上最全的RunLoop介紹

時間  2019-11-18
標籤 史上 runloop 介紹 简体版
原文   原文鏈接

以前有人在後臺給小編留言，說：小編啥時候給咱們分享RunLoop的一些文章，工做之後特別須要這樣的技術。這不，小編從網上找了一個介紹很是詳細，清晰的文章，僅供參考。前端

RunLoop 是 iOS 和 OSX 開發中很是基礎的一個概念，這篇文章將從 CFRunLoop 的源碼入手，介紹 RunLoop 的概念以及底層實現原理。web

以後會介紹一下在 iOS 中，蘋果是如何利用 RunLoop 實現自動釋放池、延遲迴調、觸摸事件、屏幕刷新等功能的。安全

  • Index網絡

  • RunLoop 的概念架構

  • RunLoop 與線程的關係app

  • RunLoop 對外的接口框架

  • RunLoop 的 Modesocket

  • RunLoop 的內部邏輯async

  • RunLoop 的底層實現函數

  • 蘋果用 RunLoop 實現的功能

  • AutoreleasePool

  • 事件響應

  • 手勢識別

  • 界面更新

  • 定時器

  • PerformSelecter

  • 關於GCD

  • 關於網絡請求

  • RunLoop 的實際應用舉例

  • AFNetworking

  • AsyncDisplayKit

RunLoop 的概念

通常來說，一個線程一次只能執行一個任務，執行完成後線程就會退出。若是咱們須要一個機制，讓線程能隨時處理事件但並不退出，一般的代碼邏輯是這樣的：

這種模型一般被稱做 Event Loop。 Event Loop 在不少系統和框架裏都有實現，好比 Node.js 的事件處理，好比 Windows 程序的消息循環，再好比 OSX/iOS 裏的 RunLoop。

實現這種模型的關鍵點在於：如何管理事件/消息，如何讓線程在沒有處理消息時休眠以免資源佔用、在有消息到來時馬上被喚醒。

因此，RunLoop 實際上就是一個對象，這個對象管理了其須要處理的事件和消息，並提供了一個入口函數來執行上面 Event Loop 的邏輯。

線程執行了這個函數後，就會一直處於這個函數內部 "接受消息->等待->處理" 的循環中，直到這個循環結束（好比傳入 quit 的消息），函數返回。

OSX/iOS 系統中，提供了兩個這樣的對象：NSRunLoop 和CFRunLoopRef。 CFRunLoopRef 是在 CoreFoundation 框架內的，它提供了純 C 函數的 API，全部這些 API 都是線程安全的。

NSRunLoop 是基於 CFRunLoopRef 的封裝，提供了面向對象的 API，可是這些 API 不是線程安全的。

CFRunLoopRef 的代碼是開源的，你能夠在這裏 http://opensource.apple.com/tarballs/CF/CF-855.17.tar.gz 下載到整個 CoreFoundation 的源碼。

爲了方便跟蹤和查看，你能夠新建一個 Xcode 工程，把這堆源碼拖進去看。

RunLoop 與線程的關係

首先，iOS 開發中能遇到兩個線程對象: pthreadt 和 NSThread。過去蘋果有份文檔標明瞭 NSThread 只是 pthreadt 的封裝，但那份文檔已經失效了，如今它們也有可能都是直接包裝自最底層的 mach thread。

蘋果並無提供這兩個對象相互轉換的接口，但無論怎麼樣，能夠確定的是 pthread_t 和 NSThread 是一一對應的。

好比，你能夠經過 pthreadmainthreadnp() 或 [NSThread mainThread] 來獲取主線程；也能夠經過 pthreadself() 或 [NSThread currentThread] 來獲取當前線程。

CFRunLoop 是基於 pthread 來管理的。

蘋果不容許直接建立 RunLoop，它只提供了兩個自動獲取的函數：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 這兩個函數內部的邏輯大概是下面這樣:

/// 全局的Dictionary，key 是 pthreadt， value 是 CFRunLoopRef static CFMutableDictionaryRef loopsDic; /// 訪問 loopsDic 時的鎖 static CFSpinLockt loopsLock;

/// 獲取一個 pthread 對應的 RunLoop。 CFRunLoopRef CFRunLoopGet(pthreadt thread) { OSSpinLockLock(&loopsLock);

if (!loopsDic) {
    // 第一次進入時，初始化全局Dic，並先爲主線程建立一個 RunLoop。
    loopsDic = CFDictionaryCreateMutable();
    CFRunLoopRef mainLoop = _CFRunLoopCreate();
    CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
}

/// 直接從 Dictionary 裏獲取。
CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));

if (!loop) {
    /// 取不到時，建立一個
    loop = _CFRunLoopCreate();
    CFDictionarySetValue(loopsDic, thread, loop);
    /// 註冊一個回調，當線程銷燬時，順便也銷燬其對應的 RunLoop。
    _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
}

OSSpinLockUnLock(&loopsLock);
return loop;

}

CFRunLoopRef CFRunLoopGetMain() { return CFRunLoopGet(pthreadmainthreadnp()); }

CFRunLoopRef CFRunLoopGetCurrent() { return CFRunLoopGet(pthreadself()); } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 /// 全局的Dictionary，key 是 pthreadt， value 是 CFRunLoopRef static CFMutableDictionaryRef loopsDic; /// 訪問 loopsDic 時的鎖 static CFSpinLockt loopsLock;

/// 獲取一個 pthread 對應的 RunLoop。 CFRunLoopRef CFRunLoopGet(pthreadt thread) { OSSpinLockLock(&loopsLock);

if (!loopsDic) {
    // 第一次進入時，初始化全局Dic，並先爲主線程建立一個 RunLoop。
    loopsDic = CFDictionaryCreateMutable();
    CFRunLoopRef mainLoop = _CFRunLoopCreate();
    CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
}

/// 直接從 Dictionary 裏獲取。
CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));

if (!loop) {
    /// 取不到時，建立一個
    loop = _CFRunLoopCreate();
    CFDictionarySetValue(loopsDic, thread, loop);
    /// 註冊一個回調，當線程銷燬時，順便也銷燬其對應的 RunLoop。
    _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
}

OSSpinLockUnLock(&loopsLock);
return loop;

}

CFRunLoopRef CFRunLoopGetMain() { return CFRunLoopGet(pthreadmainthreadnp()); }

CFRunLoopRef CFRunLoopGetCurrent() { return CFRunLoopGet(pthreadself()); }

從上面的代碼能夠看出，線程和 RunLoop 之間是一一對應的，其關係是保存在一個全局的 Dictionary 裏。

線程剛建立時並無 RunLoop，若是你不主動獲取，那它一直都不會有。RunLoop 的建立是發生在第一次獲取時，RunLoop 的銷燬是發生在線程結束時。

你只能在一個線程的內部獲取其 RunLoop（主線程除外）。

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 的狀態發生變化時，觀察者就能經過回調接受到這個變化。能夠觀測的時間點有如下幾個：


上面的 Source/Timer/Observer 被統稱爲 mode item，一個 item 能夠被同時加入多個 mode。

但一個 item 被重複加入同一個 mode 時是不會有效果的。若是一個 mode 中一個 item 都沒有，則 RunLoop 會直接退出，不進入循環。

RunLoop 的 Mode

CFRunLoopMode 和 CFRunLoop 的結構大體以下：

 這裏有個概念叫 "CommonModes"：一個 Mode 能夠將本身標爲"Common"屬性（經過將其 ModeName 添加到 RunLoop 的 "commonModes" 中）。

每當 RunLoop 的內容發生變化時，RunLoop 都會自動將_commonModeItems 裏的 Source/Observer/Timer 同步到具備"Common" 標記的全部Mode裏。

應用場景舉例：主線程的 RunLoop 裏有兩個預置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。

這兩個 Mode 都已經被標記爲"Common"屬性。DefaultMode 是 App 平時所處的狀態，TrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態。

當你建立一個 Timer 並加到 DefaultMode 時，Timer 會獲得重複回調，但此時滑動一個TableView時，RunLoop 會將 mode 切換爲TrackingRunLoopMode，這時 Timer 就不會被回調，而且也不會影響到滑動操做。

有時你須要一個 Timer，在兩個 Mode 中都能獲得回調，一種辦法就是將這個 Timer 分別加入這兩個 Mode。

還有一種方式，就是將 Timer 加入到頂層的 RunLoop 的 "commonModeItems" 中。"commonModeItems" 被 RunLoop 自動更新到全部具備"Common"屬性的 Mode 裏去。

CFRunLoop對外暴露的管理 Mode 接口只有下面2個:

Mode 暴露的管理 mode item 的接口有下面幾個：


你只能經過 mode name 來操做內部的 mode，當你傳入一個新的 mode name 但 RunLoop 內部沒有對應 mode 時，RunLoop會自動幫你建立對應的 CFRunLoopModeRef。對於一個 RunLoop 來講，其內部的 mode 只能增長不能刪除。

蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode，你能夠用這兩個 Mode Name 來操做其對應的 Mode。

同時蘋果還提供了一個操做 Common 標記的字符串：

kCFRunLoopCommonModes (NSRunLoopCommonModes)，你能夠用這個字符串來操做 Common Items，或標記一個 Mode 爲 "Common"。

使用時注意區分這個字符串和其餘 mode name。

RunLoop 的內部邏輯

根據蘋果在文檔裏的說明，RunLoop 內部的邏輯大體以下:

其內部代碼整理以下 （太長了不想看能夠直接跳過去，後面會有說明）：



能夠看到，實際上 RunLoop 就是這樣一個函數，其內部是一個 do-while 循環。當你調用 CFRunLoopRun() 時，線程就會一直停留在這個循環裏；直到超時或被手動中止，該函數纔會返回。

RunLoop 的底層實現

從上面代碼能夠看到，RunLoop 的核心是基於 mach port 的，其進入休眠時調用的函數是 mach_msg()。爲了解釋這個邏輯，下面稍微介紹一下 OSX/iOS 的系統架構。

RunLoop_3

蘋果官方將整個系統大體劃分爲上述4個層次：

  • 應用層包括用戶能接觸到的圖形應用，例如 Spotlight、Aqua、SpringBoard 等。

  • 應用框架層即開發人員接觸到的 Cocoa 等框架。

  • 核心框架層包括各類核心框架、OpenGL 等內容。

  • Darwin 即操做系統的核心，包括系統內核、驅動、Shell 等內容，這一層是開源的，其全部源碼均可以在 opensource.apple.com找到。

     

咱們在深刻看一下 Darwin 這個核心的架構：


其中，在硬件層上面的三個組成部分：Mach、BSD、IOKit (還包括一些上面沒標註的內容)，共同組成了 XNU 內核。

XNU 內核的內環被稱做 Mach，其做爲一個微內核，僅提供了諸如處理器調度、IPC (進程間通訊)等很是少許的基礎服務。

BSD 層能夠看做圍繞 Mach 層的一個外環，其提供了諸如進程管理、文件系統和網絡等功能。

IOKit 層是爲設備驅動提供了一個面向對象(C++)的一個框架。

Mach 自己提供的 API 很是有限，並且蘋果也不鼓勵使用 Mach 的 API，可是這些API很是基礎，若是沒有這些API的話，其餘任何工做都沒法實施。

在 Mach 中，全部的東西都是經過本身的對象實現的，進程、線程和虛擬內存都被稱爲"對象"。

和其餘架構不一樣， Mach 的對象間不能直接調用，只能經過消息傳遞的方式實現對象間的通訊。

"消息"是 Mach 中最基礎的概念，消息在兩個端口 (port) 之間傳遞，這就是 Mach 的 IPC (進程間通訊) 的核心。

Mach 的消息定義是在頭文件的，很簡單：



一條 Mach 消息實際上就是一個二進制數據包 (BLOB)，其頭部定義了當前端口 localport 和目標端口 remoteport，發送和接受消息是經過同一個 API 進行的，其 option 標記了消息傳遞的方向：


 

爲了實現消息的發送和接收，machmsg() 函數其實是調用了一個 Mach 陷阱 (trap)，即函數machmsg_trap()，陷阱這個概念在 Mach 中等同於系統調用。

當你在用戶態調用 machmsgtrap() 時會觸發陷阱機制，切換到內核態；內核態中內核實現的 mach_msg() 函數會完成實際的工做，以下圖：

這些概念能夠參考維基百科: Systemcall、Trap(computing)。

RunLoop 的核心就是一個 mach_msg() (見上面代碼的第7步)，RunLoop 調用這個函數去接收消息，若是沒有別人發送 port 消息過來，內核會將線程置於等待狀態。

例如你在模擬器裏跑起一個 iOS 的 App，而後在 App 靜止時點擊暫停，你會看到主線程調用棧是停留在 machmsgtrap() 這個地方。

關於具體的如何利用 mach port 發送信息，能夠看看 NSHipster 這一篇文章，或者這裏的中文翻譯 。

關於Mach的歷史能夠看看這篇頗有趣的文章：Mac OS X 背後的故事（三）Mach 之父 Avie Tevanian。

蘋果用 RunLoop 實現的功能

首先咱們能夠看一下 App 啓動後 RunLoop 的狀態：



能夠看到，系統默認註冊了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), 當你在你的代碼中下斷點調試時，一般能在調用棧上看到這些函數。

下面是這幾個函數的整理版本，若是你在調用棧中看到這些長函數名，在這裏查找一下就能定位到具體的調用地點了：


AutoreleasePool

App啓動後，蘋果在主線程 RunLoop 裏註冊了兩個 Observer，其回調都是 _wrapRunLoopWithAutoreleasePoolHandler()。

第一個 Observer 監視的事件是 Entry(即將進入Loop)，其回調內會調用 objcautoreleasePoolPush() 建立自動釋放池。

其 order 是-2147483647，優先級最高，保證建立釋放池發生在其餘全部回調以前。

第二個 Observer 監視了兩個事件： BeforeWaiting(準備進入休眠) 時調用objcautoreleasePoolPop() 和 objcautoreleasePoolPush() 釋放舊的池並建立新池；Exit(即將退出Loop) 時調用 objcautoreleasePoolPop() 來釋放自動釋放池。

這個 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) 事件，回調去執行一個很長的函數：ZN2CA11Transaction17observercallbackEP19__CFRunLoopObservermPv()。這個函數裏會遍歷全部待處理的 UIView/CAlayer 以執行實際的繪製和調整，並更新 UI 界面。

這個函數內部的調用棧大概是這樣的：

定時器

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 是用 dispatchsourcet 實現的 Timer。但同時 GCD 提供的某些接口也用到了 RunLoop， 例如 dispatch_async()。

當調用 dispatchasync(dispatchgetmainqueue(), block) 時，libDispatch 會向主線程的 RunLoop 發送消息，RunLoop會被喚醒，並從消息中取得這個 block，並在回調 CFRUNLOOPISSERVICINGTHEMAINDISPATCHQUEUE() 裏執行這個 block。但這個邏輯僅限於 dispatch 到主線程，dispatch 到其餘線程仍然是由 libDispatch 處理的。

關於網絡請求

iOS 中，關於網絡請求的接口自下至上有以下幾層:

• 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：

RunLoop 啓動前內部必需要有至少一個 Timer/Observer/Source，因此 AFNetworking 在 [runLoop run] 以前先建立了一個新的 NSMachPort 添加進去了。

一般狀況下，調用者須要持有這個 NSMachPort (mach_port) 並在外部線程經過這個 port 發送消息到 loop 內；但此處添加 port 只是爲了讓 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 事件，在收到回調時，遍歷全部以前放入隊列的待處理的任務，而後一一執行。 具體的代碼能夠看這裏：_ASAsyncTransactionGroup。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程