注：本篇博客只在 ibireme 的 深入理解RunLoop 基礎上做了點方便自己復習該知識點的修改渗蟹，能力有限，如果有理解的不對的地方，還希望能幫忙指出嫡丙。

首先了解一下程序、進程和線程

程序本身只是指令读第、數(shù)據(jù)及其組織形式的描述曙博，進程才是程序（那些指令和數(shù)據(jù)）的真正運行實例。而線程是操作系統(tǒng)能夠進行運算調(diào)度的最小單位怜瞒。它被包含在進程之中父泳，是進程中的實際運作單位。一條線程指的是進程中一個單一順序的控制流吴汪，一個進程中可以并發(fā)多個線程惠窄，每條線程并行執(zhí)行不同的任務。

一般來說浇坐，一個線程一次只能執(zhí)行一個任務睬捶，執(zhí)行完成后線程就會退出。所以程序運行的時候近刘，需要一個機制擒贸，讓線程能隨時處理事件但不退出。

以前寫游戲的時候就寫過這樣的東西觉渴，通常是一個 do while 循環(huán)介劫，讓程序一直運轉(zhuǎn)，直到接收到退出信息案淋。

而 RunLoop 就是讓線程在沒有處理消息時休眠以避免資源占用座韵，在有消息到來時立刻被喚醒。

線程和 RunLoop 之間是一一對應的踢京，其關系是保存在一個全局的 Dictionary 里誉碴。線程剛創(chuàng)建時默認是沒有 RunLoop，如果你不主動獲取瓣距，那它一直都不會有黔帕。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時，RunLoop 的銷毀是發(fā)生在線程結(jié)束時蹈丸。你只能在一個線程的內(nèi)部獲取其 RunLoop（主線程除外）成黄。

在 CoreFoundation 里面關于 RunLoop 有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 只包含一個函數(shù)指針霎箍，并不能主動觸發(fā)奇钞，需要將 Source0 標記為待處理，在 RunLoop 運轉(zhuǎn)的時候漂坏，才會處理這個事件（如果 RunLoop 處于休眠狀態(tài)景埃，則不會被喚醒去處理），而 Source1 包含了一個 mach_port 和一個函數(shù)指針顶别，mach_port 是 iOS 系統(tǒng)提供的基于端口的輸入源谷徙，可用于線程或進程間通訊。而 RunLoop 支持的輸入源類型中就包括基于端口的輸入源驯绎，可以做到對 mach_port 端口源事件的監(jiān)聽完慧。所以監(jiān)聽到 source1 端口的消息時，RunLoop 就會自己醒來去執(zhí)行 Source1 事件（也能稱為被消息喚醒）剩失。也就是 Source0 是直接添加給 RunLoop 處理的事件屈尼，而 Source1 是基于端口的，進程或線程之間傳遞消息觸發(fā)的事件（為什么要 0 和 1 來命名拴孤，每次都記不住脾歧，GG）。

Timer 是基于時間的觸發(fā)器演熟，CFRunLoopTimerRef 和 NSTimer 可以通過 Toll-free bridging 技術混用鞭执，Toll-free bridging 是一種允許某些 ObjC 類與其對應的 CoreFoundation 類之間可以互換使用的機制，當將 Timer 加入到 RunLoop 時芒粹，RunLoop 會注冊對應的時間點兄纺，當時間點到時，RunLoop 會被喚醒以執(zhí)行 Timer 回調(diào)化漆。

Observer（觀察者）都包含了一個回調(diào)（函數(shù)指針）估脆，當 RunLoop 的狀態(tài)發(fā)生變化時，觀察者就能通過回調(diào)接受到這個變化获三∨园可以觀測的時間點有以下幾個：

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 執(zhí)行一些其他的任務。

上面的 Source/Timer/Observer 被統(tǒng)稱為 mode item疙教，一個 item 可以被同時加入多個 mode棺聊。但一個 item 被重復加入同一個 mode 時是不會有效果的。如果一個 mode 中一個 item 都沒有贞谓，則 RunLoop 會直接退出限佩，不進入循環(huán)。

RunLoop 的 CFRunLoopMode 和 CFRunLoop 的結(jié)構大致如下：

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<Source/Observer/Timer>
    CFRunLoopModeRef _currentMode;    // Current Runloop Mode
    CFMutableSetRef _modes;           // Set
    ...
};

