RunLoop 是 iOS 和 OS X 開發(fā)中非常基礎(chǔ)的一個(gè)概念，這篇文章將從 CFRunLoop 的源碼入手，介紹 RunLoop 的概念以及底層實(shí)現(xiàn)原理。之后會(huì)介紹一下在 iOS 中，蘋果是如何利用 RunLoop 實(shí)現(xiàn)自動(dòng)釋放池、延遲回調(diào)、觸摸事件、屏幕刷新等功能的。

目錄

• RunLoop 的概念

• RunLoop 與線程的關(guān)系

• RunLoop 對(duì)外的接口

• RunLoop 的 Mode

• RunLoop 的內(nèi)部邏輯

• RunLoop 的底層實(shí)現(xiàn)

• 蘋果用 RunLoop 實(shí)現(xiàn)的功能

  • AutoreleasePool

  • 事件響應(yīng)

  • 手勢(shì)識(shí)別

  • 界面更新

  • 定時(shí)器

  • PerformSelecter

  • 關(guān)于GCD

  • 關(guān)于網(wǎng)絡(luò)請(qǐng)求

• RunLoop 的實(shí)際應(yīng)用舉例

  • AFNetworking

  • AsyncDisplayKit

RunLoop 的概念

一般來(lái)講，一個(gè)線程一次只能執(zhí)行一個(gè)任務(wù)，執(zhí)行完成后線程就會(huì)退出。如果我們需要一個(gè)機(jī)制，讓線程能隨時(shí)處理事件但并不退出，通常的代碼邏輯是這樣的：

1 2 3 4 5 6 7

function? loop()?{ ???? initialize(); ???? do? { ???????? var? message?=?get_next_message(); ???????? process_message(message); ???? }? while? (message?!=?quit); }

這種模型通常被稱作?Event Loop。 Event Loop 在很多系統(tǒng)和框架里都有實(shí)現(xiàn)，比如 Node.js 的事件處理，比如 Windows 程序的消息循環(huán)，再比如 OSX/iOS 里的 RunLoop。實(shí)現(xiàn)這種模型的關(guān)鍵點(diǎn)在于：如何管理事件/消息，如何讓線程在沒(méi)有處理消息時(shí)休眠以避免資源占用、在有消息到來(lái)時(shí)立刻被喚醒。

所以，RunLoop 實(shí)際上就是一個(gè)對(duì)象，這個(gè)對(duì)象管理了其需要處理的事件和消息，并提供了一個(gè)入口函數(shù)來(lái)執(zhí)行上面 Event Loop 的邏輯。線程執(zhí)行了這個(gè)函數(shù)后，就會(huì)一直處于這個(gè)函數(shù)內(nèi)部 "接受消息->等待->處理" 的循環(huán)中，直到這個(gè)循環(huán)結(jié)束（比如傳入 quit 的消息），函數(shù)返回。

OSX/iOS 系統(tǒng)中，提供了兩個(gè)這樣的對(duì)象：NSRunLoop 和 CFRunLoopRef。

CFRunLoopRef 是在 CoreFoundation 框架內(nèi)的，它提供了純 C 函數(shù)的 API，所有這些 API 都是線程安全的。

NSRunLoop 是基于 CFRunLoopRef 的封裝，提供了面向?qū)ο蟮?API，但是這些 API 不是線程安全的。

CFRunLoopRef 的代碼是開源的，你可以在這里?http://opensource.apple.com/tarballs/CF/CF-855.17.tar.gz?下載到整個(gè) CoreFoundation 的源碼。為了方便跟蹤和查看，你可以新建一個(gè) Xcode 工程，把這堆源碼拖進(jìn)去看。

RunLoop 與線程的關(guān)系

首先，iOS 開發(fā)中能遇到兩個(gè)線程對(duì)象: pthread_t 和 NSThread。過(guò)去蘋果有份文檔標(biāo)明了 NSThread 只是 pthread_t 的封裝，但那份文檔已經(jīng)失效了，現(xiàn)在它們也有可能都是直接包裝自最底層的 mach thread。蘋果并沒(méi)有提供這兩個(gè)對(duì)象相互轉(zhuǎn)換的接口，但不管怎么樣，可以肯定的是 pthread_t 和 NSThread 是一一對(duì)應(yīng)的。比如，你可以通過(guò) pthread_main_np() 或 [NSThread mainThread] 來(lái)獲取主線程；也可以通過(guò) pthread_self() 或 [NSThread currentThread] 來(lái)獲取當(dāng)前線程。CFRunLoop 是基于 pthread 來(lái)管理的。

