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