這里有個概念叫 "CommonModes"：一個 Mode 可以將自己標記為"Common"屬性（通過將其 ModeName 添加到 RunLoop 的 "commonModes" 中）裸弦。每當 RunLoop 的內(nèi)容發(fā)生變化時祟同，RunLoop 都會自動將 _commonModeItems 里的 Source/Observer/Timer 同步到具有 "Common" 標記的所有Mode里。

如上文說的 RunLoop 一次循環(huán)只能運行在一個 Mode 下理疙，是為了分隔開不同組的 Source/Timer/Observer晕城，讓其互不影響。但如果一個 Source/Timer/Observer 想在多個 Mode 下運作窖贤，則可以分別加入到多個 Mode砖顷，或者給兩個 Mode 添加 "Common" 標記，再將 Source/Timer/Observer 加入到 RunLoop 的 "commonModeItems" 赃梧。

應用場景舉例：主線程的 RunLoop 里有兩個預置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode滤蝠。這兩個 Mode 都已經(jīng)被標記為"Common"屬性。DefaultMode 是 App 平時所處的狀態(tài)授嘀，TrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態(tài)物咳。當你創(chuàng)建一個 Timer 并加到 DefaultMode 時，Timer 會得到重復回調(diào)蹄皱，但此時滑動一個TableView時览闰，RunLoop 會將 mode 切換為 TrackingRunLoopMode，這時 Timer 就不會被回調(diào)巷折，如果想讓它回調(diào)則可以將這個 Timer 分別加入這兩個 Mode焕济。或?qū)?Timer 加入到頂層的 RunLoop 的 "commonModeItems" 盔几。

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

CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);

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

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 內(nèi)部沒有對應 mode 時上鞠，RunLoop會自動幫你創(chuàng)建對應的 CFRunLoopModeRef。

接下來看 RunLoop 的執(zhí)行邏輯

按 1 - 10 來理理芯丧，首先要知道 Observer 是觀察者芍阎，也就是下面這幾種狀態(tài)都會通知觀察者，開發(fā)者也添加一個觀察者缨恒，去在以下幾種狀態(tài)的時候谴咸，執(zhí)行一些任務轮听，比如將沒啥實時性要求的東西，在即將進入休眠狀態(tài)時執(zhí)行岭佳。

    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 回調(diào)，這個通知每次 Loop 循環(huán)都會調(diào)用珊随，但 Timer 只有在注冊的時間到了才會在第 9 步去執(zhí)行述寡，第 4 步處理運行的 mode 里待處理的 Source0，其中第 5 步會判斷 mode item 里是否有 Source1 處于 ready 狀態(tài)（也就是 Source1 的端口已經(jīng)收到消息）叶洞，有的話跳到第 9 步鲫凶，處理 Source1 事件，然后進入下一個循環(huán)衩辟，沒有的話說明 mode item 里的事件都處理完畢螟炫，線程進入休眠狀態(tài)，等待 Source1艺晴，Timer 或者外部手動將 RunLoop 喚醒（上文說 Source0 并不能喚醒 RunLoop不恭，所以一般會通過手動喚醒 RunLoop，來讓 RunLoop 處理新加入進去的 Source0）财饥。

可以看到换吧，實際上 RunLoop 就是這樣一個函數(shù)，其內(nèi)部是一個 do-while 循環(huán)钥星。當你調(diào)用 CFRunLoopRun() 時沾瓦，線程就會一直停留在這個循環(huán)里，去執(zhí)行加入到 RunLoop 里的 Source0谦炒，Timer 的回調(diào)贯莺，以及 Observer 回調(diào)，以及用于線程或進程間通訊的 Source1宁改，當所有的都處理完之后缕探，結(jié)束一次循環(huán)，進入休眠狀態(tài)还蹲，休眠的時候等待 Timer 注冊的時間點或者 Source1 喚醒 RunLoop（也可以手動喚醒）爹耗。