蘋果不允許直接創(chuàng)建 RunLoop，它只提供了兩個(gè)自動(dòng)獲取的函數(shù)：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 這兩個(gè)函數(shù)內(nèi)部的邏輯大概是下面這樣:

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?是?pthread_t，?value?是?CFRunLoopRef static?CFMutableDictionaryRef?loopsDic; ///?訪問(wèn)?loopsDic?時(shí)的鎖 static?CFSpinLock_t?loopsLock; ?? ///?獲取一個(gè)?pthread?對(duì)應(yīng)的?RunLoop。 CFRunLoopRef?_CFRunLoopGet(pthread_t?thread)?{ ???? OSSpinLockLock(&loopsLock); ????? ???? if? (!loopsDic)?{ ???????? //?第一次進(jìn)入時(shí)，初始化全局Dic，并先為主線程創(chuàng)建一個(gè)?RunLoop。 ???????? loopsDic?=?CFDictionaryCreateMutable(); ???????? CFRunLoopRef?mainLoop?=?_CFRunLoopCreate(); ???????? CFDictionarySetValue(loopsDic,?pthread_main_thread_np(),?mainLoop); ???? } ????? ???? ///?直接從?Dictionary?里獲取。 ???? CFRunLoopRef?loop?=?CFDictionaryGetValue(loopsDic,?thread)); ????? ???? if? (!loop)?{ ???????? ///?取不到時(shí)，創(chuàng)建一個(gè) ???????? loop?=?_CFRunLoopCreate(); ???????? CFDictionarySetValue(loopsDic,?thread,?loop); ???????? ///?注冊(cè)一個(gè)回調(diào)，當(dāng)線程銷毀時(shí)，順便也銷毀其對(duì)應(yīng)的?RunLoop。 ???????? _CFSetTSD(...,?thread,?loop,?__CFFinalizeRunLoop); ???? } ????? ???? OSSpinLockUnLock(&loopsLock); ???? return? loop; } ?? CFRunLoopRef?CFRunLoopGetMain()?{ ???? return? _CFRunLoopGet(pthread_main_thread_np()); } ?? CFRunLoopRef?CFRunLoopGetCurrent()?{ ???? return? _CFRunLoopGet(pthread_self()); }

從上面的代碼可以看出，線程和 RunLoop 之間是一一對(duì)應(yīng)的，其關(guān)系是保存在一個(gè)全局的 Dictionary 里。線程剛創(chuàng)建時(shí)并沒(méi)有 RunLoop，如果你不主動(dòng)獲取，那它一直都不會(huì)有。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時(shí)，RunLoop 的銷毀是發(fā)生在線程結(jié)束時(shí)。你只能在一個(gè)線程的內(nèi)部獲取其 RunLoop（主線程除外）。

RunLoop 對(duì)外的接口

在 CoreFoundation 里面關(guān)于 RunLoop 有5個(gè)類:

• CFRunLoopRef

• CFRunLoopModeRef

• CFRunLoopSourceRef

• CFRunLoopTimerRef

• CFRunLoopObserverRef

其中 CFRunLoopModeRef 類并沒(méi)有對(duì)外暴露，只是通過(guò) CFRunLoopRef 的接口進(jìn)行了封裝。他們的關(guān)系如下:

一個(gè) RunLoop 包含若干個(gè) Mode，每個(gè) Mode 又包含若干個(gè) Source/Timer/Observer。每次調(diào)用 RunLoop 的主函數(shù)時(shí)，只能指定其中一個(gè) Mode，這個(gè)Mode被稱作 CurrentMode。如果需要切換 Mode，只能退出 Loop，再重新指定一個(gè) Mode 進(jìn)入。這樣做主要是為了分隔開不同組的 Source/Timer/Observer，讓其互不影響。

CFRunLoopSourceRef?是事件產(chǎn)生的地方。Source有兩個(gè)版本：Source0 和 Source1。

• Source0 只包含了一個(gè)回調(diào)（函數(shù)指針），它并不能主動(dòng)觸發(fā)事件。使用時(shí)，你需要先調(diào)用 CFRunLoopSourceSignal(source)，將這個(gè) Source 標(biāo)記為待處理，然后手動(dòng)調(diào)用 CFRunLoopWakeUp(runloop) 來(lái)喚醒 RunLoop，讓其處理這個(gè)事件。

• Source1 包含了一個(gè) mach_port 和一個(gè)回調(diào)（函數(shù)指針），被用于通過(guò)內(nèi)核和其他線程相互發(fā)送消息。這種 Source 能主動(dòng)喚醒 RunLoop 的線程，其原理在下面會(huì)講到。

CFRunLoopTimerRef?是基于時(shí)間的觸發(fā)器，它和 NSTimer 是toll-free bridged 的，可以混用。其包含一個(gè)時(shí)間長(zhǎng)度和一個(gè)回調(diào)（函數(shù)指針）。當(dāng)其加入到 RunLoop 時(shí)，RunLoop會(huì)注冊(cè)對(duì)應(yīng)的時(shí)間點(diǎn)，當(dāng)時(shí)間點(diǎn)到時(shí)，RunLoop會(huì)被喚醒以執(zhí)行那個(gè)回調(diào)。

CFRunLoopObserverRef?是觀察者，每個(gè) Observer 都包含了一個(gè)回調(diào)（函數(shù)指針），當(dāng) RunLoop 的狀態(tài)發(fā)生變化時(shí)，觀察者就能通過(guò)回調(diào)接受到這個(gè)變化。可以觀測(cè)的時(shí)間點(diǎn)有以下幾個(gè)：

1 2 3 4 5 6 7 8

