1 Runloop機(jī)制原理
深入理解RunLoop
http://www.cocoachina.com/ios/20150601/11970.html
1.1 RunLoop的概念
????????一般來(lái)講，一個(gè)線程一次只能執(zhí)行一個(gè)任務(wù)，執(zhí)行完成后線程就會(huì)退出。如果我們需要一個(gè)機(jī)制，讓線程能隨時(shí)處理事件但并不退出，通常的代碼邏輯是這樣的：
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 的代碼是開(kāi)源的，你可以在這里 http://opensource.apple.com/tarballs/CF/CF-855.17.tar.gz 下載到整個(gè) CoreFoundation 的源碼。為了方便跟蹤和查看，你可以新建一個(gè) Xcode 工程，把這堆源碼拖進(jìn)去看。
1.2 RunLoop與線程的關(guān)系
????????首先，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_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
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)線程銷(xiāo)毀時(shí)，順便也銷(xiāo)毀其對(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 的銷(xiāo)毀是發(fā)生在線程結(jié)束時(shí)。你只能在一個(gè)線程的內(nèi)部獲取其 RunLoop（主線程除外）。
1.3 RunLoop對(duì)外的接口
????????在 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被稱作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è)：
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)。
1.4 RunLoop的Mode
????????CFRunLoopMode和CFRunLoop的結(jié)構(gòu)大致如下：
struct?__CFRunLoopMode?{
????//?Mode?Name,?例如?@"kCFRunLoopDefaultMode"
????CFStringRef?_name;
????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切換為T(mén)rackingRunLoopMode，這時(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è):
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。
1.5 RunLoop的內(nèi)部邏輯(再細(xì)讀一遍)
????根據(jù)蘋(píng)果在文檔里的說(shuō)明，RunLoop 內(nèi)部的邏輯大致如下:
????????其內(nèi)部代碼整理如下 （太長(zhǎng)了不想看可以直接跳過(guò)去，后面會(huì)有說(shuō)明）：
///?用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ì)返回。
1.6 RunLoop的底層實(shí)現(xiàn)(再細(xì)讀一遍)
????????從上面代碼可以看到，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)用層包括用戶能接觸到的圖形應(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)被稱作 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非?；A(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)單：
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)記了消息傳遞的方向：
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() (見(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。
1.7 蘋(píng)果用RunLoop實(shí)現(xiàn)的功能(再細(xì)讀一遍)
????????首先我們可以看一下 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:
????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í)際作用。
????????你可以在這里看到更多的蘋(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);
}
1.8 直線型線程與圓形線程
????????有些線程執(zhí)行的任務(wù)是一條直線，起點(diǎn)到終點(diǎn)；而另一些線程要干的活則是一個(gè)圓，不斷循環(huán)，直到通過(guò)某種方式將它終止。
?????? 這兩類(lèi)線程能很好的區(qū)別Web開(kāi)發(fā)與客戶端開(kāi)發(fā)，Web開(kāi)發(fā)中，每次響應(yīng)都是直線線程，執(zhí)行完后即釋放資源，結(jié)束了；而客戶端開(kāi)發(fā)中，每次事件響應(yīng)其實(shí)都是產(chǎn)生一個(gè)圓，執(zhí)行操作雖然完成了，但是重要資源與上下文狀態(tài)都存儲(chǔ)在后臺(tái)。
?????? 對(duì)應(yīng)Web開(kāi)發(fā)的進(jìn)一步理解：Web開(kāi)發(fā)中，中間件層其實(shí)也是操作系統(tǒng)服務(wù)級(jí)別的，即它也是一個(gè)runloop；而對(duì)于中間件層里面的站點(diǎn)，則是直線處理型線程，從接收到請(qǐng)求到響應(yīng)請(qǐng)求結(jié)束，執(zhí)行完后此線程即結(jié)束了。
?????? 每個(gè)線程，包括程序的主線程（main thread）都有與之相應(yīng)的run loop對(duì)象。
? ??????主線程的runloop默認(rèn)是啟動(dòng)的。iOS的應(yīng)用程序里面，程序啟動(dòng)后會(huì)有一個(gè)如下的main()函數(shù)：
int main(int argc, char* argv[])
{
? ? @autoreleasepool{
????? ??return UIApplicationMain(argc, argv, nil, NSStringFromClass([appDelegate class]));
????}
}
????????重點(diǎn)是UIApplicationMain()函數(shù)，這個(gè)方法會(huì)為main thread設(shè)置一個(gè)NSRunLoop對(duì)象。
? ??????對(duì)其它線程來(lái)說(shuō)，run loop默認(rèn)是沒(méi)有啟動(dòng)的，如果你需要更多的線程交互則可以手動(dòng)配置和啟動(dòng)，如果線程只是去執(zhí)行一個(gè)長(zhǎng)時(shí)間的已確定的任務(wù)則不需要。
2 線程與run loop
2.1 線程任務(wù)的類(lèi)型
????????再來(lái)說(shuō)說(shuō)線程。有些線程執(zhí)行的任務(wù)是一條直線，起點(diǎn)到終點(diǎn)；而另一些線程要干的活則是一個(gè)圓，不斷循環(huán)，直到通過(guò)某種方式將它終止。直線線程如簡(jiǎn)單的Hello World，運(yùn)行打印完,它的生命周期便結(jié)束了，像曇花一現(xiàn)那樣；圓類(lèi)型的如操作系統(tǒng)，一直運(yùn)行直到你關(guān)機(jī)。在IOS中，圓型的線程就是通過(guò)run loop不停的循環(huán)實(shí)現(xiàn)的。
2.2 線程與run loop的關(guān)系
????????Run loop，正如其名，loop表示某種循環(huán)，和run放在一起就表示一直在運(yùn)行著的循環(huán)。實(shí)際上，run loop和線程是緊密相連的，可以這樣說(shuō)run loop是為了線程而生，沒(méi)有線程，它就沒(méi)有存在的必要。Run loops是線程的基礎(chǔ)架構(gòu)部分，Cocoa和CoreFundation都提供了run loop對(duì)象方便配置和管理線程的run loop（以下都已Cocoa為例）。每個(gè)線程，包括程序的主線程（main thread）都有與之相應(yīng)的run loop對(duì)象。
2.2.1 主線程的Runloop
????????主線程的run loop默認(rèn)是啟動(dòng)的。iOS的應(yīng)用程序里面，程序啟動(dòng)后會(huì)有一個(gè)如下的main()函數(shù)：
int main(int argc,char*argv[])
{
? ? ?@autoreleasepool{
????? ??return UIApplicationMain(argc, argv, nil, NSStringFromClass([appDelegate class]));
????}
}
????????重點(diǎn)是UIApplicationMain()函數(shù)，這個(gè)方法會(huì)為main thread設(shè)置一個(gè)NSRunLoop對(duì)象，這就解釋了本文開(kāi)始說(shuō)的為什么我們的應(yīng)用可以在無(wú)人操作的時(shí)候休息，需要讓它干活的時(shí)候又能立馬響應(yīng)。
2.2.2 其他線程的Runloop
????????對(duì)其它線程來(lái)說(shuō)，run loop默認(rèn)是沒(méi)有啟動(dòng)的，如果你需要更多的線程交互則可以手動(dòng)配置和啟動(dòng)，如果線程只是去執(zhí)行一個(gè)長(zhǎng)時(shí)間的已確定的任務(wù)則不需要。
2.2.3 當(dāng)前線程的Runloop獲取
????????在任何一個(gè)Cocoa程序的線程中，都可以通過(guò)：
NSRunLoop?? *runloop = [NSRunLoop currentRunLoop];
來(lái)獲取到當(dāng)前線程的run loop。
2.3 關(guān)于run loop的幾點(diǎn)說(shuō)明
2.3.1 Cocoa中的NSRunLoop類(lèi)并不是線程安全的
????????我們不能在一個(gè)線程中去操作另外一個(gè)線程的run loop對(duì)象，那很可能會(huì)造成意想不到的后果。不過(guò)幸運(yùn)的是CoreFundation中的不透明類(lèi)CFRunLoopRef是線程安全的，而且兩種類(lèi)型的run loop完全可以混合使用。Cocoa中的NSRunLoop類(lèi)可以通過(guò)實(shí)例方法：
- (CFRunLoopRef)getCFRunLoop;
????????獲取對(duì)應(yīng)的CFRunLoopRef類(lèi)，來(lái)達(dá)到線程安全的目的。
2.3.2 Runloop的管理并不完全是自動(dòng)的。
????????我們?nèi)员仨氃O(shè)計(jì)線程代碼以在適當(dāng)?shù)臅r(shí)候啟動(dòng)run loop并正確響應(yīng)輸入事件，當(dāng)然前提是線程中需要用到run loop。而且，我們還需要使用while/for語(yǔ)句來(lái)驅(qū)動(dòng)run loop能夠循環(huán)運(yùn)行，下面的代碼就成功驅(qū)動(dòng)了一個(gè)run loop：
BOOL isRunning = NO;
do{
????isRunning = [[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
} while(isRunning);
2.3.3 Runloop與autorelease的關(guān)系
????????Run loop同時(shí)也負(fù)責(zé)autorelease pool的創(chuàng)建和釋放。
????????在使用手動(dòng)的內(nèi)存管理方式的項(xiàng)目中，會(huì)經(jīng)常用到很多自動(dòng)釋放的對(duì)象，如果這些對(duì)象不能夠被即時(shí)釋放掉，會(huì)造成內(nèi)存占用量急劇增大。Run loop就為我們做了這樣的工作，每當(dāng)一個(gè)運(yùn)行循環(huán)啟動(dòng)時(shí)，系統(tǒng)會(huì)自動(dòng)創(chuàng)建一個(gè)autoreleasepool，用于掛載在此Runloop執(zhí)行期間生成的autorelease對(duì)象，而在Runloop結(jié)束的時(shí)候，它都會(huì)釋放此autorelease pool，同時(shí)pool中的所有autorelease類(lèi)型變量都會(huì)被釋放掉。
2.4 Run loop的優(yōu)點(diǎn)
????????一個(gè)run loop就是一個(gè)事件處理循環(huán)，用來(lái)不停的監(jiān)聽(tīng)和處理輸入事件并將其分配到對(duì)應(yīng)的目標(biāo)上進(jìn)行處理。如果僅僅是想實(shí)現(xiàn)這個(gè)功能，你可能會(huì)想一個(gè)簡(jiǎn)單的while循環(huán)不就可以實(shí)現(xiàn)了嗎，用得著費(fèi)老大勁來(lái)做個(gè)那么復(fù)雜的機(jī)制？顯然，蘋(píng)果的架構(gòu)設(shè)計(jì)師不是吃干飯的，你想到的他們?cè)缇拖脒^(guò)了。
????????首先，NSRunLoop是一種更加高明的消息處理模式，他就高明在對(duì)消息處理過(guò)程進(jìn)行了更好的抽象和封裝，這樣才能使你不用處理一些很瑣碎很低層次的具體消息的處理，在NSRunLoop中每一個(gè)消息就被打包在input source或者是timer source（見(jiàn)后文）中了。
????????其次，也是很重要的一點(diǎn)，使用run loop可以使你的線程在有工作的時(shí)候工作，沒(méi)有工作的時(shí)候休眠，這可以大大節(jié)省系統(tǒng)資源。
3 Runloop相關(guān)知識(shí)點(diǎn)
????????Run loop接收輸入事件來(lái)自兩種不同的來(lái)源：輸入源（input source）和定時(shí)源（timer source）。兩種源都使用程序的某一特定的處理例程來(lái)處理到達(dá)的事件。圖-1顯示了run loop的概念結(jié)構(gòu)以及各種源。
3.1 輸入事件來(lái)源
????????需要說(shuō)明的是，當(dāng)你創(chuàng)建輸入源，你需要將其分配給run loop中的一個(gè)或多個(gè)模式（什么是模式，下文將會(huì)講到）。模式只會(huì)在特定事件影響監(jiān)聽(tīng)的源。大多數(shù)情況下，run loop運(yùn)行在默認(rèn)模式下，但是你也可以使其運(yùn)行在自定義模式。若某一源在當(dāng)前模式下不被監(jiān)聽(tīng)，那么任何其生成的消息只在run loop運(yùn)行在其關(guān)聯(lián)的模式下才會(huì)被傳遞。
3.1.1 輸入源（input source）
????????傳遞異步事件，通常消息來(lái)自于其他線程或程序。輸入源傳遞異步消息給相應(yīng)的處理例程，并調(diào)用runUntilDate:方法來(lái)退出(在線程里面相關(guān)的NSRunLoop對(duì)象調(diào)用)。
3.1.1.1 基于端口的輸入源
????????基于端口的輸入源由內(nèi)核自動(dòng)發(fā)送。
????????Cocoa和Core Foundation內(nèi)置支持使用端口相關(guān)的對(duì)象和函數(shù)來(lái)創(chuàng)建的基于端口的源。例如，在Cocoa里面你從來(lái)不需要直接創(chuàng)建輸入源。你只要簡(jiǎn)單的創(chuàng)建端口對(duì)象，并使用NSPort的方法把該端口添加到runloop。端口對(duì)象會(huì)自己處理創(chuàng)建和配置輸入源。
????????在Core Foundation，你必須人工創(chuàng)建端口和它的run loop源。我們可以使用端口相關(guān)的函數(shù)（CFMachPortRef，CFMessagePortRef，CFSocketRef）來(lái)創(chuàng)建合適的對(duì)象。下面的例子展示了如何創(chuàng)建一個(gè)基于端口的輸入源，將其添加到run loop并啟動(dòng)：
void createPortSource()
{
??? CFMessagePortRef port = CFMessagePortCreateLocal(kCFAllocatorDefault, CFSTR("com.someport"), myCallbackFunc, NULL, NULL);
???CFRunLoopSourceRef source =?CFMessagePortCreateRunLoopSource (kCFAllocatorDefault, port, 0);
???CFRunLoopAddSource(CFRunLoopGetCurrent(), source, kCFRunLoopCommonModes);
???while (pageStillLoading) {
? ? ? ? NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
? ? ? ? CFRunLoopRun();
????????[pool release];
????}
???CFRunLoopRemoveSource(CFRunLoopGetCurrent(), source, kCFRunLoopDefaultMode);
???CFRelease(source);
}
3.1.1.2 自定義輸入源
????????自定義的輸入源需要人工從其他線程發(fā)送。
????????為了創(chuàng)建自定義輸入源，必須使用Core Foundation里面的CFRunLoopSourceRef類(lèi)型相關(guān)的函數(shù)來(lái)創(chuàng)建。你可以使用回調(diào)函數(shù)來(lái)配置自定義輸入源。Core Fundation會(huì)在配置源的不同地方調(diào)用回調(diào)函數(shù)，處理輸入事件，在源從run loop移除的時(shí)候清理它。
????????除了定義在事件到達(dá)時(shí)自定義輸入源的行為，你也必須定義消息傳遞機(jī)制。源的這部分運(yùn)行在單獨(dú)的線程里面，并負(fù)責(zé)在數(shù)據(jù)等待處理的時(shí)候傳遞數(shù)據(jù)給源并通知它處理數(shù)據(jù)。消息傳遞機(jī)制的定義取決于你，但最好不要過(guò)于復(fù)雜。創(chuàng)建并啟動(dòng)自定義輸入源的示例如下：
void createCustomSource()
{
???CFRunLoopSourceContext context = {0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL};
???CFRunLoopSourceRef source =CFRunLoopSourceCreate(kCFAllocatorDefault, 0, &context);
???CFRunLoopAddSource(CFRunLoopGetCurrent(), source, kCFRunLoopDefaultMode);
???while (pageStillLoading) {
???????NSAutoreleasePool *pool = [[NSAutoreleasePoolalloc] init];
???????CFRunLoopRun();
????????[pool release];
????}
???CFRunLoopRemoveSource(CFRunLoopGetCurrent(), source, kCFRunLoopDefaultMode);
???CFRelease(source);
}
3.1.1.3 Cocoa上的Selector源
????????除了基于端口的源，Cocoa定義了自定義輸入源，允許你在任何線程執(zhí)行selector方法。和基于端口的源一樣，執(zhí)行selector請(qǐng)求會(huì)在目標(biāo)線程上序列化，減緩許多在線程上允許多個(gè)方法容易引起的同步問(wèn)題。不像基于端口的源，一個(gè)selector執(zhí)行完后會(huì)自動(dòng)從run loop里面移除。
????????當(dāng)在其他線程上面執(zhí)行selector時(shí)，目標(biāo)線程須有一個(gè)活動(dòng)的run loop。對(duì)于你創(chuàng)建的線程，這意味著線程在你顯式的啟動(dòng)run loop之前是不會(huì)執(zhí)行selector方法的，而是一直處于休眠狀態(tài)。
????????NSObject類(lèi)提供了類(lèi)似如下的selector方法：
- (void) performSelectorOnMainThread: (SEL)aSelector withObject: (id)argwaitUntilDone: (BOOL)wait modes: (NSArray*)array;
3.1.2 定時(shí)源（timer source）
????????定時(shí)源在預(yù)設(shè)的時(shí)間點(diǎn)同步方式傳遞消息，這些消息都會(huì)發(fā)生在特定時(shí)間或者重復(fù)的時(shí)間間隔。定時(shí)源則直接傳遞消息給處理例程，不會(huì)立即退出run loop。
????????需要注意的是，盡管定時(shí)器可以產(chǎn)生基于時(shí)間的通知，但它并不是實(shí)時(shí)機(jī)制。和輸入源一樣，定時(shí)器也和你的run loop的特定模式相關(guān)。如果定時(shí)器所在的模式當(dāng)前未被run loop監(jiān)視，那么定時(shí)器將不會(huì)開(kāi)始直到run loop運(yùn)行在相應(yīng)的模式下。類(lèi)似的，如果定時(shí)器在run loop處理某一事件期間開(kāi)始，定時(shí)器會(huì)一直等待直到下次run loop開(kāi)始相應(yīng)的處理程序。如果run loop不再運(yùn)行，那定時(shí)器也將永遠(yuǎn)不啟動(dòng)。
????????創(chuàng)建定時(shí)器源有兩種方法，方法一：
NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval: 4.0 target: self selector: @selector(backgroundThreadFire:) userInfo: nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer: timer forMode: NSDefaultRunLoopMode];
方法二：
[NSTimer scheduledTimerWithTimeInterval:10 target: self selector: @selector(backgroundThreadFire:) userInfo: nil repeats: YES];
3.2 RunLoop觀察者
????????源是在合適的同步或異步事件發(fā)生時(shí)觸發(fā)，而run loop觀察者則是在run loop本身運(yùn)行的特定時(shí)候觸發(fā)。你可以使用run loop觀察者來(lái)為處理某一特定事件或是進(jìn)入休眠的線程做準(zhǔn)備。你可以將run loop觀察者和以下事件關(guān)聯(lián)：
????1. Runloop入口
????2.? Runloop何時(shí)處理一個(gè)定時(shí)器
????3. Runloop何時(shí)處理一個(gè)輸入源
????4. Runloop何時(shí)進(jìn)入睡眠狀態(tài)
????5. Runloop何時(shí)被喚醒，但在喚醒之前要處理的事件
????6. Runloop終止
????????和定時(shí)器類(lèi)似，在創(chuàng)建的時(shí)候你可以指定run loop觀察者可以只用一次或循環(huán)使用。若只用一次，那么在它啟動(dòng)后，會(huì)把它自己從run loop里面移除，而循環(huán)的觀察者則不會(huì)。定義觀察者并把它添加到run loop，只能使用Core Fundation。下面的例子演示了如何創(chuàng)建run loop的觀察者：
- (void) addObserverToCurrentRunloop
{
???// The application uses garbage collection, so no autorelease pool is needed.
????NSRunLoop*myRunLoop = [NSRunLoop currentRunLoop];
???// Create a run loop observer and attach it to the runloop.
???CFRunLoopObserverContext? context = {0, self, NULL, NULL, NULL};
???CFRunLoopObserverRef observer = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopBeforeTimers, YES, 0, &myRunLoopObserver, &context);
???if (observer) {
???????CFRunLoopRef cfLoop = [myRunLoop getCFRunLoop];
????????CFRunLoopAddObserver(cfLoop, observer, kCFRunLoopDefaultMode);
????}
}
????????其中，kCFRunLoopBeforeTimers表示選擇監(jiān)聽(tīng)定時(shí)器觸發(fā)前處理事件，后面的YES表示循環(huán)監(jiān)聽(tīng)。
3.3 RunLoop的事件隊(duì)列
????????每次運(yùn)行run loop，你線程的run loop對(duì)會(huì)自動(dòng)處理之前未處理的消息，并通知相關(guān)的觀察者。具體的順序如下：
????1. 通知觀察者run loop已經(jīng)啟動(dòng)
????2. 通知觀察者任何即將要開(kāi)始的定時(shí)器
????3. 通知觀察者任何即將啟動(dòng)的非基于端口的源
????4. 啟動(dòng)任何準(zhǔn)備好的非基于端口的源
????5. 如果基于端口的源準(zhǔn)備好并處于等待狀態(tài)，立即啟動(dòng)；并進(jìn)入步驟9。
????6. 通知觀察者線程進(jìn)入休眠
????7. 將線程置于休眠直到任一下面的事件發(fā)生：
????????· 某一事件到達(dá)基于端口的源
????????· 定時(shí)器啟動(dòng)
????????· Run loop設(shè)置的時(shí)間已經(jīng)超時(shí)
????????· run loop被顯式喚醒
????8. 通知觀察者線程將被喚醒。
? ? 9. 處理未處理的事件
????????· 如果用戶定義的定時(shí)器啟動(dòng)，處理定時(shí)器事件并重啟run loop。進(jìn)入步驟2
????????· 如果輸入源啟動(dòng)，傳遞相應(yīng)的消息
????????· 如果run loop被顯式喚醒而且時(shí)間還沒(méi)超時(shí)，重啟run loop。進(jìn)入步驟2
????10. 通知觀察者run loop結(jié)束。
????????因?yàn)槎〞r(shí)器和輸入源的觀察者是在相應(yīng)的事件發(fā)生之前傳遞消息，所以通知的時(shí)間和實(shí)際事件發(fā)生的時(shí)間之間可能存在誤差。如果需要精確時(shí)間控制，你可以使用休眠和喚醒通知來(lái)幫助你校對(duì)實(shí)際發(fā)生事件的時(shí)間。
????????因?yàn)楫?dāng)你運(yùn)行run loop時(shí)定時(shí)器和其它周期性事件經(jīng)常需要被傳遞，撤銷(xiāo)run loop也會(huì)終止消息傳遞。典型的例子就是鼠標(biāo)路徑追蹤。因?yàn)槟愕拇a直接獲取到消息而不是經(jīng)由程序傳遞，因此活躍的定時(shí)器不會(huì)開(kāi)始直到鼠標(biāo)追蹤結(jié)束并將控制權(quán)交給程序。
????????Run loop可以由run loop對(duì)象顯式喚醒。其它消息也可以喚醒run loop。例如，添加新的非基于端口的源會(huì)喚醒run loop從而可以立即處理輸入源而不需要等待其他事件發(fā)生后再處理。
????????從這個(gè)事件隊(duì)列中可以看出：
????①如果是事件到達(dá)，消息會(huì)被傳遞給相應(yīng)的處理程序來(lái)處理， runloop處理完當(dāng)次事件后，run loop會(huì)退出，而不管之前預(yù)定的時(shí)間到了沒(méi)有。你可以重新啟動(dòng)run loop來(lái)等待下一事件。
????②如果線程中有需要處理的源，但是響應(yīng)的事件沒(méi)有到來(lái)的時(shí)候，線程就會(huì)休眠等待相應(yīng)事件的發(fā)生。這就是為什么run loop可以做到讓線程有工作的時(shí)候忙于工作，而沒(méi)工作的時(shí)候處于休眠狀態(tài)。
3.4 什么時(shí)候使用run loop
????????僅當(dāng)在為你的程序創(chuàng)建輔助線程的時(shí)候，你才需要顯式運(yùn)行一個(gè)run loop。Run loop是程序主線程基礎(chǔ)設(shè)施的關(guān)鍵部分。所以，Cocoa和Carbon程序提供了代碼運(yùn)行主程序的循環(huán)并自動(dòng)啟動(dòng)run loop。IOS程序中UIApplication的run方法（或Mac OS X中的NSApplication）作為程序啟動(dòng)步驟的一部分，它在程序正常啟動(dòng)的時(shí)候就會(huì)啟動(dòng)程序的主循環(huán)。類(lèi)似的，RunApplicationEventLoop函數(shù)為Carbon程序啟動(dòng)主循環(huán)。如果你使用xcode提供的模板創(chuàng)建你的程序，那你永遠(yuǎn)不需要自己去顯式的調(diào)用這些例程。
????????對(duì)于輔助線程，你需要判斷一個(gè)run loop是否是必須的。如果是必須的，那么你要自己配置并啟動(dòng)它。你不需要在任何情況下都去啟動(dòng)一個(gè)線程的run loop。比如，你使用線程來(lái)處理一個(gè)預(yù)先定義的長(zhǎng)時(shí)間運(yùn)行的任務(wù)時(shí)，你應(yīng)該避免啟動(dòng)run loop。Run loop在你要和線程有更多的交互時(shí)才需要，比如以下情況：
????1. 使用端口或自定義輸入源來(lái)和其他線程通信
????2. 使用線程的定時(shí)器
????3. Cocoa中使用任何performSelector…的方法
????4. 使線程周期性工作
????????如果你決定在程序中使用run loop，那么它的配置和啟動(dòng)都很簡(jiǎn)單。和所有線程編程一樣，你需要計(jì)劃好在輔助線程退出線程的情形。讓線程自然退出往往比強(qiáng)制關(guān)閉它更好。
4 基于Runloop實(shí)現(xiàn)的上層功能
4.1 AutoreleasePool
????????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 了。
4.2 事件響應(yīng)（Good）
????????蘋(píng)果注冊(cè)了一個(gè) Source1 (基于 mach port 的) 用來(lái)接收系統(tǒng)事件，其回調(diào)函數(shù)為_(kāi)_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)中完成的。
4.3 手勢(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)記為待處理。蘋(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)處理。
4.4 界面更新
????????當(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];
4.5 定時(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 開(kāi)源的 AsyncDisplayLink 就是為了解決界面卡頓的問(wèn)題，其內(nèi)部也用到了 RunLoop，這個(gè)稍后我會(huì)再單獨(dú)寫(xiě)一頁(yè)博客來(lái)分析。
4.6 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ì)失效。
4.7 關(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 處理的。
4.8 關(guān)于網(wǎng)絡(luò)請(qǐng)求
????????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ì)獲取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)。
4.9 RunLoop的實(shí)際應(yīng)用舉例
4.9.1 AFNetworking
????????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?{
????????[[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ā)送消息。
-?(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中。
4.9.2 AsyncDisplayKit
????????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í)后面的操作需要依賴前面操作的結(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。
5 Runloop實(shí)踐思考
5.1 Runloop在動(dòng)畫(huà)重復(fù)提交調(diào)用中的限制
????????對(duì)于控件簡(jiǎn)單屬性的賦值等操作，在同一個(gè)Runloop中重復(fù)設(shè)置，最終起作用的會(huì)是最后一次，但是如果對(duì)控件的變化通過(guò)動(dòng)畫(huà)來(lái)實(shí)現(xiàn)，則每一次設(shè)置動(dòng)作都會(huì)向系統(tǒng)提交一次動(dòng)畫(huà)執(zhí)行命令，而不只是最后一次動(dòng)畫(huà)。典型運(yùn)用場(chǎng)景例如導(dǎo)航條的顯示與隱藏：
?????? 不是簡(jiǎn)單通過(guò)子類(lèi)中復(fù)寫(xiě)viewdidload方法，重新設(shè)置導(dǎo)航條的顯示屬性就可以的，涉及動(dòng)畫(huà)的，最好只設(shè)置一次，例如只在子類(lèi)中設(shè)置，而父類(lèi)就不要設(shè)置了。
??? if ([self class] == [HJBaseWebVC class]) {
??????? [self.navigationController setNavigationBarHidden:YES animated:YES];
??? }
6 參考文檔
?http://blog.csdn.net/wzzvictory/article/details/9237973
iOS-RunLoop
http://www.tuicool.com/articles/zeey63u
（good）深入理解RunLoop