從上面我們可以了解，線程和進程之間的通訊是基于 mach port 傳遞消息實現(xiàn)的谜喊，這也是 RunLoop 的核心潭兽。有必要了解一下 mach port， OSX/iOS 的系統(tǒng)架構分為 4 層斗遏，從外到內(nèi)為應用層山卦，應用框架層，核心框架層诵次，Darwin账蓉。應用層包括用戶能接觸到的圖形應用枚碗，應用框架層即開發(fā)人員接觸到的 Cocoa 等框架，核心框架層包括各種核心框架铸本、OpenGL 等內(nèi)容肮雨，Darwin 即操作系統(tǒng)的核心，包括系統(tǒng)內(nèi)核归敬、驅(qū)動、Shell 等內(nèi)容鄙早。

Darwin 核心的架構：

圖片.png

其中汪茧，在硬件層上面的三個組成部分：Mach、BSD限番、IOKit (還包括一些上面沒標注的內(nèi)容)舱污，共同組成了 XNU 內(nèi)核。

XNU 內(nèi)核的內(nèi)環(huán)被稱作 Mach弥虐，其作為一個微內(nèi)核扩灯，僅提供了諸如處理器調(diào)度、IPC (進程間通信)等非常少量的基礎服務霜瘪。

BSD 層可以看作圍繞 Mach 層的一個外環(huán)珠插，其提供了諸如進程管理、文件系統(tǒng)和網(wǎng)絡等功能颖对。
IOKit 層是為設備驅(qū)動提供了一個面向?qū)ο?C++)的一個框架捻撑。

在 Mach 中，進程缤底、線程和虛擬內(nèi)存都被稱為"對象"顾患。Mach 的對象間不能直接調(diào)用，只能通過消息傳遞的方式實現(xiàn)對象間的通信个唧。"消息"是 Mach 中最基礎的概念江解，消息在兩個端口 (port) 之間傳遞，這就是 Mach 的 IPC (進程間通信) 的核心徙歼。

Mach 中的對象通過一個 Mach 端口發(fā)送一個消息犁河，消息中會攜帶目標端口，這個消息會從用戶空間傳遞到內(nèi)核空間魄梯，再由內(nèi)核空間傳遞到目標端口呼股，實現(xiàn)線程或進程之間的通訊。（也就是線程或進程之間的通訊不能繞過系統(tǒng)內(nèi)核）画恰。目標端口接收到消息彭谁，因為 RunLoop 會對 mach_port 端口源進行監(jiān)聽，如果 RunLoop 此時處于休眠狀態(tài)允扇，則被喚醒缠局，便可以處理已經(jīng)接收到消息的 source1 事件则奥。

RunLoop 實現(xiàn)了很多功能

啟動后，系統(tǒng)默認注冊了5個Mode:

1：kCFRunLoopDefaultMode: App的默認 Mode狭园，通常主線程是在這個 Mode 下運行的读处。

2：UITrackingRunLoopMode: 界面跟蹤 Mode，用于 ScrollView 追蹤觸摸滑動唱矛，保證界面滑動時不受其他 Mode 影響罚舱。

3：UIInitializationRunLoopMode: 在剛啟動 App 時第進入的第一個 Mode，啟動完成后就不再使用绎谦。

4：GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內(nèi)部 Mode管闷，通常用不到。

5：kCFRunLoopCommonModes: 這是一個占位的 Mode窃肠，沒有實際作用包个。

AutoreleasePool

App啟動后，蘋果在主線程 RunLoop 里注冊了兩個 Observer冤留，其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()（因為需要設置不同的優(yōu)先級碧囊，所以注冊兩個）。

第一個 Observer 監(jiān)視的事件是 Entry(即將進入Loop)纤怒，用來創(chuàng)建自動釋放池糯而，且設置的優(yōu)先級最高，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前泊窘。

第二個 Observer 監(jiān)視了兩個事件： BeforeWaiting(準備進入休眠) 時去釋放舊的池并創(chuàng)建新池歧蒋；Exit(即將退出Loop) 時釋放自動釋放池。這個 Observer 的優(yōu)先級最低州既，保證其釋放池子發(fā)生在其他所有回調(diào)之后谜洽。

在主線程執(zhí)行的代碼，通常是寫在諸如事件回調(diào)吴叶、Timer 回調(diào)內(nèi)的阐虚。這些回調(diào)會被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著，所以不會出現(xiàn)內(nèi)存泄漏蚌卤。

事件響應