typedef?CF_OPTIONS(CFOptionFlags,?CFRunLoopActivity)?{ ???? kCFRunLoopEntry?????????=?(1UL?<<?0),? //?即將進(jìn)入Loop ???? kCFRunLoopBeforeTimers??=?(1UL?<<?1),? //?即將處理?Timer ???? kCFRunLoopBeforeSources?=?(1UL?<<?2),? //?即將處理?Source ???? kCFRunLoopBeforeWaiting?=?(1UL?<<?5),? //?即將進(jìn)入休眠 ???? kCFRunLoopAfterWaiting??=?(1UL?<<?6),? //?剛從休眠中喚醒 ???? kCFRunLoopExit??????????=?(1UL?<<?7),? //?即將退出Loop };

上面的 Source/Timer/Observer 被統(tǒng)稱為 mode item，一個(gè) item 可以被同時(shí)加入多個(gè) mode。但一個(gè) item 被重復(fù)加入同一個(gè) mode 時(shí)是不會(huì)有效果的。如果一個(gè) mode 中一個(gè) item 都沒(méi)有，則 RunLoop 會(huì)直接退出，不進(jìn)入循環(huán)。

RunLoop 的 Mode

CFRunLoopMode 和 CFRunLoop 的結(jié)構(gòu)大致如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

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

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

應(yīng)用場(chǎng)景舉例：主線程的 RunLoop 里有兩個(gè)預(yù)置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。這兩個(gè) Mode 都已經(jīng)被標(biāo)記為"Common"屬性。DefaultMode 是 App 平時(shí)所處的狀態(tài)，TrackingRunLoopMode 是追蹤 ScrollView 滑動(dòng)時(shí)的狀態(tài)。當(dāng)你創(chuàng)建一個(gè) Timer 并加到 DefaultMode 時(shí)，Timer 會(huì)得到重復(fù)回調(diào)，但此時(shí)滑動(dòng)一個(gè)TableView時(shí)，RunLoop 會(huì)將 mode 切換為 TrackingRunLoopMode，這時(shí) Timer 就不會(huì)被回調(diào)，并且也不會(huì)影響到滑動(dòng)操作。

有時(shí)你需要一個(gè) Timer，在兩個(gè) Mode 中都能得到回調(diào)，一種辦法就是將這個(gè) Timer 分別加入這兩個(gè) Mode。還有一種方式，就是將 Timer 加入到頂層的 RunLoop 的 "commonModeItems" 中。"commonModeItems" 被 RunLoop 自動(dòng)更新到所有具有"Common"屬性的 Mode 里去。

CFRunLoop對(duì)外暴露的管理 Mode 接口只有下面2個(gè):

1 2	CFRunLoopAddCommonMode(CFRunLoopRef?runloop,?CFStringRef?modeName); CFRunLoopRunInMode(CFStringRef?modeName,?...);

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

1 2 3 4 5 6

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);

你只能通過(guò) mode name 來(lái)操作內(nèi)部的 mode，當(dāng)你傳入一個(gè)新的 mode name 但 RunLoop 內(nèi)部沒(méi)有對(duì)應(yīng) mode 時(shí)，RunLoop會(huì)自動(dòng)幫你創(chuàng)建對(duì)應(yīng)的 CFRunLoopModeRef。對(duì)于一個(gè) RunLoop 來(lái)說(shuō)，其內(nèi)部的 mode 只能增加不能刪除。

蘋果公開提供的 Mode 有兩個(gè)：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode，你可以用這兩個(gè) Mode Name 來(lái)操作其對(duì)應(yīng)的 Mode。

同時(shí)蘋果還提供了一個(gè)操作 Common 標(biāo)記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，你可以用這個(gè)字符串來(lái)操作 Common Items，或標(biāo)記一個(gè) Mode 為 "Common"。使用時(shí)注意區(qū)分這個(gè)字符串和其他 mode name。

RunLoop 的內(nèi)部邏輯

根據(jù)蘋果在文檔里的說(shuō)明，RunLoop 內(nèi)部的邏輯大致如下:

其內(nèi)部代碼整理如下 （太長(zhǎng)了不想看可以直接跳過(guò)去，后面會(huì)有說(shuō)明）：

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 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110

