RunLoop?是?iOS?和?OSX?開(kāi)發(fā)中非?；A(chǔ)的一個(gè)概念，這篇文章將從CFRunLoop的源碼入手，介紹?RunLoop?的概念以及底層實(shí)現(xiàn)原理。之后會(huì)介紹一下在?iOS?中，蘋(píng)果是如何利用RunLoop實(shí)現(xiàn)自動(dòng)釋放池、延遲回調(diào)、觸摸事件、屏幕刷新等功能的。
作為一個(gè)開(kāi)發(fā)者，有一個(gè)學(xué)習(xí)的氛圍跟一個(gè)交流圈子特別重要這是一個(gè)我的iOS交流群：776598941，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經(jīng)驗(yàn)，討論技術(shù)， 大家一起交流學(xué)習(xí)成長(zhǎng)！
RunLoop 的概念
RunLoop 與線程的關(guān)系
RunLoop 對(duì)外的接口
RunLoop 的 Mode
RunLoop 的內(nèi)部邏輯
RunLoop 的底層實(shí)現(xiàn)
蘋(píng)果用 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
一般來(lái)講，一個(gè)線程一次只能執(zhí)行一個(gè)任務(wù)，執(zhí)行完成后線程就會(huì)退出。如果我們需要一個(gè)機(jī)制，讓線程能隨時(shí)處理事件但并不退出，通常的代碼邏輯是這樣的：
function loop() {
? ? initialize();
do{
varmessage = get_next_message();
? ? ? ? process_message(message);
}while(message != quit);
}
這種模型通常被稱(chēng)作?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 的代碼是開(kāi)源的，你可以在這里?http://opensource.apple.com/tarballs/CF/?下載到整個(gè)?CoreFoundation?的源碼來(lái)查看。
(Update: Swift 開(kāi)源后，蘋(píng)果又維護(hù)了一個(gè)跨平臺(tái)的 CoreFoundation 版本：https://github.com/apple/swift-corelibs-foundation/，這個(gè)版本的源碼可能和現(xiàn)有iOS系統(tǒng)中的實(shí)現(xiàn)略不一樣，但更容易編譯，而且已經(jīng)適配了Linux/Windows。)
首先，iOS?開(kāi)發(fā)中能遇到兩個(gè)線程對(duì)象:?pthread_t?和?NSThread。過(guò)去蘋(píng)果有份文檔標(biāo)明了?NSThread?只是?pthread_t?的封裝，但那份文檔已經(jīng)失效了，現(xiàn)在它們也有可能都是直接包裝自最底層的?mach thread。蘋(píng)果并沒(méi)有提供這兩個(gè)對(duì)象相互轉(zhuǎn)換的接口，但不管怎么樣，可以肯定的是?pthread_t?和?NSThread?是一一對(duì)應(yīng)的。比如，你可以通過(guò)?pthread_main_thread_np()?或?[NSThread mainThread]?來(lái)獲取主線程；也可以通過(guò)?pthread_self()?或?[NSThread currentThread]?來(lái)獲取當(dāng)前線程。CFRunLoop?是基于?pthread?來(lái)管理的。
蘋(píng)果不允許直接創(chuàng)建?RunLoop，它只提供了兩個(gè)自動(dòng)獲取的函數(shù)：CFRunLoopGetMain()?和?CFRunLoopGetCurrent()。 這兩個(gè)函數(shù)內(nèi)部的邏輯大概是下面這樣:
/// 全局的Dictionary，key 是 pthread_t， value 是 CFRunLoopRef
staticCFMutableDictionaryRef loopsDic;
/// 訪問(wèn) loopsDic 時(shí)的鎖
staticCFSpinLock_t loopsLock;
/// 獲取一個(gè) pthread 對(duì)應(yīng)的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_tthread) {
? ? 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)線程銷(xiāo)毀時(shí)，順便也銷(xiāo)毀其對(duì)應(yīng)的 RunLoop。
? ? ? ? _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
? ? }
? ? OSSpinLockUnLock(&loopsLock);
returnloop;
}
CFRunLoopRefCFRunLoopGetMain(){
return_CFRunLoopGet(pthread_main_thread_np());
}
CFRunLoopRefCFRunLoopGetCurrent(){
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?的銷(xiāo)毀是發(fā)生在線程結(jié)束時(shí)。你只能在一個(gè)線程的內(nèi)部獲取其?RunLoop（主線程除外）.
在?CoreFoundation?里面關(guān)于?RunLoop?有5個(gè)類(lèi):
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef
其中?CFRunLoopModeRef?類(lèi)并沒(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被稱(chēng)作?CurrentMode。如果需要切換?Mode，只能退出?Loop，再重新指定一個(gè)?Mode?進(jìn)入。這樣做主要是為了分隔開(kāi)不同組的?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è)：
typedefCF_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)稱(chē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)。
CFRunLoopMode?和?CFRunLoop?的結(jié)構(gòu)大致如下：
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” 中?！眂ommonModeItems” 被?RunLoop?自動(dòng)更新到所有具有”Common”屬性的?Mode?里去。
CFRunLoop對(duì)外暴露的管理?Mode?接口只有下面2個(gè):
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);
Mode?暴露的管理?mode item?的接口有下面幾個(gè)：
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?只能增加不能刪除。
蘋(píng)果公開(kāi)提供的?Mode?有兩個(gè)：kCFRunLoopDefaultMode?(NSDefaultRunLoopMode) 和?UITrackingRunLoopMode，你可以用這兩個(gè)?Mode Name?來(lái)操作其對(duì)應(yīng)的Mode。
同時(shí)蘋(píng)果還提供了一個(gè)操作?Common?標(biāo)記的字符串：kCFRunLoopCommonModes(NSRunLoopCommonModes)，你可以用這個(gè)字符串來(lái)操作?Common Items，或標(biāo)記一個(gè)?Mode?為 “Common”。使用時(shí)注意區(qū)分這個(gè)字符串和其他?mode name。
根據(jù)蘋(píng)果在文檔里的說(shuō)明，RunLoop?內(nèi)部的邏輯大致如下:
其內(nèi)部代碼整理如下 (太長(zhǎng)了不想看可以直接跳過(guò)去，后面會(huì)有說(shuō)明)
/// 用DefaultMode啟動(dòng)
voidCFRunLoopRun(void){
CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode,1.0e10,false);
}
/// 用指定的Mode啟動(dòng)，允許設(shè)置RunLoop超時(shí)時(shí)間
intCFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean stopAfterHandle){
returnCFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}
/// RunLoop的實(shí)現(xiàn)
intCFRunLoopRunSpecific(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;
intretVal =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)gotohandle_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。
elseif(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;
}elseif(timeout) {
/// 超出傳入?yún)?shù)標(biāo)記的超時(shí)時(shí)間了
? ? ? ? ? ? ? ? retVal = kCFRunLoopRunTimedOut;
}elseif(__CFRunLoopIsStopped(runloop)) {
/// 被外部調(diào)用者強(qiáng)制停止了
? ? ? ? ? ? ? ? retVal = kCFRunLoopRunStopped;
}elseif(__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);
}
從上面代碼可以看到，RunLoop?的核心是基于?mach port?的，其進(jìn)入休眠時(shí)調(diào)用的函數(shù)是?mach_msg()。為了解釋這個(gè)邏輯，下面稍微介紹一下?OSX/iOS?的系統(tǒng)架構(gòu)。
蘋(píng)果官方將整個(gè)系統(tǒng)大致劃分為上述4個(gè)層次：
應(yīng)用層包括用戶(hù)能接觸到的圖形應(yīng)用，例如?Spotlight、Aqua、SpringBoard?等。
應(yīng)用框架層即開(kāi)發(fā)人員接觸到的?Cocoa等框架。
核心框架層包括各種核心框架、OpenGL?等內(nèi)容。
Darwin?即操作系統(tǒng)的核心，包括系統(tǒng)內(nèi)核、驅(qū)動(dòng)、Shell?等內(nèi)容，這一層是開(kā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)被稱(chēng)作?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?非常有限，而且蘋(píng)果也不鼓勵(lì)使用?Mach?的?API，但是這些API非常基礎(chǔ)，如果沒(méi)有這些API的話，其他任何工作都無(wú)法實(shí)施。在?Mach?中，所有的東西都是通過(guò)自己的對(duì)象實(shí)現(xiàn)的，進(jìn)程、線程和虛擬內(nèi)存都被稱(chēng)為”對(duì)象”。和其他架構(gòu)不同，?Mach?的對(duì)象間不能直接調(diào)用，只能通過(guò)消息傳遞的方式實(shí)現(xiàn)對(duì)象間的通信。”消息”是?Mach?中最基礎(chǔ)的概念，消息在兩個(gè)端口 (port) 之間傳遞，這就是?Mach?的?IPC?(進(jìn)程間通信) 的核心。
Mach?的消息定義是在??頭文件的，很簡(jiǎn)單：
typedefstruct{
mach_msg_header_theader;
mach_msg_body_tbody;
}mach_msg_base_t;
typedefstruct{
mach_msg_bits_tmsgh_bits;
mach_msg_size_tmsgh_size;
mach_port_tmsgh_remote_port;
mach_port_tmsgh_local_port;
mach_port_name_tmsgh_voucher_port;
mach_msg_id_tmsgh_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)記了消息傳遞的方向：
mach_msg_return_tmach_msg(
mach_msg_header_t*msg,
mach_msg_option_toption,
mach_msg_size_tsend_size,
mach_msg_size_trcv_size,
mach_port_name_trcv_name,
mach_msg_timeout_ttimeout,
mach_port_name_tnotify);
為了實(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)你在用戶(hù)態(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()?(見(jiàn)上面代碼的第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。
蘋(píng)果用 RunLoop 實(shí)現(xiàn)的功能
首先我們可以看一下App啟動(dòng)后RunLoop的狀態(tài)：
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:
kCFRunLoopDefaultMode:?App的默認(rèn)?Mode，通常主線程是在這個(gè)?Mode?下運(yùn)行的。
UITrackingRunLoopMode: 界面跟蹤?Mode，用于?ScrollView?追蹤觸摸滑動(dòng)，保證界面滑動(dòng)時(shí)不受其他?Mode?影響。
UIInitializationRunLoopMode: 在剛啟動(dòng)?App?時(shí)第進(jìn)入的第一個(gè)?Mode，啟動(dòng)完成后就不再使用。
GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內(nèi)部?Mode，通常用不到。
kCFRunLoopCommonModes: 這是一個(gè)占位的?Mode，沒(méi)有實(shí)際作用。
你可以在這里看到更多的蘋(píng)果內(nèi)部的?Mode，但那些?Mode?在開(kāi)發(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. 通知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);
}
App啟動(dòng)后，蘋(pí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í)行的代碼，通常是寫(xiě)在諸如事件回調(diào)、Timer回調(diào)內(nèi)的。這些回調(diào)會(huì)被?RunLoop?創(chuàng)建好的?AutoreleasePool?環(huán)繞著，所以不會(huì)出現(xiàn)內(nèi)存泄漏，開(kāi)發(fā)者也不必顯示創(chuàng)建Pool?了。
蘋(pí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)程。隨后蘋(píng)果注冊(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)中完成的。
當(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)記為待處理。
蘋(píng)果注冊(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)建/銷(xiāo)毀/狀態(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è)全局的容器去。
蘋(píng)果注冊(cè)了一個(gè)?Observer?監(jiān)聽(tīng)?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)用棧大概是這樣的：
_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];
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ì)讓用戶(hù)有所察覺(jué)。Facebook?開(kāi)源的AsyncDisplayLink?就是為了解決界面卡頓的問(wèn)題，其內(nèi)部也用到了?RunLoop，這個(gè)稍后我會(huì)再單獨(dú)寫(xiě)一頁(yè)博客來(lái)分析。
當(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ì)失效。
實(shí)際上?RunLoop?底層也會(huì)用到 GCD 的東西， 例如?dispatch_async()。
NSTimer 是用了 XNU 內(nèi)核的?mk_timer來(lái)驅(qū)動(dòng)的，而非 GCD 驅(qū)動(dòng)的.
當(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?處理的。
iOS 中，關(guān)于網(wǎng)絡(luò)請(qǐng)求的接口自下至上有如下幾層:
CFSocket
CFNetwork? ? ? ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession? ? ->AFNetworking2, Alamofire
CFSocket?是最底層的接口，只負(fù)責(zé)?socket?通信。
CFNetwork?是基于?CFSocket?等接口的上層封裝，ASIHttpRequest?工作于這一層。
NSURLConnection?是基于?CFNetwork?的更高層的封裝，提供面向?qū)ο蟮慕涌?，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)開(kāi)始網(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)。
AFURLConnectionOperation?這個(gè)類(lèi)是基于?NSURLConnection?構(gòu)建的，其希望能在后臺(tái)線程接收?Delegate?回調(diào)。為此?AFNetworking單獨(dú)創(chuàng)建了一個(gè)線程，并在這個(gè)線程中啟動(dòng)了一個(gè)?RunLoop
+ (void)networkRequestThreadEntryPoint:(id)__unused object {
@autoreleasepool{
[[NSThreadcurrentThread] setName:@"AFNetworking"];
NSRunLoop*runLoop = [NSRunLoopcurrentRunLoop];
[runLoop addPort:[NSMachPortport] forMode:NSDefaultRunLoopMode];
? ? ? ? [runLoop run];
? ? }
}
+ (NSThread*)networkRequestThread {
staticNSThread*_networkRequestThread =nil;
staticdispatch_once_toncePredicate;
dispatch_once(&oncePredicate, ^{
_networkRequestThread = [[NSThreadalloc] initWithTarget:selfselector:@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ā)送消息。
- (void)start {
[self.lock lock];
if([selfisCancelled]) {
[selfperformSelector:@selector(cancelConnection) onThread:[[selfclass] networkRequestThread] withObject:nilwaitUntilDone:NOmodes:[self.runLoopModes allObjects]];
}elseif([selfisReady]) {
self.state = AFOperationExecutingState;
[selfperformSelector:@selector(operationDidStart) onThread:[[selfclass] networkRequestThread] withObject:nilwaitUntilDone:NOmodes:[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?是 Facebook 推出的用于保持界面流暢性的框架，其原理大致如下：
UI?線程中一旦出現(xiàn)繁重的任務(wù)就會(huì)導(dǎo)致界面卡頓，這類(lèi)任務(wù)通常分為3類(lèi)：排版，繪制，UI對(duì)象操作。
排版通常包括計(jì)算視圖大小、計(jì)算文本高度、重新計(jì)算子式圖的排版等操作。
繪制一般有文本繪制 (例如?CoreText)、圖片繪制 (例如預(yù)先解壓)、元素繪制 (Quartz)等操作。
UI對(duì)象操作通常包括?UIView/CALayer?等 UI 對(duì)象的創(chuàng)建、設(shè)置屬性和銷(xiāo)毀。
其中前兩類(lèi)操作可以通過(guò)各種方法扔到后臺(tái)線程執(zhí)行，而最后一類(lèi)操作只能在主線程完成，并且有時(shí)后面的操作需要依賴(lài)前面操作的結(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)線程更改，開(kāi)發(fā)者可以只通過(guò)?Node?來(lái)操作其內(nèi)部的?UIView/CALayer，這樣就可以將排版和繪制放入了后臺(tái)線程。但是無(wú)論怎么操作，這些屬性總需要在某個(gè)時(shí)刻同步到主線程的?UIView/CALayer?去。
ASDK?仿照?QuartzCore/UIKit?框架的模式，實(shí)現(xiàn)了一套類(lèi)似的界面更新的機(jī)制：即在主線程的?RunLoop?中添加一個(gè)?Observer，監(jiān)聽(tīng)了?kCFRunLoopBeforeWaiting?和?kCFRunLoopExit?事件，在收到回調(diào)時(shí)，遍歷所有之前放入隊(duì)列的待處理的任務(wù)，然后一一執(zhí)行。
具體的代碼可以看這里：_ASAsyncTransactionGroup。
RunLoop?需要深入理解
文章來(lái)源于網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系小編刪除！
全文完