蘋果注冊了一個 Source1 (基于 mach port 的) 用來接收系統(tǒng)事件实束，其回調(diào)函數(shù)為 __IOHIDEventSystemClientQueueCallback()。

當一個硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后逊彭，首先由 IOKit.framework 生成一個 IOHIDEvent 事件并由 SpringBoard 接收咸灿。隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進程。隨后蘋果注冊的那個 Source1 就會觸發(fā)回調(diào)侮叮，并調(diào)用 _UIApplicationHandleEventQueue() 進行應用內(nèi)部的事件傳遞避矢。

_UIApplicationHandleEventQueue() 會把 IOHIDEvent 處理并包裝成 UIEvent 進行處理或分發(fā)，其中包括識別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等。通常事件比如 UIButton 點擊审胸、touchesBegin/Move/End/Cancel 事件都是在這個回調(diào)中完成的亥宿。

手勢識別

當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會調(diào)用 Cancel 將當前的 touchesBegin/Move/End 系列回調(diào)打斷砂沛。隨后系統(tǒng)將對應的 UIGestureRecognizer 標記為待處理烫扼。

蘋果注冊了一個 Observer 監(jiān)測 BeforeWaiting (Loop即將進入休眠) 事件，這個 Observer 的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()碍庵，其內(nèi)部會獲取所有剛被標記為待處理的 GestureRecognizer映企，并執(zhí)行 GestureRecognizer 的回調(diào)。

當有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時静浴，這個回調(diào)都會進行相應處理堰氓。

界面更新

當在操作 UI 時，比如改變了 Frame马绝、更新了 UIView/CALayer 的層次時豆赏，或者手動調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay 方法后挣菲，這個 UIView/CALayer 就被標記為待處理富稻，并被提交到一個全局的容器去。

蘋果注冊了一個 Observer 監(jiān)聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件白胀，回調(diào)去執(zhí)行一個很長的函數(shù)：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()椭赋。這個函數(shù)里會遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實際的繪制和調(diào)整，并更新 UI 界面或杠。也就是 UI 是在界面 RunLoop 休眠之前更新的哪怔，所以如果想在 UI 更新之后做一些事情，可以注冊一個 Observer 監(jiān)聽 kCFRunLoopAfterWaiting(剛從休眠中喚醒)向抢。

定時器

NSTimer 其實就是 CFRunLoopTimerRef认境，他們之間是 toll-free bridged 的。一個 NSTimer 注冊到 RunLoop 后挟鸠，RunLoop 會為其重復的時間點注冊好事件叉信。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節(jié)省資源艘希，并不會在非常準確的時間點回調(diào)這個Timer硼身。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到后覆享，容許有多少最大誤差佳遂。

如果某個時間點被錯過了，例如執(zhí)行了一個很長的任務撒顿，則那個時間點的回調(diào)也會跳過去丑罪，不會延后執(zhí)行。

CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復雜，和 NSTimer 并不一樣巍糯，其內(nèi)部實際是操作了一個 Source）啸驯。如果在兩次屏幕刷新之間執(zhí)行了一個長任務，那其中就會有一幀被跳過去（和 NSTimer 相似）祟峦，造成界面卡頓的感覺罚斗。

PerformSelecter

當調(diào)用 NSObject 的 performSelecter:afterDelay: 后，實際上其內(nèi)部會創(chuàng)建一個 Timer 并添加到當前線程的 RunLoop 中宅楞。所以如果當前線程沒有 RunLoop针姿，則這個方法會失效。

當調(diào)用 performSelector:onThread: 時厌衙，實際上其會創(chuàng)建一個 Timer 加到對應的線程去距淫，同樣的，如果對應線程沒有 RunLoop 該方法也會失效婶希。

GCD

當調(diào)用 dispatch_async(dispatch_get_main_queue(), block) 時榕暇，libDispatch 會向主線程的 RunLoop 發(fā)送消息，RunLoop會被喚醒喻杈，并從消息中取得這個 block揽思，并在回調(diào) CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里執(zhí)行這個 block矾飞。但這個邏輯僅限于 dispatch 到主線程收厨，dispatch 到其他線程仍然是由 libDispatch 處理的羹呵。

網(wǎng)絡請求

iOS 中，關于網(wǎng)絡請求的接口自下至上有如下幾層:

CFSocket
CFNetwork       ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession    ->AFNetworking2, Alamofire