///?用DefaultMode啟動(dòng) void?CFRunLoopRun(void)?{ ???? CFRunLoopRunSpecific(CFRunLoopGetCurrent(),?kCFRunLoopDefaultMode,?1.0e10,? false ); } ?? ///?用指定的Mode啟動(dòng)，允許設(shè)置RunLoop超時(shí)時(shí)間 int?CFRunLoopRunInMode(CFStringRef?modeName,?CFTimeInterval?seconds,?Boolean?stopAfterHandle)?{ ???? return? CFRunLoopRunSpecific(CFRunLoopGetCurrent(),?modeName,?seconds,?returnAfterSourceHandled); } ?? ///?RunLoop的實(shí)現(xiàn) int?CFRunLoopRunSpecific(runloop,?modeName,?seconds,?stopAfterHandle)?{ ????? ???? ///?首先根據(jù)modeName找到對(duì)應(yīng)mode ???? CFRunLoopModeRef?currentMode?=?__CFRunLoopFindMode(runloop,?modeName,? false ); ???? ///?如果mode里沒(méi)有source/timer/observer,?直接返回。 ???? if? (__CFRunLoopModeIsEmpty(currentMode))? return ; ????? ???? ///?1.?通知?Observers:?RunLoop?即將進(jìn)入?loop。 ???? __CFRunLoopDoObservers(runloop,?currentMode,?kCFRunLoopEntry); ????? ???? ///?內(nèi)部函數(shù)，進(jìn)入loop ???? __CFRunLoopRun(runloop,?currentMode,?seconds,?returnAfterSourceHandled)?{ ????????? ???????? Boolean?sourceHandledThisLoop?=?NO; ???????? int?retVal?=?0; ???????? do? { ?? ???????????? ///?2.?通知?Observers:?RunLoop?即將觸發(fā)?Timer?回調(diào)。 ???????????? __CFRunLoopDoObservers(runloop,?currentMode,?kCFRunLoopBeforeTimers); ???????????? ///?3.?通知?Observers:?RunLoop?即將觸發(fā)?Source0?(非port)?回調(diào)。 ???????????? __CFRunLoopDoObservers(runloop,?currentMode,?kCFRunLoopBeforeSources); ???????????? ///?執(zhí)行被加入的block ???????????? __CFRunLoopDoBlocks(runloop,?currentMode); ????????????? ???????????? ///?4.?RunLoop?觸發(fā)?Source0?(非port)?回調(diào)。 ???????????? sourceHandledThisLoop?=?__CFRunLoopDoSources0(runloop,?currentMode,?stopAfterHandle); ???????????? ///?執(zhí)行被加入的block ???????????? __CFRunLoopDoBlocks(runloop,?currentMode); ?? ???????????? ///?5.?如果有?Source1?(基于port)?處于?ready?狀態(tài)，直接處理這個(gè)?Source1?然后跳轉(zhuǎn)去處理消息。 ???????????? if? (__Source0DidDispatchPortLastTime)?{ ???????????????? Boolean?hasMsg?=?__CFRunLoopServiceMachPort(dispatchPort,?&msg) ???????????????? if? (hasMsg)?goto?handle_msg; ???????????? } ????????????? ???????????? ///?通知?Observers:?RunLoop?的線程即將進(jìn)入休眠(sleep)。 ???????????? if? (!sourceHandledThisLoop)?{ ???????????????? __CFRunLoopDoObservers(runloop,?currentMode,?kCFRunLoopBeforeWaiting); ???????????? } ????????????? ???????????? ///?7.?調(diào)用?mach_msg?等待接受?mach_port?的消息。線程將進(jìn)入休眠,?直到被下面某一個(gè)事件喚醒。 ???????????? ///???一個(gè)基于?port?的Source?的事件。 ???????????? ///???一個(gè)?Timer?到時(shí)間了 ???????????? ///???RunLoop?自身的超時(shí)時(shí)間到了 ???????????? ///???被其他什么調(diào)用者手動(dòng)喚醒 ???????????? __CFRunLoopServiceMachPort(waitSet,?&msg,?sizeof(msg_buffer),?&livePort)?{ ???????????????? mach_msg(msg,?MACH_RCV_MSG,?port);? //?thread?wait?for?receive?msg ???????????? } ?? ???????????? ///?8.?通知?Observers:?RunLoop?的線程剛剛被喚醒了。 ???????????? __CFRunLoopDoObservers(runloop,?currentMode,?kCFRunLoopAfterWaiting); ????????????? ???????????? ///?收到消息，處理消息。 ???????????? handle_msg: ?? ???????????? ///?9.1?如果一個(gè)?Timer?到時(shí)間了，觸發(fā)這個(gè)Timer的回調(diào)。 ???????????? if? (msg_is_timer)?{ ???????????????? __CFRunLoopDoTimers(runloop,?currentMode,?mach_absolute_time()) ???????????? }? ?? ???????????? ///?9.2?如果有dispatch到main_queue的block，執(zhí)行block。 ???????????? else? if? (msg_is_dispatch)?{ ???????????????? __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg); ???????????? }? ?? ???????????? ///?9.3?如果一個(gè)?Source1?(基于port)?發(fā)出事件了，處理這個(gè)事件 ???????????? else? { ???????????????? CFRunLoopSourceRef?source1?=?__CFRunLoopModeFindSourceForMachPort(runloop,?currentMode,?livePort); ???????????????? sourceHandledThisLoop?=?__CFRunLoopDoSource1(runloop,?currentMode,?source1,?msg); ???????????????? if? (sourceHandledThisLoop)?{ ???????????????????? mach_msg(reply,?MACH_SEND_MSG,?reply); ???????????????? } ???????????? } ????????????? ???????????? ///?執(zhí)行加入到Loop的block ???????????? __CFRunLoopDoBlocks(runloop,?currentMode); ????????????? ?? ???????????? if? (sourceHandledThisLoop?&&?stopAfterHandle)?{ ???????????????? ///?進(jìn)入loop時(shí)參數(shù)說(shuō)處理完事件就返回。 ???????????????? retVal?=?kCFRunLoopRunHandledSource; ???????????? }? else? if? (timeout)?{ ???????????????? ///?超出傳入?yún)?shù)標(biāo)記的超時(shí)時(shí)間了 ???????????????? retVal?=?kCFRunLoopRunTimedOut; ???????????? }? else? if? (__CFRunLoopIsStopped(runloop))?{ ???????????????? ///?被外部調(diào)用者強(qiáng)制停止了 ???????????????? retVal?=?kCFRunLoopRunStopped; ???????????? }? else? if? (__CFRunLoopModeIsEmpty(runloop,?currentMode))?{ ???????????????? ///?source/timer/observer一個(gè)都沒(méi)有了 ???????????????? retVal?=?kCFRunLoopRunFinished; ???????????? } ????????????? ???????????? ///?如果沒(méi)超時(shí)，mode里沒(méi)空，loop也沒(méi)被停止，那繼續(xù)loop。 ???????? }? while? (retVal?==?0); ???? } ????? ???? ///?10.?通知?Observers:?RunLoop?即將退出。 ???? __CFRunLoopDoObservers(rl,?currentMode,?kCFRunLoopExit); }

