Runloop是iOS和OSX開發中非常基礎的一個概念，從概念開始學習。
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實際就是一個對象，這個對象管理了其需要處理的事件和消息，并提供了一個入口函數來執行上面的Eventloop的邏輯。線程執行了該函數后，就會一直處于這個函數內部“接受消息”->等待->處理的循環中，知道循環結束，函數退出。
OSX/iOS系統中提供了兩個這樣的對象：NSRunLoop和CFRunLoopRef。
CFRunLoopRef 是在CoreFoundation框架內，它提供了純C的API，所有這些API都是線程安全的。NSRunLoop是基于CFRunLoopRef的封裝，提供了面向對象的API，但是這些API不是線程安全的。
CFRunLoopRef是開源的，地址：http://opensource.apple.com/tarballs/CF/
Swift開源后，apple又維護了一個跨平臺的CoreFounation，https://github.com/apple/swift-corelibs-foundation/，這個版本的源碼可能和現有的iOS系統中實現略不一樣，但更容易編譯。
RunLoop與線程的關系
iOS開發中能遇到兩個線程對象：pthread_t和NSThread。它們是一一對應的。比如，你可以通過pthread_main_thread_np()或者[NSThread mainThread]來獲取主線程；也可以通過pthread_self（）或者[NSThread currentThread]獲取當前線程。CFRunLoop是基于pthread來管理的。
蘋果不允許直接創建Runloop，它只提供了兩個自動獲取的函數：CFRunLoopGetMain()和CFRunLoopGetCurrent().這兩個函數的內部邏輯大概是下面這樣：
//全局的Dictionary，key是pthread_t，value 是CFRunLoopRef
static CFMutableDictionaryRef ? ?loopsDic;
static CFpinlock_t ? ?loopslock；//訪問loopsDic時的鎖，防止被改變
／／獲取一個pthread對應的RunLoop。
CFRunloopRef ?_CFRunLoopGet(pthread_t thread){
OSSpinlocklock(&loopsLock)
if(!loopsDic){
//第一次進入時，初始化全局Dic，并為主線程創建一個RunLoop。
loopsDic = CFDictionaryCreateMutable();
CFRunLoopRef mainloop = _CFRunLoopCreat();
CFDictionarySetValue(loopsDic,pthread_main_thread_np(),mainloop);
}
///直接從Dictionary中獲取。
CFRunLoopRef loop = CFDictionaryGetValue(loopsDic,thread));
if(!loop){
///取不到、創建一個
loop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic,thread,loop);
///注冊一個回調，當線程銷毀時，順便也銷毀對應的Runloop。是這樣嗎？同一個Runloop里面不是可以對象很多thread嗎？？？？？
_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的銷毀時發生在線程結束時。你只能在一個thread中獲取其Runloop（主線程除外）
RunLoop對外的接口
在CoreFoundation中關于RunLoop有5個類：CFRunLoopRef、CFRunLoopModeRef、CFRunLoopSourceRef、CFRunloopTimerRef、CFRunLoopObserverRef
CFRunLoopModeRef并沒有對外暴露，一個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的狀態發生變化時，觀察者就能通過回調接受到這個變化。
typedefCF_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會直接退出，不進入循環。
RunLoop的Mode
CFRunLoopMode和CFRunLoop的結構大致如下：
struct ?__CFRunLoopMode{
CFStringRef_name;// Mode Name, 例如 @"kCFRunLoopDefaultMode"
CFMutableSetRef_sources0;// Set
CFMutableSetRef_sources1;// Set
CFMutableArrayRef_observers;// Array
CFMutableArrayRef_timers;// Array
...
};
struct __CFRunLoop{
CFMutableSetRef _commonModes;// Set
CFMutableSetRef _commonModeItems;// Set
CFRunLoopModeRef _currentMode;// Current Runloop Mode
CFMutableSetRef _modes;// Set
...
};
這里有個概念叫“CommonModes”一個Mode可以將自己標記為“Common”屬性（通過將其ModeName 添加到RunLoop的“commonModes”中）。每當RunLoop的內容發生變化時，RunLoop都會自動的_commonModeltems里的Source／Observer／Timer同步到具有“Common”標記的所有Mode里。
應用場景舉例：主線程的RunLoop里有兩個預置的Mode：kCFRunLoopDefaultMode和UITrackingRunLoopMode。這兩個mode都已經標記為“Common”屬性。DefaultMode是App平時所處的狀態，TrackingRunLoopMode是追蹤Scrollview滑動時的狀態。當你創建一個Timer并加入DefaultMode時，Timer會得到重復調用，但此時滑動一個TablView時，RunLoop會將Mode切換為TrackingRunLoopMode，這時Timer就不會被調用，并且也不會影響到滑動操作。
有時候，你需要一個Timer，在兩個Mode中都能得到回調，一種辦法就是將這個Timer分別計入這兩個Mode。還有一種方法，就是將Timer加入懂啊頂層的Runloop的“commonModeitems”中。commonModeItems被RunLoop自動更新到所有具有Common屬性的Mode中。
CFRunLoopAddCommonMode(CFRunLoopRef rl, CFRunLoopMode mode)
CFRunLoopRunInMode(CFRunLoopMode mode, CFTimeInterval seconds, Boolean returnAfterSourceHandled)
我們通過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
RunLoop的內部邏輯
/// 用DefaultMode啟動
voidCFRunLoopRun(void){
CFRunLoopRunSpecific(CFRunLoopGetCurrent(),kCFRunLoopDefaultMode,1.0e10,false);
}
/// 用指定的Mode啟動，允許設置RunLoop超時時間
intCFRunLoopRunInMode(CFStringRefmodeName,CFTimeIntervalseconds,BooleanstopAfterHandle){
returnCFRunLoopRunSpecific(CFRunLoopGetCurrent(),modeName,seconds,returnAfterSourceHandled);
}
/// RunLoop的實現
intCFRunLoopRunSpecific(runloop,modeName,seconds,stopAfterHandle){
/// 首先根據modeName找到對應mode
CFRunLoopModeRefcurrentMode=__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){
BooleansourceHandledThisLoop=NO;
intretVal=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){
BooleanhasMsg=__CFRunLoopServiceMachPort(dispatchPort,&msg)
if(hasMsg)gotohandle_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。
elseif(msg_is_dispatch){
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
}
/// 9.3 如果一個 Source1 (基于port) 發出事件了，處理這個事件
else{
CFRunLoopSourceRefsource1=__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;
}elseif(timeout){
/// 超出傳入參數標記的超時時間了
retVal=kCFRunLoopRunTimedOut;
}elseif(__CFRunLoopIsStopped(runloop)){
/// 被外部調用者強制停止了
retVal=kCFRunLoopRunStopped;
}elseif(__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() 時，線程就會一直停留在這個循環里；直到超時或被手動停止，該函數才會返回。
蘋果官方將整個系統大致劃分為上述4個層次：
應用層包括用戶能接觸到的圖形應用，例如 Spotlight、Aqua、SpringBoard 等。
應用框架層即開發人員接觸到的 Cocoa 等框架。
核心框架層包括各種核心框架、OpenGL 等內容。
Darwin 即操作系統的核心，包括系統內核、驅動、Shell 等內容，這一層是開源的，其所有源碼都可以在opensource.apple.com里找到。
其中，在硬件層上面的三個組成部分：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_theader;
mach_msg_body_tbody;
}mach_msg_base_t;
typedef ? struct{
mach_msg_bits_tmsgh_bits;
mach_msg_size_tmsgh_size;
mach_port_tmsgh_remote_port;
mach_port_tmsgh_local_port;
mach_port_name_tmsgh_voucher_port;
mach_msg_id_tmsgh_id;
}mach_msg_header_t;
一條 Mach 消息實際上就是一個二進制數據包 (BLOB)，其頭部定義了當前端口 local_port 和目標端口 remote_port，
發送和接受消息是通過同一個 API 進行的，其 option 標記了消息傳遞的方向：
mach_msg_return_t ?mach_msg(
mach_msg_header_t *msg,
mach_msg_option_toption,
mach_msg_size_tsend_size,
mach_msg_size_trcv_size,
mach_port_name_trcv_name,
mach_msg_timeout_ttimeout,
mach_port_name_tnotify);
為了實現消息的發送和接收，mach_msg() 函數實際上是調用了一個 Mach 陷阱 (trap)，即函數mach_msg_trap()，陷阱這個概念在 Mach 中等同于系統調用。當你在用戶態調用 mach_msg_trap() 時會觸發陷阱機制，切換到內核態；內核態中內核實現的 mach_msg() 函數會完成實際的工作，如下圖：
RunLoop 的核心就是一個 mach_msg() (見上面代碼的第7步)，RunLoop 調用這個函數去接收消息，如果沒有別人發送 port 消息過來，內核會將線程置于等待狀態。例如你在模擬器里跑起一個 iOS 的 App，然后在 App 靜止時點擊暫停，你會看到主線程調用棧是停留在 mach_msg_trap() 這個地方
蘋果用RunLoop實現的功能
首先我們看下App啟動后RunLoop的狀態：
CFRunLoop{
currentmode=kCFRunLoopDefaultMode
commonmodes={
UITrackingRunLoopMode
kCFRunLoopDefaultMode
}
commonmodeitems={
// 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,
nextfiredate=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、UITackingRunLoopMode：界面跟蹤Mode，用于Scrollview追蹤觸摸滑動，保證界面滑動時不受其他mode影響。
3、UIinitializationRunLoopMode：在剛啟動App時第一Mode，啟動后就不再使用。
4、GSEventReceiveRunLoopMode：接受系統事件的內部Mode，通常用不到。
5、kCFRunLoopCommonModes：這是一個占位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);
}
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 了。
事件響應
蘋果注冊了一個 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 事件都是在這個回調中完成的。
手勢識別
當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會調用 Cancel 將當前的 touchesBegin/Move/End 系列回調打斷。隨后系統將對應的 UIGestureRecognizer 標記為待處理。
蘋果注冊了一個 Observer 監測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回調函數是 _UIGestureRecognizerUpdateObserver()，其內部會獲取所有剛被標記為待處理的 GestureRecognizer，并執行GestureRecognizer的回調。當有 UIGestureRecognizer 的變化(創建/銷毀/狀態改變)時，這個回調都會進行相應處理。
界面更新
當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動調用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，這個 UIView/CALayer 就被標記為待處理，并被提交到一個全局的容器去
蘋果注冊了一個 Observer 監聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調去執行一個很長的函數：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數里會遍歷所有待處理的 UIView/CAlayer 以執行實際的繪制和調整，并更新 UI 界面
定時器
NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 注冊到 RunLoop 后，RunLoop 會為其重復的時間點注冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節省資源，并不會在非常準確的時間點回調這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到后，容許有多少最大誤差。
CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現原理更復雜，和 NSTimer 并不一樣，其內部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執行了一個長任務，那其中就會有一幀被跳過去（和 NSTimer 相似），造成界面卡頓的感覺。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題，其內部也用到了 RunLoop
PerformSelecter
當調用 NSObject 的 performSelecter:afterDelay: 后，實際上其內部會創建一個 Timer 并添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop，則這個方法會失效。
當調用 performSelector:onThread: 時，實際上其會創建一個 Timer 加到對應的線程去，同樣的，如果對應線程沒有 RunLoop 該方法也會失效
關于GCD
實際上 RunLoop 底層也會用到 GCD 的東西，NSTimer 是用了 XNU 內核的 mk_timer， NSTimer 確實是由 mk_timer 驅動，而非 GCD 驅動的）。但同時 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 處理的。
網絡請求
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 執行實際的回調。
RunLoop 的應用
AFNetworking
AFURLConnectionOperation 這個類時基于NSURLConnection 構建的，其希望能在后臺線程接收Delegate回調。為此AFnetWorking單獨創建一個線程，并在線程中啟動了一個Runloop：
+(void) networkRequestThreadEntryPint:(id) __unused object {
@autoreleasepool {
[NSThread currentThread] set Name:@" 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(networkRequestThreadEntryPint:) object:nil];
[_networkRequestThread ?start]; });
return _networkRequestThread;
}
RunLoop 啟動前內部必現至少有一個timer／observer／Source，所以AFNetworking 在[runloop run] 之前先創建一個NSMachPort添加進去，產生一個source1.通常情況下，調用者需要持有這個NSMachPort(mach_port)并在外部線程通過這個port發送信息到loop內；但是此處添加port就是為了讓loop不退出，并沒有實際發送消息。
-(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 = AFOperatinExecutingState;
[self performSelector:@selector(operationDidStart) onThread:[[ self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self. runloopModes allObjects]];
}
[self.lock unlock];
}
當需要這個后臺線程執行任務時，AFNetworking 通過調用 [NSObject performSelector:onThread:..] 將這個任務扔到了后臺線程的 RunLoop 中
總結
這是一篇學習筆記，大部分參考了大神的作品，反復看了幾遍，也查看了開源的代碼，發現蘋果最新的維護CoreFoundation中的用法和大神說的有出入，不過大部分原理都是一致的。個人學習體會如下：
1、Runloop是在線程的基礎上存在的，pthread_t.也就是說thread可以沒有runloop，但是后者不行。問題來了，一個thread開一個runloop 對app性能有影響嗎？為什么？這個問題是有待進一步研究。
總結，學習必須動手驗證。。。。
本文參考：https://blog.ibireme.com/2015/05/18/runloop/