通常使用 NSURLConnection 時瓷们，你會傳入一個 Delegate业栅，當調(diào)用了 [connection start] 后，這個 Delegate 就會不停收到事件回調(diào)谬晕。實際上碘裕，start 這個函數(shù)的內(nèi)部會會獲取 CurrentRunLoop，然后在其中的 DefaultMode 添加了多個需要手動觸發(fā)的 Source0攒钳。

當開始網(wǎng)絡傳輸時帮孔，NSURLConnection 創(chuàng)建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的夕玩。NSURLConnectionLoader 這個線程內(nèi)部會使用 RunLoop 基于 mach port 的 Source1 接收來自底層 CFSocket 的消息你弦，當收到消息后，其會在合適的時機將 Source0 標記為待處理燎孟，同時喚醒 Delegate 線程的 RunLoop 來讓其處理 Source0禽作。完成一個由 CFSocket 線程到網(wǎng)絡請求所在線程的數(shù)據(jù)處理。

AFNetworking

AFURLConnectionOperation 這個類是基于 NSURLConnection 構建的揩页，其希望能在后臺線程接收 Delegate 回調(diào)旷偿。為此 AFNetworking 創(chuàng)建了一個線程，并在這個線程中啟動了一個 RunLoop，RunLoop 啟動前內(nèi)部必須要有至少一個 Timer/Observer/Source萍程，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個新的 NSMachPort 添加進去了幢妄。只是為了讓 RunLoop 不至于退出，并沒有用于實際的發(fā)送消息茫负。當需要這個后臺線程執(zhí)行網(wǎng)絡請求任務時蕉鸳，AFNetworking 通過調(diào)用 [NSObject performSelector:onThread:..] 將這個任務扔到了該線程的 RunLoop 中。

AsyncDisplayKit

AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架忍法，其原理大致如下：

UI 線程中一旦出現(xiàn)繁重的任務就會導致界面卡頓潮尝，這類任務通常分為3類：排版，繪制饿序，UI對象操作勉失。

排版通常包括計算視圖大小、計算文本高度原探、重新計算子式圖的排版等操作乱凿。
繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預先解壓)咽弦、元素繪制 (Quartz)等操作徒蟆。
UI對象操作通常包括 UIView/CALayer 等 UI 對象的創(chuàng)建、設置屬性和銷毀离唬。

其中前兩類操作可以通過各種方法扔到后臺線程執(zhí)行后专，而最后一類操作只能在主線程完成划鸽，并且有時后面的操作需要依賴前面操作的結(jié)果 （例如TextView創(chuàng)建時可能需要提前計算出文本的大惺漭骸）。ASDK 所做的裸诽，就是盡量將能放入后臺的任務放入后臺嫂用，不能的則盡量推遲 (例如視圖的創(chuàng)建、屬性的調(diào)整)丈冬。

為此嘱函，ASDK 創(chuàng)建了一個名為 ASDisplayNode 的對象，并在內(nèi)部封裝了 UIView/CALayer埂蕊，它具有和 UIView/CALayer 相似的屬性往弓，例如 frame、backgroundColor 等蓄氧。所有這些屬性都可以在后臺線程更改函似，開發(fā)者可以只通過 Node 來操作其內(nèi)部的 UIView/CALayer，這樣就可以將排版和繪制放入了后臺線程喉童。但是無論怎么操作撇寞，這些屬性總需要在某個時刻同步到主線程的 UIView/CALayer 去。

ASDK 仿照 QuartzCore/UIKit 框架的模式，實現(xiàn)了一套類似的界面更新的機制：即在主線程的 RunLoop 中添加一個 Observer蔑担，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件牌废，在收到回調(diào)時，遍歷所有之前放入隊列的待處理的任務（需要將 Node 的屬性同步到主線程的 UIView/CALayer 去的任務）啤握，然后一一執(zhí)行鸟缕。

總結(jié)：

ibireme 的 深入理解RunLoop 前前后后我看了好幾遍，每次都看的不深入排抬，總是瞬時了解叁扫，睡一覺就記不清楚細節(jié)了，這次自己逐行去理解畜埋，并寫下來莫绣，加上點自己的理解，也寫了點代碼去觀察 RunLoop悠鞍，算是對 RunLoop 的理解更加深入了对室。