可以看到，實(shí)際上 RunLoop 就是這樣一個(gè)函數(shù)，其內(nèi)部是一個(gè) do-while 循環(huán)。當(dāng)你調(diào)用 CFRunLoopRun() 時(shí)，線程就會(huì)一直停留在這個(gè)循環(huán)里；直到超時(shí)或被手動(dòng)停止，該函數(shù)才會(huì)返回。

RunLoop 的底層實(shí)現(xiàn)

從上面代碼可以看到，RunLoop 的核心是基于 mach port 的，其進(jìn)入休眠時(shí)調(diào)用的函數(shù)是 mach_msg()。為了解釋這個(gè)邏輯，下面稍微介紹一下 OSX/iOS 的系統(tǒng)架構(gòu)。

蘋果官方將整個(gè)系統(tǒng)大致劃分為上述4個(gè)層次：

應(yīng)用層包括用戶能接觸到的圖形應(yīng)用，例如 Spotlight、Aqua、SpringBoard 等。

應(yīng)用框架層即開發(fā)人員接觸到的 Cocoa 等框架。

核心框架層包括各種核心框架、OpenGL 等內(nèi)容。

Darwin 即操作系統(tǒng)的核心，包括系統(tǒng)內(nèi)核、驅(qū)動(dòng)、Shell 等內(nèi)容，這一層是開源的，其所有源碼都可以在?opensource.apple.com?里找到。

我們?cè)谏钊肟匆幌?Darwin 這個(gè)核心的架構(gòu)：

其中，在硬件層上面的三個(gè)組成部分：Mach、BSD、IOKit (還包括一些上面沒(méi)標(biāo)注的內(nèi)容)，共同組成了 XNU 內(nèi)核。

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

BSD 層可以看作圍繞 Mach 層的一個(gè)外環(huán)，其提供了諸如進(jìn)程管理、文件系統(tǒng)和網(wǎng)絡(luò)等功能。

IOKit 層是為設(shè)備驅(qū)動(dòng)提供了一個(gè)面向?qū)ο?C++)的一個(gè)框架。

Mach 本身提供的 API 非常有限，而且蘋果也不鼓勵(lì)使用 Mach 的 API，但是這些API非常基礎(chǔ)，如果沒(méi)有這些API的話，其他任何工作都無(wú)法實(shí)施。在 Mach 中，所有的東西都是通過(guò)自己的對(duì)象實(shí)現(xiàn)的，進(jìn)程、線程和虛擬內(nèi)存都被稱為"對(duì)象"。和其他架構(gòu)不同， Mach 的對(duì)象間不能直接調(diào)用，只能通過(guò)消息傳遞的方式實(shí)現(xiàn)對(duì)象間的通信。"消息"是 Mach 中最基礎(chǔ)的概念，消息在兩個(gè)端口 (port) 之間傳遞，這就是 Mach 的 IPC (進(jìn)程間通信) 的核心。

Mach 的消息定義是在頭文件的，很簡(jiǎn)單：

1 2 3 4 5 6 7 8 9 10 11 12 13

typedef?struct?{ ?? mach_msg_header_t?header; ?? mach_msg_body_t?body; }?mach_msg_base_t; ?? typedef?struct?{ ?? mach_msg_bits_t?msgh_bits; ?? mach_msg_size_t?msgh_size; ?? mach_port_t?msgh_remote_port; ?? mach_port_t?msgh_local_port; ?? mach_port_name_t?msgh_voucher_port; ?? mach_msg_id_t?msgh_id; }?mach_msg_header_t;

一條 Mach 消息實(shí)際上就是一個(gè)二進(jìn)制數(shù)據(jù)包 (BLOB)，其頭部定義了當(dāng)前端口 local_port 和目標(biāo)端口 remote_port，

發(fā)送和接受消息是通過(guò)同一個(gè) API 進(jìn)行的，其 option 標(biāo)記了消息傳遞的方向：

1 2 3 4 5 6 7 8

mach_msg_return_t?mach_msg( mach_msg_header_t?*msg, mach_msg_option_t?option, mach_msg_size_t?send_size, mach_msg_size_t?rcv_size, mach_port_name_t?rcv_name, mach_msg_timeout_t?timeout, mach_port_name_t?notify);

為了實(shí)現(xiàn)消息的發(fā)送和接收，mach_msg() 函數(shù)實(shí)際上是調(diào)用了一個(gè) Mach 陷阱 (trap)，即函數(shù)mach_msg_trap()，陷阱這個(gè)概念在 Mach 中等同于系統(tǒng)調(diào)用。當(dāng)你在用戶態(tài)調(diào)用 mach_msg_trap() 時(shí)會(huì)觸發(fā)陷阱機(jī)制，切換到內(nèi)核態(tài)；內(nèi)核態(tài)中內(nèi)核實(shí)現(xiàn)的 mach_msg() 函數(shù)會(huì)完成實(shí)際的工作，如下圖：

