1 Runloop機(jī)制原理
深入理解RunLoop
http://www.cocoachina.com/ios/20150601/11970.html
1.1 RunLoop的概念
????????一般來講，一個線程一次只能執(zhí)行一個任務(wù)，執(zhí)行完成后線程就會退出。如果我們需要一個機(jī)制，讓線程能隨時處理事件但并不退出，通常的代碼邏輯是這樣的：
function?loop()?{
????initialize();
????do{
????????var?message?=?get_next_message();
????????process_message(message);
????}?while(message?!=?quit);
}
????????這種模型通常被稱作 Event?Loop。 Event Loop 在很多系統(tǒng)和框架里都有實現(xiàn)，比如 Node.js 的事件處理，比如 Windows 程序的消息循環(huán)，再比如 OSX/iOS 里的 RunLoop。實現(xiàn)這種模型的關(guān)鍵點在于：如何管理事件/消息，如何讓線程在沒有處理消息時休眠以避免資源占用、在有消息到來時立刻被喚醒。
????????所以，RunLoop 實際上就是一個對象，這個對象管理了其需要處理的事件和消息，并提供了一個入口函數(shù)來執(zhí)行上面 Event Loop 的邏輯。線程執(zhí)行了這個函數(shù)后，就會一直處于這個函數(shù)內(nèi)部 "接受消息->等待->處理" 的循環(huán)中，直到這個循環(huán)結(jié)束（比如傳入 quit 的消息），函數(shù)返回。
????????OSX/iOS 系統(tǒng)中，提供了兩個這樣的對象：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 下載到整個 CoreFoundation 的源碼。為了方便跟蹤和查看，你可以新建一個 Xcode 工程，把這堆源碼拖進(jìn)去看。
1.2 RunLoop與線程的關(guān)系
????????首先，iOS 開發(fā)中能遇到兩個線程對象: pthread_t 和 NSThread。過去蘋果有份文檔標(biāo)明了 NSThread 只是 pthread_t 的封裝，但那份文檔已經(jīng)失效了，現(xiàn)在它們也有可能都是直接包裝自最底層的 mach thread。蘋果并沒有提供這兩個對象相互轉(zhuǎn)換的接口，但不管怎么樣，可以肯定的是 pthread_t 和NSThread 是一一對應(yīng)的。比如，你可以通過 pthread_main_np() 或 [NSThread mainThread] 來獲取主線程；也可以通過 pthread_self() 或 [NSThread currentThread] 來獲取當(dāng)前線程。CFRunLoop 是基于 pthread 來管理的。
????????蘋果不允許直接創(chuàng)建 RunLoop，它只提供了兩個自動獲取的函數(shù)：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 這兩個函數(shù)內(nèi)部的邏輯大概是下面這樣:
///?全局的Dictionary，key?是?pthread_t，?value?是?CFRunLoopRef
static?CFMutableDictionaryRef?loopsDic;
///?訪問?loopsDic?時的鎖
static?CFSpinLock_t?loopsLock;
///?獲取一個?pthread?對應(yīng)的?RunLoop。
CFRunLoopRef?_CFRunLoopGet(pthread_t?thread)?{
????OSSpinLockLock(&loopsLock);
????if?(!loopsDic)?{
????????//?第一次進(jìn)入時，初始化全局Dic，并先為主線程創(chuàng)建一個?RunLoop。
????????loopsDic?=?CFDictionaryCreateMutable();
????????CFRunLoopRef?mainLoop?=?_CFRunLoopCreate();
????????CFDictionarySetValue(loopsDic,?pthread_main_thread_np(),?mainLoop);
????}
????///?直接從?Dictionary?里獲取。
????CFRunLoopRef?loop?=?CFDictionaryGetValue(loopsDic,?thread));
? ??if?(!loop)?{
? ? ????///?取不到時，創(chuàng)建一個
????????loop?=?_CFRunLoopCreate();
????????CFDictionarySetValue(loopsDic,?thread,?loop);
? ? ?????///?注冊一個回調(diào)，當(dāng)線程銷毀時，順便也銷毀其對應(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 之間是一一對應(yīng)的，其映射關(guān)系是保存在一個全局的 Dictionary 里。線程剛創(chuàng)建時并沒有 RunLoop，如果你不主動獲取，那它一直都不會有。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時，RunLoop 的銷毀是發(fā)生在線程結(jié)束時。你只能在一個線程的內(nèi)部獲取其 RunLoop（主線程除外）。
1.3 RunLoop對外的接口
????????在 CoreFoundation 里面關(guān)于 RunLoop 有5個類:
????? CFRunLoopRef
????? CFRunLoopModeRef
????? CFRunLoopSourceRef
????? CFRunLoopTimerRef
????? CFRunLoopObserverRef
????????其中 CFRunLoopModeRef 類并沒有對外暴露，只是通過 CFRunLoopRef 的接口進(jìn)行了封裝。他們的關(guān)系如下:
????????一個 RunLoop 包含若干個 Mode，每個 Mode 又包含若干個 Source/ Timer/Observer。每次調(diào)用RunLoop的主函數(shù)時，只能指定其中一個Mode，這個Mode被稱作CurrentMode。如果需要切換Mode，只能退出Loop，再重新指定一個Mode進(jìn)入。這樣做主要是為了分隔開不同組的Source/Timer/Observer，讓其互不影響。
? ??????CFRunLoopSourceRef 是事件產(chǎn)生的地方。Source有兩個版本：Source0 和 Source1。
????? Source0 只包含了一個回調(diào)（函數(shù)指針），它并不能主動觸發(fā)事件。使用時，你需要先調(diào)用CFRunLoopSourceSignal(source)，將這個 Source 標(biāo)記為待處理，然后手動調(diào)用CFRunLoopWakeUp(runloop) 來喚醒RunLoop，讓其處理這個事件。
????? Source1 包含了一個mach_port和一個回調(diào)（函數(shù)指針），被用于通過內(nèi)核和其他線程相互發(fā)送消息。這種Source能主動喚醒RunLoop的線程，其原理在下面會講到。
? ??????CFRunLoopTimerRef 是基于時間的觸發(fā)器，它和NSTimer是toll-free bridged的，可以混用。其包含一個時間長度和一個回調(diào)（函數(shù)指針）。當(dāng)其加入到RunLoop時，RunLoop會注冊對應(yīng)的時間點，當(dāng)時間點到時，RunLoop會被喚醒以執(zhí)行那個回調(diào)。
? ??????CFRunLoopObserverRef 是觀察者，每個 Observer 都包含了一個回調(diào)（函數(shù)指針），當(dāng)RunLoop的狀態(tài)發(fā)生變化時，觀察者就能通過回調(diào)接受到這個變化。可以觀測的時間點有以下幾個：
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，一個item可以被同時加入多個mode。但一個item被重復(fù)加入同一個mode時是不會有效果的。如果一個mode中一個item都沒有，則RunLoop會直接退出，不進(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
????...
};
????????這里有個概念叫"CommonModes"：一個 Mode 可以將自己標(biāo)記為"Common"屬性（通過將其ModeName添加到RunLoop的"commonModes"中）。每當(dāng)RunLoop的內(nèi)容發(fā)生變化時，RunLoop都會自動將 _commonModeItems里的Source/Observer/Timer同步到具有"Common"標(biāo)記的所有Mode里。
????????應(yīng)用場景舉例：主線程的RunLoop里有兩個預(yù)置的 Mode：kCFRunLoopDefaultMode和UITrackingRunLoopMode。這兩個Mode都已經(jīng)被標(biāo)記為"Common"屬性。DefaultMode是App平時所處的狀態(tài)，TrackingRunLoopMode是追蹤ScrollView滑動時的狀態(tài)。當(dāng)你創(chuàng)建一個Timer 并加到DefaultMode時，Timer會得到重復(fù)回調(diào)，但此時滑動一個TableView時，RunLoop會將mode切換為TrackingRunLoopMode，這時Timer就不會被回調(diào)，并且也不會影響到滑動操作。
????????有時你需要一個Timer，在兩個Mode中都能得到回調(diào)，一種辦法就是將這個 Timer分別加入這兩個Mode。還有一種方式，就是將Timer加入到頂層的 RunLoop的 "commonModeItems" 中。 "commonModeItems" 被RunLoop自動更新到所有具有"Common"屬性的Mode里去。
????????CFRunLoop對外暴露的管理Mode接口只有下面2個:
CFRunLoopAddCommonMode(CFRunLoopRef?runloop,?CFStringRef?modeName);
CFRunLoopRunInMode(CFStringRef?modeName,?...);
????????Mode暴露的管理mode item的接口有下面幾個：
CFRunLoopAddSource(CFRunLoopRef?rl, CFRunLoopSourceRef?source,?CFStringRef?modeName);
CFRunLoopAddObserver(CFRunLoopRef?rl,?CFRunLoopObserverRef?observer, CFStringRef?modeName);
CFRunLoopAddTimer(CFRunLoopRef?rl,?CFRunLoopTimerRef?timer,?CFStringRef?mode);
CFRunLoopRemoveSource(CFRunLoopRef?rl,?CFRunLoopSourceRef?source, CFStringRef?modeName);
CFRunLoopRemoveObserver(CFRunLoopRef?rl,?CFRunLoopObserverRef?observer, CFStringRef?modeName);
CFRunLoopRemoveTimer(CFRunLoopRef?rl,?CFRunLoopTimerRef?timer,?CFStringRef?mode);
????????你只能通過mode name來操作內(nèi)部的mode，當(dāng)你傳入一個新的mode name但RunLoop內(nèi)部沒有對應(yīng)mode時，RunLoop會自動幫你創(chuàng)建對應(yīng)的 CFRunLoopModeRef。對于一個RunLoop來說，其內(nèi)部的mode只能增加不能刪除。
????????蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode，你可以用這兩個 Mode Name 來操作其對應(yīng)的 Mode。
????????同時蘋果還提供了一個操作 Common 標(biāo)記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，你可以用這個字符串來操作 Common Items，或標(biāo)記一個 Mode 為 "Common"。使用時注意區(qū)分這個字符串和其他 mode name。
1.5 RunLoop的內(nèi)部邏輯(再細(xì)讀一遍)
????根據(jù)蘋果在文檔里的說明，RunLoop 內(nèi)部的邏輯大致如下:
????????其內(nèi)部代碼整理如下 （太長了不想看可以直接跳過去，后面會有說明）：
///?用DefaultMode啟動
void?CFRunLoopRun(void)?{
????CFRunLoopRunSpecific(CFRunLoopGetCurrent(),?kCFRunLoopDefaultMode,?1.0e10,?false);
}
///?用指定的Mode啟動，允許設(shè)置RunLoop超時時間
int?CFRunLoopRunInMode(CFStringRef?modeName,?CFTimeInterval?seconds,?Boolean?stopAfterHandle)?{
????return?CFRunLoopRunSpecific(CFRunLoopGetCurrent(),?modeName,?seconds,?returnAfterSourceHandled);
}
///?RunLoop的實現(xiàn)
int?CFRunLoopRunSpecific(runloop,?modeName,?seconds,?stopAfterHandle)?{
????///?首先根據(jù)modeName找到對應(yīng)mode
????CFRunLoopModeRef?currentMode?=?__CFRunLoopFindMode(runloop,?modeName,?false);
????///?如果mode里沒有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)，直接處理這個?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)入休眠,?直到被下面某一個事件喚醒。
????????????/// 一個基于?port?的Source?的事件。
????????????/// 一個?Timer?到時間了
????????????/// RunLoop?自身的超時時間到了
????????????/// 被其他什么調(diào)用者手動喚醒
????????????__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?如果一個?Timer?到時間了，觸發(fā)這個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?如果一個?Source1?(基于port)?發(fā)出事件了，處理這個事件
????????????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ù)說處理完事件就返回。
????????????????retVal?=?kCFRunLoopRunHandledSource;
????????????}?else?if?(timeout)?{
????????????????///?超出傳入?yún)?shù)標(biāo)記的超時時間了
????????????????retVal?=?kCFRunLoopRunTimedOut;
????????????}?else?if?(__CFRunLoopIsStopped(runloop))?{
????????????????///?被外部調(diào)用者強(qiáng)制停止了
????????????????retVal?=?kCFRunLoopRunStopped;
????????????}?else?if?(__CFRunLoopModeIsEmpty(runloop,?currentMode))?{
????????????????///?source/timer/observer一個都沒有了
????????????????retVal?=?kCFRunLoopRunFinished;
????????????}
????????????///?如果沒超時，mode里沒空，loop也沒被停止，那繼續(xù)loop。
????????}?while?(retVal?==?0);
????}
????///?10.?通知?Observers:?RunLoop?即將退出。
????__CFRunLoopDoObservers(rl,?currentMode,?kCFRunLoopExit);
}
????????可以看到，實際上 RunLoop 就是這樣一個函數(shù)，其內(nèi)部是一個 do-while 循環(huán)。當(dāng)你調(diào)用 CFRunLoopRun() 時，線程就會一直停留在這個循環(huán)里；直到超時或被手動停止，該函數(shù)才會返回。
1.6 RunLoop的底層實現(xiàn)(再細(xì)讀一遍)
????????從上面代碼可以看到，RunLoop 的核心是基于 mach port 的，其進(jìn)入休眠時調(diào)用的函數(shù)是 mach_msg()。為了解釋這個邏輯，下面稍微介紹一下 OSX/iOS 的系統(tǒng)架構(gòu)。
????????蘋果官方將整個系統(tǒng)大致劃分為上述4個層次：
????? 應(yīng)用層包括用戶能接觸到的圖形應(yīng)用，例如 Spotlight、Aqua、SpringBoard 等。
????? 應(yīng)用框架層即開發(fā)人員接觸到的 Cocoa 等框架。
????? 核心框架層包括各種核心框架、OpenGL 等內(nèi)容。
????? Darwin 即操作系統(tǒng)的核心，包括系統(tǒng)內(nèi)核、驅(qū)動、Shell 等內(nèi)容，這一層是開源的，其所有源碼都可以在 opensource.apple.com 里找到。
????????我們在深入看一下 Darwin 這個核心的架構(gòu)：
????????其中，在硬件層上面的三個組成部分：Mach、BSD、IOKit (還包括一些上面沒標(biāo)注的內(nèi)容)，共同組成了 XNU 內(nèi)核。
????????XNU 內(nèi)核的內(nèi)環(huán)被稱作 Mach，其作為一個微內(nèi)核，僅提供了諸如處理器調(diào)度、IPC (進(jìn)程間通信)等非常少量的基礎(chǔ)服務(wù)。
????????BSD 層可以看作圍繞 Mach 層的一個外環(huán)，其提供了諸如進(jìn)程管理、文件系統(tǒng)和網(wǎng)絡(luò)等功能。
????????IOKit 層是為設(shè)備驅(qū)動提供了一個面向?qū)ο?C++)的一個框架。
????????Mach 本身提供的 API 非常有限，而且蘋果也不鼓勵使用 Mach 的 API，但是這些API非常基礎(chǔ)，如果沒有這些API的話，其他任何工作都無法實施。在 Mach 中，所有的東西都是通過自己的對象實現(xiàn)的，進(jìn)程、線程和虛擬內(nèi)存都被稱為"對象"。和其他架構(gòu)不同， Mach 的對象間不能直接調(diào)用，只能通過消息傳遞的方式實現(xiàn)對象間的通信。"消息"是 Mach 中最基礎(chǔ)的概念，消息在兩個端口 (port) 之間傳遞，這就是 Mach 的 IPC (進(jìn)程間通信) 的核心。
????????Mach 的消息定義是在頭文件的，很簡單：
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 消息實際上就是一個二進(jìn)制數(shù)據(jù)包 (BLOB)，其頭部定義了當(dāng)前端口 local_port 和目標(biāo)端口 remote_port，發(fā)送和接受消息是通過同一個 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);
????????為了實現(xiàn)消息的發(fā)送和接收，mach_msg() 函數(shù)實際上是調(diào)用了一個 Mach 陷阱 (trap)，即函數(shù)mach_msg_trap()，陷阱這個概念在 Mach 中等同于系統(tǒng)調(diào)用。當(dāng)你在用戶態(tài)調(diào)用 mach_msg_trap() 時會觸發(fā)陷阱機(jī)制，切換到內(nèi)核態(tài)；內(nèi)核態(tài)中內(nèi)核實現(xiàn)的 mach_msg() 函數(shù)會完成實際的工作，如下圖：
????????這些概念可以參考維基百科: System_call、Trap_(computing)。
????????RunLoop 的核心就是一個 mach_msg() (見上面代碼的第7步)，RunLoop 調(diào)用這個函數(shù)去接收消息，如果沒有別人發(fā)送 port 消息過來，內(nèi)核會將線程置于等待狀態(tài)。例如你在模擬器里跑起一個 iOS 的 App，然后在 App 靜止時點擊暫停，你會看到主線程調(diào)用棧是停留在 mach_msg_trap() 這個地方。
????????關(guān)于具體的如何利用 mach port 發(fā)送信息，可以看看 NSHipster 這一篇文章，或者這里的中文翻譯 。
????????關(guān)于Mach的歷史可以看看這篇很有趣的文章：Mac?OS X 背后的故事（三）Mach 之父 Avie Tevanian。
1.7 蘋果用RunLoop實現(xiàn)的功能(再細(xì)讀一遍)
????????首先我們可以看一下 App 啟動后 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)注冊了5個Mode:
????1. kCFRunLoopDefaultMode: App的默認(rèn)Mode，通常主線程是在這個Mode下運(yùn)行的。
????2. UITrackingRunLoopMode: 界面跟蹤Mode，用于ScrollView追蹤觸摸滑動，保證界面滑動時不受其他Mode影響。
????3. UIInitializationRunLoopMode: 在剛啟動App時進(jìn)入的第一個Mode，啟動完成后就不再使用。
????4: GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內(nèi)部Mode，通常用不到。
????5: kCFRunLoopCommonModes: 這是一個占位的Mode，沒有實際作用。
????????你可以在這里看到更多的蘋果內(nèi)部的 Mode，但那些 Mode 在開發(fā)中就很難遇到了。
????????當(dāng)RunLoop進(jìn)行回調(diào)時，一般都是通過一個很長的函數(shù)調(diào)用出去 (call out), 當(dāng)你在你的代碼中下斷點調(diào)試時，通常能在調(diào)用棧上看到這些函數(shù)。下面是這幾個函數(shù)的整理版本，如果你在調(diào)用棧中看到這些長函數(shù)名，在這里查找一下就能定位到具體的調(diào)用地點了：
{
????///?1.?通知Observers，即將進(jìn)入RunLoop
????///?此處有Observer會創(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的)?的事件喚醒了，處理這個事件
????????__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ù)是一條直線，起點到終點；而另一些線程要干的活則是一個圓，不斷循環(huán)，直到通過某種方式將它終止。
?????? 這兩類線程能很好的區(qū)別Web開發(fā)與客戶端開發(fā)，Web開發(fā)中，每次響應(yīng)都是直線線程，執(zhí)行完后即釋放資源，結(jié)束了；而客戶端開發(fā)中，每次事件響應(yīng)其實都是產(chǎn)生一個圓，執(zhí)行操作雖然完成了，但是重要資源與上下文狀態(tài)都存儲在后臺。
?????? 對應(yīng)Web開發(fā)的進(jìn)一步理解：Web開發(fā)中，中間件層其實也是操作系統(tǒng)服務(wù)級別的，即它也是一個runloop；而對于中間件層里面的站點，則是直線處理型線程，從接收到請求到響應(yīng)請求結(jié)束，執(zhí)行完后此線程即結(jié)束了。
?????? 每個線程，包括程序的主線程（main thread）都有與之相應(yīng)的run loop對象。
? ??????主線程的runloop默認(rèn)是啟動的。iOS的應(yīng)用程序里面，程序啟動后會有一個如下的main()函數(shù)：
int main(int argc, char* argv[])
{
? ? @autoreleasepool{
????? ??return UIApplicationMain(argc, argv, nil, NSStringFromClass([appDelegate class]));
????}
}
????????重點是UIApplicationMain()函數(shù)，這個方法會為main thread設(shè)置一個NSRunLoop對象。
? ??????對其它線程來說，run loop默認(rèn)是沒有啟動的，如果你需要更多的線程交互則可以手動配置和啟動，如果線程只是去執(zhí)行一個長時間的已確定的任務(wù)則不需要。
2 線程與run loop
2.1 線程任務(wù)的類型
????????再來說說線程。有些線程執(zhí)行的任務(wù)是一條直線，起點到終點；而另一些線程要干的活則是一個圓，不斷循環(huán)，直到通過某種方式將它終止。直線線程如簡單的Hello World，運(yùn)行打印完,它的生命周期便結(jié)束了，像曇花一現(xiàn)那樣；圓類型的如操作系統(tǒng)，一直運(yùn)行直到你關(guān)機(jī)。在IOS中，圓型的線程就是通過run loop不停的循環(huán)實現(xiàn)的。
2.2 線程與run loop的關(guān)系
????????Run loop，正如其名，loop表示某種循環(huán)，和run放在一起就表示一直在運(yùn)行著的循環(huán)。實際上，run loop和線程是緊密相連的，可以這樣說run loop是為了線程而生，沒有線程，它就沒有存在的必要。Run loops是線程的基礎(chǔ)架構(gòu)部分，Cocoa和CoreFundation都提供了run loop對象方便配置和管理線程的run loop（以下都已Cocoa為例）。每個線程，包括程序的主線程（main thread）都有與之相應(yīng)的run loop對象。
2.2.1 主線程的Runloop
????????主線程的run loop默認(rèn)是啟動的。iOS的應(yīng)用程序里面，程序啟動后會有一個如下的main()函數(shù)：
int main(int argc,char*argv[])
{
? ? ?@autoreleasepool{
????? ??return UIApplicationMain(argc, argv, nil, NSStringFromClass([appDelegate class]));
????}
}
????????重點是UIApplicationMain()函數(shù)，這個方法會為main thread設(shè)置一個NSRunLoop對象，這就解釋了本文開始說的為什么我們的應(yīng)用可以在無人操作的時候休息，需要讓它干活的時候又能立馬響應(yīng)。
2.2.2 其他線程的Runloop
????????對其它線程來說，run loop默認(rèn)是沒有啟動的，如果你需要更多的線程交互則可以手動配置和啟動，如果線程只是去執(zhí)行一個長時間的已確定的任務(wù)則不需要。
2.2.3 當(dāng)前線程的Runloop獲取
????????在任何一個Cocoa程序的線程中，都可以通過：
NSRunLoop?? *runloop = [NSRunLoop currentRunLoop];
來獲取到當(dāng)前線程的run loop。
2.3 關(guān)于run loop的幾點說明
2.3.1 Cocoa中的NSRunLoop類并不是線程安全的
????????我們不能在一個線程中去操作另外一個線程的run loop對象，那很可能會造成意想不到的后果。不過幸運(yùn)的是CoreFundation中的不透明類CFRunLoopRef是線程安全的，而且兩種類型的run loop完全可以混合使用。Cocoa中的NSRunLoop類可以通過實例方法：
- (CFRunLoopRef)getCFRunLoop;
????????獲取對應(yīng)的CFRunLoopRef類，來達(dá)到線程安全的目的。
2.3.2 Runloop的管理并不完全是自動的。
????????我們?nèi)员仨氃O(shè)計線程代碼以在適當(dāng)?shù)臅r候啟動run loop并正確響應(yīng)輸入事件，當(dāng)然前提是線程中需要用到run loop。而且，我們還需要使用while/for語句來驅(qū)動run loop能夠循環(huán)運(yùn)行，下面的代碼就成功驅(qū)動了一個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同時也負(fù)責(zé)autorelease pool的創(chuàng)建和釋放。
????????在使用手動的內(nèi)存管理方式的項目中，會經(jīng)常用到很多自動釋放的對象，如果這些對象不能夠被即時釋放掉，會造成內(nèi)存占用量急劇增大。Run loop就為我們做了這樣的工作，每當(dāng)一個運(yùn)行循環(huán)啟動時，系統(tǒng)會自動創(chuàng)建一個autoreleasepool，用于掛載在此Runloop執(zhí)行期間生成的autorelease對象，而在Runloop結(jié)束的時候，它都會釋放此autorelease pool，同時pool中的所有autorelease類型變量都會被釋放掉。
2.4 Run loop的優(yōu)點
????????一個run loop就是一個事件處理循環(huán)，用來不停的監(jiān)聽和處理輸入事件并將其分配到對應(yīng)的目標(biāo)上進(jìn)行處理。如果僅僅是想實現(xiàn)這個功能，你可能會想一個簡單的while循環(huán)不就可以實現(xiàn)了嗎，用得著費(fèi)老大勁來做個那么復(fù)雜的機(jī)制？顯然，蘋果的架構(gòu)設(shè)計師不是吃干飯的，你想到的他們早就想過了。
????????首先，NSRunLoop是一種更加高明的消息處理模式，他就高明在對消息處理過程進(jìn)行了更好的抽象和封裝，這樣才能使你不用處理一些很瑣碎很低層次的具體消息的處理，在NSRunLoop中每一個消息就被打包在input source或者是timer source（見后文）中了。
????????其次，也是很重要的一點，使用run loop可以使你的線程在有工作的時候工作，沒有工作的時候休眠，這可以大大節(jié)省系統(tǒng)資源。
3 Runloop相關(guān)知識點
????????Run loop接收輸入事件來自兩種不同的來源：輸入源（input source）和定時源（timer source）。兩種源都使用程序的某一特定的處理例程來處理到達(dá)的事件。圖-1顯示了run loop的概念結(jié)構(gòu)以及各種源。
3.1 輸入事件來源
????????需要說明的是，當(dāng)你創(chuàng)建輸入源，你需要將其分配給run loop中的一個或多個模式（什么是模式，下文將會講到）。模式只會在特定事件影響監(jiān)聽的源。大多數(shù)情況下，run loop運(yùn)行在默認(rèn)模式下，但是你也可以使其運(yùn)行在自定義模式。若某一源在當(dāng)前模式下不被監(jiān)聽，那么任何其生成的消息只在run loop運(yùn)行在其關(guān)聯(lián)的模式下才會被傳遞。
3.1.1 輸入源（input source）
????????傳遞異步事件，通常消息來自于其他線程或程序。輸入源傳遞異步消息給相應(yīng)的處理例程，并調(diào)用runUntilDate:方法來退出(在線程里面相關(guān)的NSRunLoop對象調(diào)用)。
3.1.1.1 基于端口的輸入源
????????基于端口的輸入源由內(nèi)核自動發(fā)送。
????????Cocoa和Core Foundation內(nèi)置支持使用端口相關(guān)的對象和函數(shù)來創(chuàng)建的基于端口的源。例如，在Cocoa里面你從來不需要直接創(chuàng)建輸入源。你只要簡單的創(chuàng)建端口對象，并使用NSPort的方法把該端口添加到runloop。端口對象會自己處理創(chuàng)建和配置輸入源。
????????在Core Foundation，你必須人工創(chuàng)建端口和它的run loop源。我們可以使用端口相關(guān)的函數(shù)（CFMachPortRef，CFMessagePortRef，CFSocketRef）來創(chuàng)建合適的對象。下面的例子展示了如何創(chuàng)建一個基于端口的輸入源，將其添加到run loop并啟動：
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類型相關(guān)的函數(shù)來創(chuàng)建。你可以使用回調(diào)函數(shù)來配置自定義輸入源。Core Fundation會在配置源的不同地方調(diào)用回調(diào)函數(shù)，處理輸入事件，在源從run loop移除的時候清理它。
????????除了定義在事件到達(dá)時自定義輸入源的行為，你也必須定義消息傳遞機(jī)制。源的這部分運(yùn)行在單獨的線程里面，并負(fù)責(zé)在數(shù)據(jù)等待處理的時候傳遞數(shù)據(jù)給源并通知它處理數(shù)據(jù)。消息傳遞機(jī)制的定義取決于你，但最好不要過于復(fù)雜。創(chuà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請求會在目標(biāo)線程上序列化，減緩許多在線程上允許多個方法容易引起的同步問題。不像基于端口的源，一個selector執(zhí)行完后會自動從run loop里面移除。
????????當(dāng)在其他線程上面執(zhí)行selector時，目標(biāo)線程須有一個活動的run loop。對于你創(chuàng)建的線程，這意味著線程在你顯式的啟動run loop之前是不會執(zhí)行selector方法的，而是一直處于休眠狀態(tài)。
????????NSObject類提供了類似如下的selector方法：
- (void) performSelectorOnMainThread: (SEL)aSelector withObject: (id)argwaitUntilDone: (BOOL)wait modes: (NSArray*)array;
3.1.2 定時源（timer source）
????????定時源在預(yù)設(shè)的時間點同步方式傳遞消息，這些消息都會發(fā)生在特定時間或者重復(fù)的時間間隔。定時源則直接傳遞消息給處理例程，不會立即退出run loop。
????????需要注意的是，盡管定時器可以產(chǎn)生基于時間的通知，但它并不是實時機(jī)制。和輸入源一樣，定時器也和你的run loop的特定模式相關(guān)。如果定時器所在的模式當(dāng)前未被run loop監(jiān)視，那么定時器將不會開始直到run loop運(yùn)行在相應(yīng)的模式下。類似的，如果定時器在run loop處理某一事件期間開始，定時器會一直等待直到下次run loop開始相應(yīng)的處理程序。如果run loop不再運(yùn)行，那定時器也將永遠(yuǎn)不啟動。
????????創(chuàng)建定時器源有兩種方法，方法一：
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ā)生時觸發(fā)，而run loop觀察者則是在run loop本身運(yùn)行的特定時候觸發(fā)。你可以使用run loop觀察者來為處理某一特定事件或是進(jìn)入休眠的線程做準(zhǔn)備。你可以將run loop觀察者和以下事件關(guān)聯(lián)：
????1. Runloop入口
????2.? Runloop何時處理一個定時器
????3. Runloop何時處理一個輸入源
????4. Runloop何時進(jìn)入睡眠狀態(tài)
????5. Runloop何時被喚醒，但在喚醒之前要處理的事件
????6. Runloop終止
????????和定時器類似，在創(chuàng)建的時候你可以指定run loop觀察者可以只用一次或循環(huán)使用。若只用一次，那么在它啟動后，會把它自己從run loop里面移除，而循環(huán)的觀察者則不會。定義觀察者并把它添加到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)聽定時器觸發(fā)前處理事件，后面的YES表示循環(huán)監(jiān)聽。
3.3 RunLoop的事件隊列
????????每次運(yùn)行run loop，你線程的run loop對會自動處理之前未處理的消息，并通知相關(guān)的觀察者。具體的順序如下：
????1. 通知觀察者run loop已經(jīng)啟動
????2. 通知觀察者任何即將要開始的定時器
????3. 通知觀察者任何即將啟動的非基于端口的源
????4. 啟動任何準(zhǔn)備好的非基于端口的源
????5. 如果基于端口的源準(zhǔn)備好并處于等待狀態(tài)，立即啟動；并進(jìn)入步驟9。
????6. 通知觀察者線程進(jìn)入休眠
????7. 將線程置于休眠直到任一下面的事件發(fā)生：
????????· 某一事件到達(dá)基于端口的源
????????· 定時器啟動
????????· Run loop設(shè)置的時間已經(jīng)超時
????????· run loop被顯式喚醒
????8. 通知觀察者線程將被喚醒。
? ? 9. 處理未處理的事件
????????· 如果用戶定義的定時器啟動，處理定時器事件并重啟run loop。進(jìn)入步驟2
????????· 如果輸入源啟動，傳遞相應(yīng)的消息
????????· 如果run loop被顯式喚醒而且時間還沒超時，重啟run loop。進(jìn)入步驟2
????10. 通知觀察者run loop結(jié)束。
????????因為定時器和輸入源的觀察者是在相應(yīng)的事件發(fā)生之前傳遞消息，所以通知的時間和實際事件發(fā)生的時間之間可能存在誤差。如果需要精確時間控制，你可以使用休眠和喚醒通知來幫助你校對實際發(fā)生事件的時間。
????????因為當(dāng)你運(yùn)行run loop時定時器和其它周期性事件經(jīng)常需要被傳遞，撤銷run loop也會終止消息傳遞。典型的例子就是鼠標(biāo)路徑追蹤。因為你的代碼直接獲取到消息而不是經(jīng)由程序傳遞，因此活躍的定時器不會開始直到鼠標(biāo)追蹤結(jié)束并將控制權(quán)交給程序。
????????Run loop可以由run loop對象顯式喚醒。其它消息也可以喚醒run loop。例如，添加新的非基于端口的源會喚醒run loop從而可以立即處理輸入源而不需要等待其他事件發(fā)生后再處理。
????????從這個事件隊列中可以看出：
????①如果是事件到達(dá)，消息會被傳遞給相應(yīng)的處理程序來處理， runloop處理完當(dāng)次事件后，run loop會退出，而不管之前預(yù)定的時間到了沒有。你可以重新啟動run loop來等待下一事件。
????②如果線程中有需要處理的源，但是響應(yīng)的事件沒有到來的時候，線程就會休眠等待相應(yīng)事件的發(fā)生。這就是為什么run loop可以做到讓線程有工作的時候忙于工作，而沒工作的時候處于休眠狀態(tài)。
3.4 什么時候使用run loop
????????僅當(dāng)在為你的程序創(chuàng)建輔助線程的時候，你才需要顯式運(yùn)行一個run loop。Run loop是程序主線程基礎(chǔ)設(shè)施的關(guān)鍵部分。所以，Cocoa和Carbon程序提供了代碼運(yùn)行主程序的循環(huán)并自動啟動run loop。IOS程序中UIApplication的run方法（或Mac OS X中的NSApplication）作為程序啟動步驟的一部分，它在程序正常啟動的時候就會啟動程序的主循環(huán)。類似的，RunApplicationEventLoop函數(shù)為Carbon程序啟動主循環(huán)。如果你使用xcode提供的模板創(chuàng)建你的程序，那你永遠(yuǎn)不需要自己去顯式的調(diào)用這些例程。
????????對于輔助線程，你需要判斷一個run loop是否是必須的。如果是必須的，那么你要自己配置并啟動它。你不需要在任何情況下都去啟動一個線程的run loop。比如，你使用線程來處理一個預(yù)先定義的長時間運(yùn)行的任務(wù)時，你應(yīng)該避免啟動run loop。Run loop在你要和線程有更多的交互時才需要，比如以下情況：
????1. 使用端口或自定義輸入源來和其他線程通信
????2. 使用線程的定時器
????3. Cocoa中使用任何performSelector…的方法
????4. 使線程周期性工作
????????如果你決定在程序中使用run loop，那么它的配置和啟動都很簡單。和所有線程編程一樣，你需要計劃好在輔助線程退出線程的情形。讓線程自然退出往往比強(qiáng)制關(guān)閉它更好。
4 基于Runloop實現(xiàn)的上層功能
4.1 AutoreleasePool
????????App啟動后，蘋果在主線程 RunLoop 里注冊了兩個 Observer，其回調(diào)都是_wrapRunLoopWithAutoreleasePoolHandler()。
????????第一個 Observer 監(jiān)視的事件是Entry(即將進(jìn)入Loop)，其回調(diào)內(nèi)會調(diào)用 _objc_autoreleasePoolPush() 創(chuàng)建自動釋放池。其 order 是-2147483647，優(yōu)先級最高，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前。
????????第二個 Observer 監(jiān)視了兩個事件： BeforeWaiting(準(zhǔn)備進(jìn)入休眠) 時調(diào)用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池并創(chuàng)建新池；Exit(即將退出Loop)時調(diào)用 _objc_autoreleasePoolPop() 來釋放自動釋放池。這個 Observer 的 order 是 2147483647，優(yōu)先級最低，保證其釋放只發(fā)生在其他所有回調(diào)之后。
????????在主線程執(zhí)行的代碼，通常是寫在諸如事件回調(diào)、Timer回調(diào)內(nèi)的。這些回調(diào)會被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著，所以不會出現(xiàn)內(nèi)存泄漏，開發(fā)者也不必顯示創(chuàng)建 Pool 了。
4.2 事件響應(yīng)（Good）
????????蘋果注冊了一個 Source1 (基于 mach port 的) 用來接收系統(tǒng)事件，其回調(diào)函數(shù)為__IOHIDEventSystemClientQueueCallback()。
????????當(dāng)一個硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后，首先由 IOKit.framework 生成一個 IOHIDEvent 事件并由SpringBoard 接收。這個過程的詳細(xì)情況可以參考這里。SpringBoard只接收按鍵(鎖屏/靜音等)，觸摸，加速，接近傳感器等幾種 Event，隨后用mach port 轉(zhuǎn)發(fā)給需要的App進(jìn)程。隨后蘋果注冊的那個 Source1 就會觸發(fā)回調(diào)，并調(diào)用 _UIApplicationHandleEventQueue() 進(jìn)行應(yīng)用內(nèi)部的分發(fā)。
????????_UIApplicationHandleEventQueue()會把 IOHIDEvent 處理并包裝成 UIEvent 進(jìn)行處理或分發(fā)，其中包括識別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等。通常事件比如UIButton點擊、touchesBegin/Move/End/Cancel 事件都是在這個回調(diào)中完成的。
4.3 手勢識別
????????當(dāng)上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會調(diào)用 Cancel 將當(dāng)前的 touchesBegin/Move/End 系列回調(diào)打斷。隨后系統(tǒng)將對應(yīng)的 UIGestureRecognizer 標(biāo)記為待處理。蘋果注冊了一個 Observer 監(jiān)測 BeforeWaiting (Loop即將進(jìn)入休眠) 事件，這個Observer的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()，其內(nèi)部會獲取所有剛被標(biāo)記為待處理的 GestureRecognizer，并執(zhí)行GestureRecognizer的回調(diào)。
????????當(dāng)有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時，這個回調(diào)都會進(jìn)行相應(yīng)處理。
4.4 界面更新
????????當(dāng)在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動調(diào)用了UIView/CALayer的setNeedsLayout/setNeedsDisplay方法后，這個UIView/CALayer就被標(biāo)記為待處理，并被提交到一個全局的容器去。
????????蘋果注冊了一個Observer監(jiān)聽BeforeWaiting(即將進(jìn)入休眠)和Exit (即將退出Loop)事件，回調(diào)去執(zhí)行一個很長的函數(shù)：
????_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數(shù)里會遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實際的繪制和調(diào)整，并更新 UI 界面。
????????這個函數(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 定時器
????????NSTimer其實就是CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 注冊到 RunLoop 后，RunLoop 會為其重復(fù)的時間點注冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節(jié)省資源，并不會在非常準(zhǔn)確的時間點回調(diào)這個Timer。Timer有個屬性叫做 Tolerance (寬容度)，標(biāo)示了當(dāng)時間點到后，容許有多少最大誤差。
????????如果某個時間點被錯過了，例如執(zhí)行了一個很長的任務(wù)，則那個時間點的回調(diào)也會跳過去，不會延后執(zhí)行。就比如等公交，如果 10:10 時我忙著玩手機(jī)錯過了那個點的公交，那我只能等 10:20 這一趟了。
????????CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復(fù)雜，和 NSTimer 并不一樣，其內(nèi)部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執(zhí)行了一個長任務(wù)，那其中就會有一幀被跳過去（和 NSTimer 相似），造成界面卡頓的感覺。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題，其內(nèi)部也用到了 RunLoop，這個稍后我會再單獨寫一頁博客來分析。
4.6 PerformSelecter
????????當(dāng)調(diào)用 NSObject 的 performSelecter:afterDelay: 后，實際上其內(nèi)部會創(chuàng)建一個 Timer 并添加到當(dāng)前線程的 RunLoop 中。所以如果當(dāng)前線程沒有 RunLoop，則這個方法會失效。
????????當(dāng)調(diào)用 performSelector:onThread: 時，實際上其會創(chuàng)建一個 Timer 加到對應(yīng)的線程去，同樣的，如果對應(yīng)線程沒有 RunLoop 該方法也會失效。
4.7 關(guān)于GCD
????????實際上 RunLoop 底層也會用到GCD的東西，比如RunLoop是用 dispatch_source_t 實現(xiàn)的Timer。但同時GCD提供的某些接口也用到了 RunLoop，例如 dispatch_async()。
????????當(dāng)調(diào)用dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主線程的RunLoop發(fā)送消息，RunLoop會被喚醒，并從消息中取得這個 block，并在回調(diào)__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__()里執(zhí)行這個block。但這個邏輯僅限于dispatch到主線程，dispatch到其他線程仍然是由 libDispatch 處理的。
4.8 關(guān)于網(wǎng)絡(luò)請求
????????iOS 中，關(guān)于網(wǎng)絡(luò)請求的接口自下至上有如下幾層:
????CFSocket
????CFNetwork???????->ASIHttpRequest
????NSURLConnection?->AFNetworking
????NSURLSession????->AFNetworking2,?Alamofire
? CFSocket 是最底層的接口，只負(fù)責(zé) socket 通信。
? CFNetwork 是基于 CFSocket 等接口的上層封裝，ASIHttpRequest 工作于這一層。
? NSURLConnection 是基于 CFNetwork 的更高層的封裝，提供面向?qū)ο蟮慕涌冢珹FNetworking 工作于這一層。
? NSURLSession 是 iOS7 中新增的接口，表面上是和 NSURLConnection 并列的，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)，AFNetworking2 和 Alamofire 工作于這一層。
????????下面主要介紹下 NSURLConnection 的工作過程。
????????通常使用 NSURLConnection 時，你會傳入一個Delegate，當(dāng)調(diào)用了 [connection start]后，這個Delegate 就會不停收到事件回調(diào)。實際上，start 這個函數(shù)的內(nèi)部會獲取CurrentRunLoop，然后在其中的DefaultMode添加了4個 Source0 (即需要手動觸發(fā)的Source)。CFMultiplexerSource 是負(fù)責(zé)各種 Delegate 回調(diào)的，CFHTTPCookieStorage 是處理各種Cookie的。
????????當(dāng)開始網(wǎng)絡(luò)傳輸時，我們可以看到 NSURLConnection 創(chuàng)建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的。NSURLConnectionLoader這個線程內(nèi)部會使用 RunLoop 來接收底層socket的事件，并通過之前添加的 Source0 通知到上層的Delegate。
????????NSURLConnectionLoader中的RunLoop通過一些基于mach port 的 Source 接收來自底層 CFSocket 的通知。當(dāng)收到通知后，其會在合適的時機(jī)向 CFMultiplexerSource 等 Source0 發(fā)送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執(zhí)行實際的回調(diào)。
4.9 RunLoop的實際應(yīng)用舉例
4.9.1 AFNetworking
????????AFURLConnectionOperation 這個類是基于 NSURLConnection 構(gòu)建的，其希望能在后臺線程接收 Delegate 回調(diào)。為此 AFNetworking 單獨創(chuàng)建了一個線程，并在這個線程中啟動了一個 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 啟動前內(nèi)部必須要有至少一個 Timer/Observer/Source，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個新的 NSMachPort 添加進(jìn)去了。通常情況下，調(diào)用者需要持有這個 NSMachPort (mach_port) 并在外部線程通過這個port發(fā)送消息到loop內(nèi)；但此處添加port只是為了讓RunLoop不至于退出，并沒有用于實際的發(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)需要這個后臺線程執(zhí)行任務(wù)時，AFNetworking 通過調(diào)用 [NSObject performSelector: onThread: ..] 將這個任務(wù)扔到了后臺線程的RunLoop中。
4.9.2 AsyncDisplayKit
????????AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架，其原理大致如下：
????????UI 線程中一旦出現(xiàn)繁重的任務(wù)就會導(dǎo)致界面卡頓，這類任務(wù)通常分為3類：排版，繪制，UI對象操作。排版通常包括計算視圖大小、計算文本高度、重新計算子式圖的排版等操作。繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預(yù)先解壓)、元素繪制 (Quartz)等操作。UI對象操作通常包括 UIView/CALayer 等 UI 對象的創(chuàng)建、設(shè)置屬性和銷毀。
????????其中前兩類操作可以通過各種方法扔到后臺線程執(zhí)行，而最后一類操作只能在主線程完成，并且有時后面的操作需要依賴前面操作的結(jié)果 （例如TextView創(chuàng)建時可能需要提前計算出文本的大小）。ASDK 所做的，就是盡量將能放入后臺的任務(wù)放入后臺，不能的則盡量推遲 (例如視圖的創(chuàng)建、屬性的調(diào)整)。
????????為此，ASDK 創(chuàng)建了一個名為 ASDisplayNode 的對象，并在內(nèi)部封裝了 UIView/CALayer，它具有和 UIView/CALayer 相似的屬性，例如 frame、backgroundColor等。所有這些屬性都可以在后臺線程更改，開發(fā)者可以只通過 Node 來操作其內(nèi)部的 UIView/CALayer，這樣就可以將排版和繪制放入了后臺線程。但是無論怎么操作，這些屬性總需要在某個時刻同步到主線程的 UIView/CALayer 去。
????????ASDK 仿照QuartzCore/UIKit 框架的模式，實現(xiàn)了一套類似的界面更新的機(jī)制：即在主線程的 RunLoop 中添加一個Observer，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件，在收到回調(diào)時，遍歷所有之前放入隊列的待處理的任務(wù)，然后一一執(zhí)行。
????????具體的代碼可以看這里：_ASAsyncTransactionGroup。
5 Runloop實踐思考
5.1 Runloop在動畫重復(fù)提交調(diào)用中的限制
????????對于控件簡單屬性的賦值等操作，在同一個Runloop中重復(fù)設(shè)置，最終起作用的會是最后一次，但是如果對控件的變化通過動畫來實現(xiàn)，則每一次設(shè)置動作都會向系統(tǒng)提交一次動畫執(zhí)行命令，而不只是最后一次動畫。典型運(yùn)用場景例如導(dǎo)航條的顯示與隱藏：
?????? 不是簡單通過子類中復(fù)寫viewdidload方法，重新設(shè)置導(dǎo)航條的顯示屬性就可以的，涉及動畫的，最好只設(shè)置一次，例如只在子類中設(shè)置，而父類就不要設(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