這些概念可以參考維基百科:?System_call、Trap_(computing)。

RunLoop 的核心就是一個(gè) mach_msg() (見上面代碼的第7步)，RunLoop 調(diào)用這個(gè)函數(shù)去接收消息，如果沒(méi)有別人發(fā)送 port 消息過(guò)來(lái)，內(nèi)核會(huì)將線程置于等待狀態(tài)。例如你在模擬器里跑起一個(gè) iOS 的 App，然后在 App 靜止時(shí)點(diǎn)擊暫停，你會(huì)看到主線程調(diào)用棧是停留在 mach_msg_trap() 這個(gè)地方。

關(guān)于具體的如何利用 mach port 發(fā)送信息，可以看看?NSHipster 這一篇文章，或者這里的中文翻譯 。

關(guān)于Mach的歷史可以看看這篇很有趣的文章：Mac OS X 背后的故事（三）Mach 之父 Avie Tevanian。

蘋果用 RunLoop 實(shí)現(xiàn)的功能

首先我們可以看一下 App 啟動(dòng)后 RunLoop 的狀態(tài)：

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 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99

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 ), ???????? } ???? } }

可以看到，系統(tǒng)默認(rèn)注冊(cè)了5個(gè)Mode:

1. kCFRunLoopDefaultMode: App的默認(rèn) Mode，通常主線程是在這個(gè) Mode 下運(yùn)行的。

2. UITrackingRunLoopMode: 界面跟蹤 Mode，用于 ScrollView 追蹤觸摸滑動(dòng)，保證界面滑動(dòng)時(shí)不受其他 Mode 影響。

3. UIInitializationRunLoopMode: 在剛啟動(dòng) App 時(shí)第進(jìn)入的第一個(gè) Mode，啟動(dòng)完成后就不再使用。

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

5: kCFRunLoopCommonModes: 這是一個(gè)占位的 Mode，沒(méi)有實(shí)際作用。

你可以在這里看到更多的蘋果內(nèi)部的 Mode，但那些 Mode 在開發(fā)中就很難遇到了。

當(dāng) RunLoop 進(jìn)行回調(diào)時(shí)，一般都是通過(guò)一個(gè)很長(zhǎng)的函數(shù)調(diào)用出去 (call out), 當(dāng)你在你的代碼中下斷點(diǎn)調(diào)試時(shí)，通常能在調(diào)用棧上看到這些函數(shù)。下面是這幾個(gè)函數(shù)的整理版本，如果你在調(diào)用棧中看到這些長(zhǎng)函數(shù)名，在這里查找一下就能定位到具體的調(diào)用地點(diǎn)了：

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 39 40 41 42 43

{ ???? ///?1.?通知Observers，即將進(jìn)入RunLoop ???? ///?此處有Observer會(huì)創(chuàng)建AutoreleasePool:?_objc_autoreleasePoolPush(); ???? __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry); ???? do? { ?? ???????? ///?2.?通知?Observers:?即將觸發(fā)?Timer?回調(diào)。 ???????? __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers); ???????? ///?3.?通知?Observers:?即將觸發(fā)?Source?(非基于port的,Source0)?回調(diào)。 ???????? __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources); ???????? __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block); ?? ???????? ///?4.?觸發(fā)?Source0?(非基于port的)?回調(diào)。 ???????? __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0); ???????? __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block); ?? ???????? ///?6.?通知Observers，即將進(jìn)入休眠 ???????? ///?此處有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喚醒的，回調(diào)Timer ???????? __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer); ?? ???????? ///?9.?如果是被dispatch喚醒的，執(zhí)行所有調(diào)用?dispatch_async?等方法放入main?queue?的?block ???????? __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(dispatched_block); ?? ???????? ///?9.?如果如果Runloop是被?Source1?(基于port的)?的事件喚醒了，處理這個(gè)事件 ???????? __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啟動(dòng)后，蘋果在主線程 RunLoop 里注冊(cè)了兩個(gè) Observer，其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()。

第一個(gè) Observer 監(jiān)視的事件是 Entry(即將進(jìn)入Loop)，其回調(diào)內(nèi)會(huì)調(diào)用 _objc_autoreleasePoolPush() 創(chuàng)建自動(dòng)釋放池。其 order 是-2147483647，優(yōu)先級(jí)最高，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前。

第二個(gè) Observer 監(jiān)視了兩個(gè)事件： BeforeWaiting(準(zhǔn)備進(jìn)入休眠) 時(shí)調(diào)用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池并創(chuàng)建新池；Exit(即將退出Loop) 時(shí)調(diào)用 _objc_autoreleasePoolPop() 來(lái)釋放自動(dòng)釋放池。這個(gè) Observer 的 order 是 2147483647，優(yōu)先級(jí)最低，保證其釋放池子發(fā)生在其他所有回調(diào)之后。

在主線程執(zhí)行的代碼，通常是寫在諸如事件回調(diào)、Timer回調(diào)內(nèi)的。這些回調(diào)會(huì)被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著，所以不會(huì)出現(xiàn)內(nèi)存泄漏，開發(fā)者也不必顯示創(chuàng)建 Pool 了。

事件響應(yīng)

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

當(dāng)一個(gè)硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后，首先由 IOKit.framework 生成一個(gè) IOHIDEvent 事件并由 SpringBoard 接收。這個(gè)過(guò)程的詳細(xì)情況可以參考這里。SpringBoard 只接收按鍵(鎖屏/靜音等)，觸摸，加速，接近傳感器等幾種 Event，隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進(jìn)程。隨后蘋果注冊(cè)的那個(gè) Source1 就會(huì)觸發(fā)回調(diào)，并調(diào)用 _UIApplicationHandleEventQueue() 進(jìn)行應(yīng)用內(nèi)部的分發(fā)。

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

手勢(shì)識(shí)別

當(dāng)上面的 _UIApplicationHandleEventQueue() 識(shí)別了一個(gè)手勢(shì)時(shí)，其首先會(huì)調(diào)用 Cancel 將當(dāng)前的 touchesBegin/Move/End 系列回調(diào)打斷。隨后系統(tǒng)將對(duì)應(yīng)的 UIGestureRecognizer 標(biāo)記為待處理。

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

當(dāng)有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時(shí)，這個(gè)回調(diào)都會(huì)進(jìn)行相應(yīng)處理。

界面更新

當(dāng)在操作 UI 時(shí)，比如改變了 Frame、更新了 UIView/CALayer 的層次時(shí)，或者手動(dòng)調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，這個(gè) UIView/CALayer 就被標(biāo)記為待處理，并被提交到一個(gè)全局的容器去。

蘋果注冊(cè)了一個(gè) Observer 監(jiān)聽 BeforeWaiting(即將進(jìn)入休眠) 和 Exit (即將退出Loop) 事件，回調(diào)去執(zhí)行一個(gè)很長(zhǎng)的函數(shù)：

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個(gè)函數(shù)里會(huì)遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實(shí)際的繪制和調(diào)整，并更新 UI 界面。

這個(gè)函數(shù)內(nèi)部的調(diào)用棧大概是這樣的：

1 2 3 4 5 6 7 8 9 10 11

_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];

定時(shí)器

NSTimer 其實(shí)就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個(gè) NSTimer 注冊(cè)到 RunLoop 后，RunLoop 會(huì)為其重復(fù)的時(shí)間點(diǎn)注冊(cè)好事件。例如 10:00, 10:10, 10:20 這幾個(gè)時(shí)間點(diǎn)。RunLoop為了節(jié)省資源，并不會(huì)在非常準(zhǔn)確的時(shí)間點(diǎn)回調(diào)這個(gè)Timer。Timer 有個(gè)屬性叫做 Tolerance (寬容度)，標(biāo)示了當(dāng)時(shí)間點(diǎn)到后，容許有多少最大誤差。

如果某個(gè)時(shí)間點(diǎn)被錯(cuò)過(guò)了，例如執(zhí)行了一個(gè)很長(zhǎng)的任務(wù)，則那個(gè)時(shí)間點(diǎn)的回調(diào)也會(huì)跳過(guò)去，不會(huì)延后執(zhí)行。就比如等公交，如果 10:10 時(shí)我忙著玩手機(jī)錯(cuò)過(guò)了那個(gè)點(diǎn)的公交，那我只能等 10:20 這一趟了。

CADisplayLink 是一個(gè)和屏幕刷新率一致的定時(shí)器（但實(shí)際實(shí)現(xiàn)原理更復(fù)雜，和 NSTimer 并不一樣，其內(nèi)部實(shí)際是操作了一個(gè) Source）。如果在兩次屏幕刷新之間執(zhí)行了一個(gè)長(zhǎng)任務(wù)，那其中就會(huì)有一幀被跳過(guò)去（和 NSTimer 相似），造成界面卡頓的感覺(jué)。在快速滑動(dòng)TableView時(shí)，即使一幀的卡頓也會(huì)讓用戶有所察覺(jué)。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問(wèn)題，其內(nèi)部也用到了 RunLoop，這個(gè)稍后我會(huì)再單獨(dú)寫一頁(yè)博客來(lái)分析。

PerformSelecter

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

當(dāng)調(diào)用 performSelector:onThread: 時(shí)，實(shí)際上其會(huì)創(chuàng)建一個(gè) Timer 加到對(duì)應(yīng)的線程去，同樣的，如果對(duì)應(yīng)線程沒(méi)有 RunLoop 該方法也會(huì)失效。

關(guān)于GCD

實(shí)際上 RunLoop 底層也會(huì)用到 GCD 的東西，比如 RunLoop 是用 dispatch_source_t 實(shí)現(xiàn)的 Timer。但同時(shí) GCD 提供的某些接口也用到了 RunLoop， 例如 dispatch_async()。

當(dāng)調(diào)用 dispatch_async(dispatch_get_main_queue(), block) 時(shí)，libDispatch 會(huì)向主線程的 RunLoop 發(fā)送消息，RunLoop會(huì)被喚醒，并從消息中取得這個(gè) block，并在回調(diào) __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 里執(zhí)行這個(gè) block。但這個(gè)邏輯僅限于 dispatch 到主線程，dispatch 到其他線程仍然是由 libDispatch 處理的。

關(guān)于網(wǎng)絡(luò)請(qǐng)求

iOS 中，關(guān)于網(wǎng)絡(luò)請(qǐng)求的接口自下至上有如下幾層:

1 2 3 4

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

• CFSocket 是最底層的接口，只負(fù)責(zé) socket 通信。

• CFNetwork 是基于 CFSocket 等接口的上層封裝，ASIHttpRequest 工作于這一層。

• NSURLConnection 是基于 CFNetwork 的更高層的封裝，提供面向?qū)ο蟮慕涌?#xff0c;AFNetworking 工作于這一層。

• NSURLSession 是 iOS7 中新增的接口，表面上是和 NSURLConnection 并列的，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)，AFNetworking2 和 Alamofire 工作于這一層。

下面主要介紹下 NSURLConnection 的工作過(guò)程。

通常使用 NSURLConnection 時(shí)，你會(huì)傳入一個(gè) Delegate，當(dāng)調(diào)用了 [connection start] 后，這個(gè) Delegate 就會(huì)不停收到事件回調(diào)。實(shí)際上，start 這個(gè)函數(shù)的內(nèi)部會(huì)會(huì)獲取 CurrentRunLoop，然后在其中的 DefaultMode 添加了4個(gè) Source0 (即需要手動(dòng)觸發(fā)的Source)。CFMultiplexerSource 是負(fù)責(zé)各種 Delegate 回調(diào)的，CFHTTPCookieStorage 是處理各種 Cookie 的。

當(dāng)開始網(wǎng)絡(luò)傳輸時(shí)，我們可以看到 NSURLConnection 創(chuàng)建了兩個(gè)新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的。NSURLConnectionLoader 這個(gè)線程內(nèi)部會(huì)使用 RunLoop 來(lái)接收底層 socket 的事件，并通過(guò)之前添加的 Source0 通知到上層的 Delegate。

NSURLConnectionLoader 中的 RunLoop 通過(guò)一些基于 mach port 的 Source 接收來(lái)自底層 CFSocket 的通知。當(dāng)收到通知后，其會(huì)在合適的時(shí)機(jī)向 CFMultiplexerSource 等 Source0 發(fā)送通知，同時(shí)喚醒 Delegate 線程的 RunLoop 來(lái)讓其處理這些通知。CFMultiplexerSource 會(huì)在 Delegate 線程的 RunLoop 對(duì) Delegate 執(zhí)行實(shí)際的回調(diào)。

RunLoop 的實(shí)際應(yīng)用舉例

AFNetworking

AFURLConnectionOperation?這個(gè)類是基于 NSURLConnection 構(gòu)建的，其希望能在后臺(tái)線程接收 Delegate 回調(diào)。為此 AFNetworking 單獨(dú)創(chuàng)建了一個(gè)線程，并在這個(gè)線程中啟動(dòng)了一個(gè) RunLoop：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

+?(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 啟動(dòng)前內(nèi)部必須要有至少一個(gè) Timer/Observer/Source，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個(gè)新的 NSMachPort 添加進(jìn)去了。通常情況下，調(diào)用者需要持有這個(gè) NSMachPort (mach_port) 并在外部線程通過(guò)這個(gè) port 發(fā)送消息到 loop 內(nèi)；但此處添加 port 只是為了讓 RunLoop 不至于退出，并沒(méi)有用于實(shí)際的發(fā)送消息。

1 2 3 4 5 6 7 8 9 10

-?(void)start?{ ???? [self.lock?lock]; ???? if? ([self?isCancelled])?{ ???????? [self?performSelector:@selector(cancelConnection)?onThread:[[self?class]?networkRequestThread]?withObject:nil?waitUntilDone:NO?modes:[self.runLoopModes?allObjects]]; ???? }? else? if? ([self?isReady])?{ ???????? self.state?=?AFOperationExecutingState; ???????? [self?performSelector:@selector(operationDidStart)?onThread:[[self?class]?networkRequestThread]?withObject:nil?waitUntilDone:NO?modes:[self.runLoopModes?allObjects]]; ???? } ???? [self.lock?unlock]; }

當(dāng)需要這個(gè)后臺(tái)線程執(zhí)行任務(wù)時(shí)，AFNetworking 通過(guò)調(diào)用 [NSObject performSelector:onThread:..] 將這個(gè)任務(wù)扔到了后臺(tái)線程的 RunLoop 中。

AsyncDisplayKit

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

UI 線程中一旦出現(xiàn)繁重的任務(wù)就會(huì)導(dǎo)致界面卡頓，這類任務(wù)通常分為3類：排版，繪制，UI對(duì)象操作。

排版通常包括計(jì)算視圖大小、計(jì)算文本高度、重新計(jì)算子式圖的排版等操作。

繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預(yù)先解壓)、元素繪制 (Quartz)等操作。

UI對(duì)象操作通常包括 UIView/CALayer 等 UI 對(duì)象的創(chuàng)建、設(shè)置屬性和銷毀。

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

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

ASDK 仿照 QuartzCore/UIKit 框架的模式，實(shí)現(xiàn)了一套類似的界面更新的機(jī)制：即在主線程的 RunLoop 中添加一個(gè) Observer，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件，在收到回調(diào)時(shí)，遍歷所有之前放入隊(duì)列的待處理的任務(wù)，然后一一執(zhí)行。

具體的代碼可以看這里：_ASAsyncTransactionGroup。

總結(jié)

以上是生活随笔為你收集整理的深入理解RunLoop的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。