1 Runloop機制原理
深入理解RunLoop
http://www.cocoachina.com/ios/20150601/11970.html
1.1 RunLoop的概念
????????一般來講歹颓，一個線程一次只能執(zhí)行一個任務，執(zhí)行完成后線程就會退出陨倡。如果我們需要一個機制，讓線程能隨時處理事件但并不退出仍侥，通常的代碼邏輯是這樣的：
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)這種模型的關鍵點在于：如何管理事件/消息贡茅，如何讓線程在沒有處理消息時休眠以避免資源占用秘蛇、在有消息到來時立刻被喚醒。
????????所以顶考，RunLoop 實際上就是一個對象赁还，這個對象管理了其需要處理的事件和消息，并提供了一個入口函數(shù)來執(zhí)行上面 Event Loop 的邏輯驹沿。線程執(zhí)行了這個函數(shù)后秽浇，就會一直處于這個函數(shù)內(nèi)部 "接受消息->等待->處理" 的循環(huán)中，直到這個循環(huán)結束（比如傳入 quit 的消息）甚负，函數(shù)返回柬焕。
????????OSX/iOS 系統(tǒng)中，提供了兩個這樣的對象：NSRunLoop 和 CFRunLoopRef梭域。
????????CFRunLoopRef 是在 CoreFoundation 框架內(nèi)的斑举，它提供了純 C 函數(shù)的 API，所有這些 API 都是線程安全的病涨。
????????NSRunLoop 是基于 CFRunLoopRef 的封裝富玷，提供了面向對象的 API，但是這些 API 不是線程安全的既穆。
????????CFRunLoopRef 的代碼是開源的赎懦，你可以在這里 http://opensource.apple.com/tarballs/CF/CF-855.17.tar.gz 下載到整個 CoreFoundation 的源碼。為了方便跟蹤和查看幻工，你可以新建一個 Xcode 工程励两，把這堆源碼拖進去看。
1.2 RunLoop與線程的關系
????????首先囊颅，iOS 開發(fā)中能遇到兩個線程對象: pthread_t 和 NSThread当悔。過去蘋果有份文檔標明了 NSThread 只是 pthread_t 的封裝傅瞻，但那份文檔已經(jīng)失效了，現(xiàn)在它們也有可能都是直接包裝自最底層的 mach thread盲憎。蘋果并沒有提供這兩個對象相互轉換的接口嗅骄，但不管怎么樣，可以肯定的是 pthread_t 和NSThread 是一一對應的饼疙。比如溺森，你可以通過 pthread_main_np() 或 [NSThread mainThread] 來獲取主線程；也可以通過 pthread_self() 或 [NSThread currentThread] 來獲取當前線程窑眯。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?對應的?RunLoop更胖。
CFRunLoopRef?_CFRunLoopGet(pthread_t?thread)?{
????OSSpinLockLock(&loopsLock);
????if?(!loopsDic)?{
????????//?第一次進入時铛铁，初始化全局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);
? ? ?????///?注冊一個回調彪标，當線程銷毀時倍权，順便也銷毀其對應的?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 里。線程剛創(chuàng)建時并沒有 RunLoop题画，如果你不主動獲取默辨，那它一直都不會有。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時苍息，RunLoop 的銷毀是發(fā)生在線程結束時缩幸。你只能在一個線程的內(nèi)部獲取其 RunLoop（主線程除外）。
1.3 RunLoop對外的接口
????????在 CoreFoundation 里面關于 RunLoop 有5個類:
????? CFRunLoopRef
????? CFRunLoopModeRef
????? CFRunLoopSourceRef
????? CFRunLoopTimerRef
????? CFRunLoopObserverRef
????????其中 CFRunLoopModeRef 類并沒有對外暴露竞思，只是通過 CFRunLoopRef 的接口進行了封裝表谊。他們的關系如下:
????????一個 RunLoop 包含若干個 Mode，每個 Mode 又包含若干個 Source/ Timer/Observer盖喷。每次調用RunLoop的主函數(shù)時爆办，只能指定其中一個Mode，這個Mode被稱作CurrentMode传蹈。如果需要切換Mode押逼，只能退出Loop，再重新指定一個Mode進入惦界。這樣做主要是為了分隔開不同組的Source/Timer/Observer挑格，讓其互不影響。
? ??????CFRunLoopSourceRef 是事件產(chǎn)生的地方沾歪。Source有兩個版本：Source0 和 Source1漂彤。
????? Source0 只包含了一個回調（函數(shù)指針），它并不能主動觸發(fā)事件灾搏。使用時挫望，你需要先調用CFRunLoopSourceSignal(source)，將這個 Source 標記為待處理狂窑，然后手動調用CFRunLoopWakeUp(runloop) 來喚醒RunLoop媳板，讓其處理這個事件。
????? Source1 包含了一個mach_port和一個回調（函數(shù)指針）泉哈，被用于通過內(nèi)核和其他線程相互發(fā)送消息蛉幸。這種Source能主動喚醒RunLoop的線程，其原理在下面會講到丛晦。
? ??????CFRunLoopTimerRef 是基于時間的觸發(fā)器奕纫，它和NSTimer是toll-free bridged的，可以混用烫沙。其包含一個時間長度和一個回調（函數(shù)指針）匹层。當其加入到RunLoop時，RunLoop會注冊對應的時間點锌蓄，當時間點到時升筏，RunLoop會被喚醒以執(zhí)行那個回調。
? ??????CFRunLoopObserverRef 是觀察者瘸爽，每個 Observer 都包含了一個回調（函數(shù)指針）仰冠，當RunLoop的狀態(tài)發(fā)生變化時，觀察者就能通過回調接受到這個變化蝶糯⊙笾唬可以觀測的時間點有以下幾個：
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 被統(tǒng)稱為mode item，一個item可以被同時加入多個mode昼捍。但一個item被重復加入同一個mode時是不會有效果的烟勋。如果一個mode中一個item都沒有荚斯，則RunLoop會直接退出，不進入循環(huán)。
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的內(nèi)容發(fā)生變化時，RunLoop都會自動將 _commonModeItems里的Source/Observer/Timer同步到具有"Common"標記的所有Mode里绪妹。
????????應用場景舉例：主線程的RunLoop里有兩個預置的 Mode：kCFRunLoopDefaultMode和UITrackingRunLoopMode。這兩個Mode都已經(jīng)被標記為"Common"屬性铭腕。DefaultMode是App平時所處的狀態(tài)，TrackingRunLoopMode是追蹤ScrollView滑動時的狀態(tài)多糠。當你創(chuàng)建一個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來操作內(nèi)部的mode盾沫，當你傳入一個新的mode name但RunLoop內(nèi)部沒有對應mode時，RunLoop會自動幫你創(chuàng)建對應的 CFRunLoopModeRef殿漠。對于一個RunLoop來說赴精，其內(nèi)部的mode只能增加不能刪除。
????????蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode绞幌，你可以用這兩個 Mode Name 來操作其對應的 Mode蕾哟。
????????同時蘋果還提供了一個操作 Common 標記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，你可以用這個字符串來操作 Common Items莲蜘，或標記一個 Mode 為 "Common"谭确。使用時注意區(qū)分這個字符串和其他 mode name。
1.5 RunLoop的內(nèi)部邏輯(再細讀一遍)
????根據(jù)蘋果在文檔里的說明票渠，RunLoop 內(nèi)部的邏輯大致如下:
????????其內(nèi)部代碼整理如下 （太長了不想看可以直接跳過去逐哈，后面會有說明）：
///?用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的實現(xiàn)
int?CFRunLoopRunSpecific(runloop,?modeName,?seconds,?stopAfterHandle)?{
????///?首先根據(jù)modeName找到對應mode
????CFRunLoopModeRef?currentMode?=?__CFRunLoopFindMode(runloop,?modeName,?false);
????///?如果mode里沒有source/timer/observer,?直接返回问顷。
????if?(__CFRunLoopModeIsEmpty(currentMode))?return;
????///?1.?通知?Observers:?RunLoop?即將進入?loop昂秃。
__CFRunLoopDoObservers(runloop,?currentMode,?kCFRunLoopEntry);
????///?內(nèi)部函數(shù)，進入loop
__CFRunLoopRun(runloop,?currentMode,?seconds,?returnAfterSourceHandled)?{
Boolean?sourceHandledThisLoop?=?NO;
int?retVal?=?0;
????????do{
????????????///2.通知Observers:RunLoop即將觸發(fā)Timer回調杜窄。
? ? ? ? ? ? __CFRunLoopDoObservers(runloop,?currentMode,?kCFRunLoopBeforeTimers);
????????????///3.通知Observers:RunLoop即將觸發(fā)Source0(非port)回調肠骆。
????????????__CFRunLoopDoObservers(runloop,?currentMode,?kCFRunLoopBeforeSources);
????????????///執(zhí)行被加入的block
????????????__CFRunLoopDoBlocks(runloop,?currentMode);
????????????///4.RunLoop觸發(fā)Source0(非port)回調。
????????????sourceHandledThisLoop?=?__CFRunLoopDoSources0(runloop,?currentMode,?stopAfterHandle);
????????????///?執(zhí)行被加入的block
????????????__CFRunLoopDoBlocks(runloop,?currentMode);
????????????///?5.?如果有?Source1?(基于port)?處于?ready?狀態(tài)塞耕，直接處理這個?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?到時間了，觸發(fā)這個Timer的回調蜀涨。
????????????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)?{
????????????????///?進入loop時參數(shù)說處理完事件就返回。
????????????????retVal?=?kCFRunLoopRunHandledSource;
????????????}?else?if?(timeout)?{
????????????????///?超出傳入?yún)?shù)標記的超時時間了
????????????????retVal?=?kCFRunLoopRunTimedOut;
????????????}?else?if?(__CFRunLoopIsStopped(runloop))?{
????????????????///?被外部調用者強制停止了
????????????????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)胧奔。當你調用 CFRunLoopRun() 時，線程就會一直停留在這個循環(huán)里预吆；直到超時或被手動停止龙填，該函數(shù)才會返回。
1.6 RunLoop的底層實現(xiàn)(再細讀一遍)
????????從上面代碼可以看到拐叉，RunLoop 的核心是基于 mach port 的岩遗，其進入休眠時調用的函數(shù)是 mach_msg()。為了解釋這個邏輯凤瘦，下面稍微介紹一下 OSX/iOS 的系統(tǒng)架構宿礁。
????????蘋果官方將整個系統(tǒng)大致劃分為上述4個層次：
????? 應用層包括用戶能接觸到的圖形應用，例如 Spotlight蔬芥、Aqua梆靖、SpringBoard 等。
????? 應用框架層即開發(fā)人員接觸到的 Cocoa 等框架笔诵。
????? 核心框架層包括各種核心框架涤姊、OpenGL 等內(nèi)容。
????? Darwin 即操作系統(tǒng)的核心嗤放，包括系統(tǒng)內(nèi)核思喊、驅動、Shell 等內(nèi)容次酌，這一層是開源的恨课，其所有源碼都可以在 opensource.apple.com 里找到舆乔。
????????我們在深入看一下 Darwin 這個核心的架構：
????????其中，在硬件層上面的三個組成部分：Mach剂公、BSD希俩、IOKit (還包括一些上面沒標注的內(nèi)容)，共同組成了 XNU 內(nèi)核纲辽。
????????XNU 內(nèi)核的內(nèi)環(huán)被稱作 Mach颜武，其作為一個微內(nèi)核，僅提供了諸如處理器調度拖吼、IPC (進程間通信)等非常少量的基礎服務鳞上。
????????BSD 層可以看作圍繞 Mach 層的一個外環(huán)，其提供了諸如進程管理吊档、文件系統(tǒng)和網(wǎng)絡等功能篙议。
????????IOKit 層是為設備驅動提供了一個面向對象(C++)的一個框架。
????????Mach 本身提供的 API 非常有限怠硼，而且蘋果也不鼓勵使用 Mach 的 API鬼贱，但是這些API非常基礎香璃，如果沒有這些API的話这难，其他任何工作都無法實施。在 Mach 中葡秒，所有的東西都是通過自己的對象實現(xiàn)的姻乓，進程、線程和虛擬內(nèi)存都被稱為"對象"同云。和其他架構不同糖权， Mach 的對象間不能直接調用，只能通過消息傳遞的方式實現(xiàn)對象間的通信炸站。"消息"是 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 消息實際上就是一個二進制數(shù)據(jù)包 (BLOB)，其頭部定義了當前端口 local_port 和目標端口 remote_port阀坏，發(fā)送和接受消息是通過同一個 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);
????????為了實現(xiàn)消息的發(fā)送和接收，mach_msg() 函數(shù)實際上是調用了一個 Mach 陷阱 (trap)忌堂，即函數(shù)mach_msg_trap()盒至，陷阱這個概念在 Mach 中等同于系統(tǒng)調用。當你在用戶態(tài)調用 mach_msg_trap() 時會觸發(fā)陷阱機制，切換到內(nèi)核態(tài)枷遂；內(nèi)核態(tài)中內(nèi)核實現(xiàn)的 mach_msg() 函數(shù)會完成實際的工作樱衷，如下圖：
????????這些概念可以參考維基百科: System_call、Trap_(computing)酒唉。
????????RunLoop 的核心就是一個 mach_msg() (見上面代碼的第7步)矩桂，RunLoop 調用這個函數(shù)去接收消息，如果沒有別人發(fā)送 port 消息過來痪伦，內(nèi)核會將線程置于等待狀態(tài)侄榴。例如你在模擬器里跑起一個 iOS 的 App，然后在 App 靜止時點擊暫停网沾，你會看到主線程調用棧是停留在 mach_msg_trap() 這個地方癞蚕。
????????關于具體的如何利用 mach port 發(fā)送信息，可以看看 NSHipster 這一篇文章绅这，或者這里的中文翻譯 涣达。
????????關于Mach的歷史可以看看這篇很有趣的文章：Mac?OS X 背后的故事（三）Mach 之父 Avie Tevanian在辆。
1.7 蘋果用RunLoop實現(xiàn)的功能(再細讀一遍)
????????首先我們可以看一下 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)默認注冊了5個Mode:
????1. kCFRunLoopDefaultMode: App的默認Mode，通常主線程是在這個Mode下運行的匆篓。
????2. UITrackingRunLoopMode: 界面跟蹤Mode浑度，用于ScrollView追蹤觸摸滑動，保證界面滑動時不受其他Mode影響鸦概。
????3. UIInitializationRunLoopMode: 在剛啟動App時進入的第一個Mode箩张，啟動完成后就不再使用。
????4: GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內(nèi)部Mode窗市，通常用不到先慷。
????5: kCFRunLoopCommonModes: 這是一個占位的Mode，沒有實際作用咨察。
????????你可以在這里看到更多的蘋果內(nèi)部的 Mode论熙，但那些 Mode 在開發(fā)中就很難遇到了。
????????當RunLoop進行回調時摄狱，一般都是通過一個很長的函數(shù)調用出去 (call out), 當你在你的代碼中下斷點調試時脓诡，通常能在調用棧上看到這些函數(shù)。下面是這幾個函數(shù)的整理版本媒役，如果你在調用棧中看到這些長函數(shù)名祝谚，在這里查找一下就能定位到具體的調用地點了：
{
????///?1.?通知Observers，即將進入RunLoop
????///?此處有Observer會創(chuàng)建AutoreleasePool:?_objc_autoreleasePoolPush();
????__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
????do?{
????????///?2.?通知?Observers:?即將觸發(fā)?Timer?回調酣衷。
????????__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
????????///?3.?通知?Observers:?即將觸發(fā)?Source?(非基于port的,Source0)?回調交惯。
????????__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
????????__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
????????///?4.?觸發(fā)?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喚醒的，執(zhí)行所有調用?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í)行的任務是一條直線，起點到終點炬藤；而另一些線程要干的活則是一個圓御铃，不斷循環(huán)，直到通過某種方式將它終止沈矿。
?????? 這兩類線程能很好的區(qū)別Web開發(fā)與客戶端開發(fā)上真，Web開發(fā)中，每次響應都是直線線程羹膳，執(zhí)行完后即釋放資源睡互，結束了；而客戶端開發(fā)中陵像，每次事件響應其實都是產(chǎn)生一個圓就珠，執(zhí)行操作雖然完成了，但是重要資源與上下文狀態(tài)都存儲在后臺醒颖。
?????? 對應Web開發(fā)的進一步理解：Web開發(fā)中妻怎，中間件層其實也是操作系統(tǒng)服務級別的，即它也是一個runloop泞歉；而對于中間件層里面的站點逼侦，則是直線處理型線程，從接收到請求到響應請求結束腰耙，執(zhí)行完后此線程即結束了榛丢。
?????? 每個線程，包括程序的主線程（main thread）都有與之相應的run loop對象挺庞。
? ??????主線程的runloop默認是啟動的晰赞。iOS的應用程序里面，程序啟動后會有一個如下的main()函數(shù)：
int main(int argc, char* argv[])
{
? ? @autoreleasepool{
????? ??return UIApplicationMain(argc, argv, nil, NSStringFromClass([appDelegate class]));
????}
}
????????重點是UIApplicationMain()函數(shù)挠阁，這個方法會為main thread設置一個NSRunLoop對象宾肺。
? ??????對其它線程來說，run loop默認是沒有啟動的侵俗，如果你需要更多的線程交互則可以手動配置和啟動锨用，如果線程只是去執(zhí)行一個長時間的已確定的任務則不需要。
2 線程與run loop
2.1 線程任務的類型
????????再來說說線程隘谣。有些線程執(zhí)行的任務是一條直線增拥，起點到終點啄巧；而另一些線程要干的活則是一個圓，不斷循環(huán)掌栅，直到通過某種方式將它終止秩仆。直線線程如簡單的Hello World，運行打印完,它的生命周期便結束了猾封，像曇花一現(xiàn)那樣澄耍；圓類型的如操作系統(tǒng)，一直運行直到你關機晌缘。在IOS中齐莲，圓型的線程就是通過run loop不停的循環(huán)實現(xiàn)的。
2.2 線程與run loop的關系
????????Run loop磷箕，正如其名选酗，loop表示某種循環(huán)，和run放在一起就表示一直在運行著的循環(huán)岳枷。實際上芒填，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()函數(shù)：
int main(int argc,char*argv[])
{
? ? ?@autoreleasepool{
????? ??return UIApplicationMain(argc, argv, nil, NSStringFromClass([appDelegate class]));
????}
}
????????重點是UIApplicationMain()函數(shù)掰吕，這個方法會為main thread設置一個NSRunLoop對象，這就解釋了本文開始說的為什么我們的應用可以在無人操作的時候休息颅痊，需要讓它干活的時候又能立馬響應殖熟。
2.2.2 其他線程的Runloop
????????對其它線程來說，run loop默認是沒有啟動的斑响，如果你需要更多的線程交互則可以手動配置和啟動菱属，如果線程只是去執(zhí)行一個長時間的已確定的任務則不需要。
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的管理并不完全是自動的缕溉。
????????我們?nèi)员仨氃O計線程代碼以在適當?shù)臅r候啟動run loop并正確響應輸入事件，當然前提是線程中需要用到run loop吃型。而且证鸥，我們還需要使用while/for語句來驅動run loop能夠循環(huán)運行，下面的代碼就成功驅動了一個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的創(chuàng)建和釋放勤晚。
????????在使用手動的內(nèi)存管理方式的項目中敌土，會經(jīng)常用到很多自動釋放的對象，如果這些對象不能夠被即時釋放掉运翼，會造成內(nèi)存占用量急劇增大返干。Run loop就為我們做了這樣的工作，每當一個運行循環(huán)啟動時血淌，系統(tǒng)會自動創(chuàng)建一個autoreleasepool矩欠，用于掛載在此Runloop執(zhí)行期間生成的autorelease對象，而在Runloop結束的時候悠夯，它都會釋放此autorelease pool癌淮，同時pool中的所有autorelease類型變量都會被釋放掉。
2.4 Run loop的優(yōu)點
????????一個run loop就是一個事件處理循環(huán)沦补，用來不停的監(jiān)聽和處理輸入事件并將其分配到對應的目標上進行處理乳蓄。如果僅僅是想實現(xiàn)這個功能，你可能會想一個簡單的while循環(huán)不就可以實現(xiàn)了嗎夕膀，用得著費老大勁來做個那么復雜的機制虚倒？顯然，蘋果的架構設計師不是吃干飯的产舞，你想到的他們早就想過了魂奥。
????????首先，NSRunLoop是一種更加高明的消息處理模式易猫，他就高明在對消息處理過程進行了更好的抽象和封裝耻煤，這樣才能使你不用處理一些很瑣碎很低層次的具體消息的處理，在NSRunLoop中每一個消息就被打包在input source或者是timer source（見后文）中了准颓。
????????其次哈蝇，也是很重要的一點，使用run loop可以使你的線程在有工作的時候工作攘已，沒有工作的時候休眠炮赦，這可以大大節(jié)省系統(tǒng)資源。
3 Runloop相關知識點
????????Run loop接收輸入事件來自兩種不同的來源：輸入源（input source）和定時源（timer source）贯被。兩種源都使用程序的某一特定的處理例程來處理到達的事件眼五。圖-1顯示了run loop的概念結構以及各種源妆艘。
3.1 輸入事件來源
????????需要說明的是，當你創(chuàng)建輸入源看幼，你需要將其分配給run loop中的一個或多個模式（什么是模式批旺，下文將會講到）。模式只會在特定事件影響監(jiān)聽的源诵姜。大多數(shù)情況下汽煮，run loop運行在默認模式下，但是你也可以使其運行在自定義模式棚唆。若某一源在當前模式下不被監(jiān)聽暇赤，那么任何其生成的消息只在run loop運行在其關聯(lián)的模式下才會被傳遞。
3.1.1 輸入源（input source）
????????傳遞異步事件宵凌，通常消息來自于其他線程或程序鞋囊。輸入源傳遞異步消息給相應的處理例程，并調用runUntilDate:方法來退出(在線程里面相關的NSRunLoop對象調用)瞎惫。
3.1.1.1 基于端口的輸入源
????????基于端口的輸入源由內(nèi)核自動發(fā)送溜腐。
????????Cocoa和Core Foundation內(nèi)置支持使用端口相關的對象和函數(shù)來創(chuàng)建的基于端口的源。例如瓜喇，在Cocoa里面你從來不需要直接創(chuàng)建輸入源挺益。你只要簡單的創(chuàng)建端口對象，并使用NSPort的方法把該端口添加到runloop乘寒。端口對象會自己處理創(chuàng)建和配置輸入源望众。
????????在Core Foundation，你必須人工創(chuàng)建端口和它的run loop源伞辛。我們可以使用端口相關的函數(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類型相關的函數(shù)來創(chuàng)建。你可以使用回調函數(shù)來配置自定義輸入源润文。Core Fundation會在配置源的不同地方調用回調函數(shù)，處理輸入事件，在源從run loop移除的時候清理它睬澡。
????????除了定義在事件到達時自定義輸入源的行為艇拍，你也必須定義消息傳遞機制。源的這部分運行在單獨的線程里面骏掀，并負責在數(shù)據(jù)等待處理的時候傳遞數(shù)據(jù)給源并通知它處理數(shù)據(jù)鸠澈。消息傳遞機制的定義取決于你柱告，但最好不要過于復雜。創(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請求會在目標線程上序列化乖菱，減緩許多在線程上允許多個方法容易引起的同步問題。不像基于端口的源蓬网，一個selector執(zhí)行完后會自動從run loop里面移除窒所。
????????當在其他線程上面執(zhí)行selector時，目標線程須有一個活動的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）
????????定時源在預設的時間點同步方式傳遞消息海渊，這些消息都會發(fā)生在特定時間或者重復的時間間隔。定時源則直接傳遞消息給處理例程哲鸳，不會立即退出run loop臣疑。
????????需要注意的是，盡管定時器可以產(chǎn)生基于時間的通知徙菠，但它并不是實時機制讯沈。和輸入源一樣，定時器也和你的run loop的特定模式相關婿奔。如果定時器所在的模式當前未被run loop監(jiān)視缺狠，那么定時器將不會開始直到run loop運行在相應的模式下。類似的萍摊，如果定時器在run loop處理某一事件期間開始挤茄，定時器會一直等待直到下次run loop開始相應的處理程序。如果run loop不再運行冰木，那定時器也將永遠不啟動穷劈。
????????創(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本身運行的特定時候觸發(fā)歇终。你可以使用run loop觀察者來為處理某一特定事件或是進入休眠的線程做準備。你可以將run loop觀察者和以下事件關聯(lián)：
????1. Runloop入口
????2.? Runloop何時處理一個定時器
????3. Runloop何時處理一個輸入源
????4. Runloop何時進入睡眠狀態(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的事件隊列
????????每次運行run loop，你線程的run loop對會自動處理之前未處理的消息达椰，并通知相關的觀察者翰蠢。具體的順序如下：
????1. 通知觀察者run loop已經(jīng)啟動
????2. 通知觀察者任何即將要開始的定時器
????3. 通知觀察者任何即將啟動的非基于端口的源
????4. 啟動任何準備好的非基于端口的源
????5. 如果基于端口的源準備好并處于等待狀態(tài)，立即啟動啰劲；并進入步驟9梁沧。
????6. 通知觀察者線程進入休眠
????7. 將線程置于休眠直到任一下面的事件發(fā)生：
????????· 某一事件到達基于端口的源
????????· 定時器啟動
????????· Run loop設置的時間已經(jīng)超時
????????· run loop被顯式喚醒
????8. 通知觀察者線程將被喚醒。
? ? 9. 處理未處理的事件
????????· 如果用戶定義的定時器啟動蝇裤，處理定時器事件并重啟run loop廷支。進入步驟2
????????· 如果輸入源啟動，傳遞相應的消息
????????· 如果run loop被顯式喚醒而且時間還沒超時栓辜，重啟run loop恋拍。進入步驟2
????10. 通知觀察者run loop結束。
????????因為定時器和輸入源的觀察者是在相應的事件發(fā)生之前傳遞消息藕甩，所以通知的時間和實際事件發(fā)生的時間之間可能存在誤差施敢。如果需要精確時間控制，你可以使用休眠和喚醒通知來幫助你校對實際發(fā)生事件的時間狭莱。
????????因為當你運行run loop時定時器和其它周期性事件經(jīng)常需要被傳遞僵娃，撤銷run loop也會終止消息傳遞。典型的例子就是鼠標路徑追蹤腋妙。因為你的代碼直接獲取到消息而不是經(jīng)由程序傳遞默怨，因此活躍的定時器不會開始直到鼠標追蹤結束并將控制權交給程序。
????????Run loop可以由run loop對象顯式喚醒骤素。其它消息也可以喚醒run loop匙睹。例如，添加新的非基于端口的源會喚醒run loop從而可以立即處理輸入源而不需要等待其他事件發(fā)生后再處理谆甜。
????????從這個事件隊列中可以看出：
????①如果是事件到達垃僚，消息會被傳遞給相應的處理程序來處理， runloop處理完當次事件后规辱，run loop會退出，而不管之前預定的時間到了沒有栽燕。你可以重新啟動run loop來等待下一事件罕袋。
????②如果線程中有需要處理的源改淑，但是響應的事件沒有到來的時候，線程就會休眠等待相應事件的發(fā)生浴讯。這就是為什么run loop可以做到讓線程有工作的時候忙于工作朵夏，而沒工作的時候處于休眠狀態(tài)。
3.4 什么時候使用run loop
????????僅當在為你的程序創(chuàng)建輔助線程的時候榆纽，你才需要顯式運行一個run loop仰猖。Run loop是程序主線程基礎設施的關鍵部分。所以奈籽，Cocoa和Carbon程序提供了代碼運行主程序的循環(huán)并自動啟動run loop饥侵。IOS程序中UIApplication的run方法（或Mac OS X中的NSApplication）作為程序啟動步驟的一部分，它在程序正常啟動的時候就會啟動程序的主循環(huán)衣屏。類似的躏升，RunApplicationEventLoop函數(shù)為Carbon程序啟動主循環(huán)。如果你使用xcode提供的模板創(chuàng)建你的程序狼忱，那你永遠不需要自己去顯式的調用這些例程膨疏。
????????對于輔助線程，你需要判斷一個run loop是否是必須的钻弄。如果是必須的佃却，那么你要自己配置并啟動它。你不需要在任何情況下都去啟動一個線程的run loop窘俺。比如饲帅，你使用線程來處理一個預先定義的長時間運行的任務時，你應該避免啟動run loop批销。Run loop在你要和線程有更多的交互時才需要洒闸，比如以下情況：
????1. 使用端口或自定義輸入源來和其他線程通信
????2. 使用線程的定時器
????3. Cocoa中使用任何performSelector…的方法
????4. 使線程周期性工作
????????如果你決定在程序中使用run loop，那么它的配置和啟動都很簡單均芽。和所有線程編程一樣丘逸，你需要計劃好在輔助線程退出線程的情形。讓線程自然退出往往比強制關閉它更好掀宋。
4 基于Runloop實現(xiàn)的上層功能
4.1 AutoreleasePool
????????App啟動后深纲，蘋果在主線程 RunLoop 里注冊了兩個 Observer，其回調都是_wrapRunLoopWithAutoreleasePoolHandler()劲妙。
????????第一個 Observer 監(jiān)視的事件是Entry(即將進入Loop)湃鹊，其回調內(nèi)會調用 _objc_autoreleasePoolPush() 創(chuàng)建自動釋放池。其 order 是-2147483647镣奋，優(yōu)先級最高币呵，保證創(chuàng)建釋放池發(fā)生在其他所有回調之前。
????????第二個 Observer 監(jiān)視了兩個事件： BeforeWaiting(準備進入休眠) 時調用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池并創(chuàng)建新池侨颈；Exit(即將退出Loop)時調用 _objc_autoreleasePoolPop() 來釋放自動釋放池余赢。這個 Observer 的 order 是 2147483647芯义，優(yōu)先級最低，保證其釋放只發(fā)生在其他所有回調之后妻柒。
????????在主線程執(zhí)行的代碼扛拨，通常是寫在諸如事件回調、Timer回調內(nèi)的举塔。這些回調會被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著绑警，所以不會出現(xiàn)內(nèi)存泄漏，開發(fā)者也不必顯示創(chuàng)建 Pool 了央渣。
4.2 事件響應（Good）
????????蘋果注冊了一個 Source1 (基于 mach port 的) 用來接收系統(tǒng)事件计盒，其回調函數(shù)為__IOHIDEventSystemClientQueueCallback()。
????????當一個硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后痹屹，首先由 IOKit.framework 生成一個 IOHIDEvent 事件并由SpringBoard 接收章郁。這個過程的詳細情況可以參考這里。SpringBoard只接收按鍵(鎖屏/靜音等)志衍，觸摸暖庄，加速，接近傳感器等幾種 Event楼肪，隨后用mach port 轉發(fā)給需要的App進程培廓。隨后蘋果注冊的那個 Source1 就會觸發(fā)回調，并調用 _UIApplicationHandleEventQueue() 進行應用內(nèi)部的分發(fā)春叫。
????????_UIApplicationHandleEventQueue()會把 IOHIDEvent 處理并包裝成 UIEvent 進行處理或分發(fā)肩钠，其中包括識別 UIGesture/處理屏幕旋轉/發(fā)送給 UIWindow 等。通常事件比如UIButton點擊暂殖、touchesBegin/Move/End/Cancel 事件都是在這個回調中完成的价匠。
4.3 手勢識別
????????當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會調用 Cancel 將當前的 touchesBegin/Move/End 系列回調打斷呛每。隨后系統(tǒng)將對應的 UIGestureRecognizer 標記為待處理踩窖。蘋果注冊了一個 Observer 監(jiān)測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回調函數(shù)是 _UIGestureRecognizerUpdateObserver()晨横，其內(nèi)部會獲取所有剛被標記為待處理的 GestureRecognizer洋腮，并執(zhí)行GestureRecognizer的回調。
????????當有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時手形，這個回調都會進行相應處理啥供。
4.4 界面更新
????????當在操作 UI 時，比如改變了 Frame库糠、更新了 UIView/CALayer 的層次時伙狐，或者手動調用了UIView/CALayer的setNeedsLayout/setNeedsDisplay方法后，這個UIView/CALayer就被標記為待處理，并被提交到一個全局的容器去鳞骤。
????????蘋果注冊了一個Observer監(jiān)聽BeforeWaiting(即將進入休眠)和Exit (即將退出Loop)事件窒百，回調去執(zhí)行一個很長的函數(shù)：
????_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()黍判。這個函數(shù)里會遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實際的繪制和調整豫尽，并更新 UI 界面。
????????這個函數(shù)內(nèi)部的調用棧大概是這樣的：
_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為了節(jié)省資源，并不會在非常準確的時間點回調這個Timer陶舞。Timer有個屬性叫做 Tolerance (寬容度)嗽测，標示了當時間點到后，容許有多少最大誤差肿孵。
????????如果某個時間點被錯過了唠粥，例如執(zhí)行了一個很長的任務，則那個時間點的回調也會跳過去停做，不會延后執(zhí)行晤愧。就比如等公交，如果 10:10 時我忙著玩手機錯過了那個點的公交蛉腌，那我只能等 10:20 這一趟了官份。
????????CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復雜，和 NSTimer 并不一樣烙丛，其內(nèi)部實際是操作了一個 Source）舅巷。如果在兩次屏幕刷新之間執(zhí)行了一個長任務，那其中就會有一幀被跳過去（和 NSTimer 相似）河咽，造成界面卡頓的感覺钠右。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺库北。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題爬舰，其內(nèi)部也用到了 RunLoop，這個稍后我會再單獨寫一頁博客來分析寒瓦。
4.6 PerformSelecter
????????當調用 NSObject 的 performSelecter:afterDelay: 后情屹，實際上其內(nèi)部會創(chuàng)建一個 Timer 并添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop杂腰，則這個方法會失效垃你。
????????當調用 performSelector:onThread: 時，實際上其會創(chuàng)建一個 Timer 加到對應的線程去，同樣的惜颇，如果對應線程沒有 RunLoop 該方法也會失效皆刺。
4.7 關于GCD
????????實際上 RunLoop 底層也會用到GCD的東西，比如RunLoop是用 dispatch_source_t 實現(xiàn)的Timer凌摄。但同時GCD提供的某些接口也用到了 RunLoop羡蛾，例如 dispatch_async()。
????????當調用dispatch_async(dispatch_get_main_queue(), block) 時锨亏，libDispatch 會向主線程的RunLoop發(fā)送消息痴怨，RunLoop會被喚醒，并從消息中取得這個 block器予，并在回調__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__()里執(zhí)行這個block浪藻。但這個邏輯僅限于dispatch到主線程，dispatch到其他線程仍然是由 libDispatch 處理的乾翔。
4.8 關于網(wǎng)絡請求
????????iOS 中爱葵，關于網(wǎng)絡請求的接口自下至上有如下幾層:
????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 這個函數(shù)的內(nèi)部會獲取CurrentRunLoop吭狡，然后在其中的DefaultMode添加了4個 Source0 (即需要手動觸發(fā)的Source)。CFMultiplexerSource 是負責各種 Delegate 回調的丈莺，CFHTTPCookieStorage 是處理各種Cookie的划煮。
????????當開始網(wǎng)絡傳輸時，我們可以看到 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 的通知蟹略。當收到通知后登失，其會在合適的時機向 CFMultiplexerSource 等 Source0 發(fā)送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知挖炬。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執(zhí)行實際的回調揽浙。
4.9 RunLoop的實際應用舉例
4.9.1 AFNetworking
????????AFURLConnectionOperation 這個類是基于 NSURLConnection 構建的，其希望能在后臺線程接收 Delegate 回調茅茂。為此 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 添加進去了空闲。通常情況下，調用者需要持有這個 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];
}
????????當需要這個后臺線程執(zhí)行任務時掉丽，AFNetworking 通過調用 [NSObject performSelector: onThread: ..] 將這個任務扔到了后臺線程的RunLoop中跌榔。
4.9.2 AsyncDisplayKit
????????AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架，其原理大致如下：
????????UI 線程中一旦出現(xiàn)繁重的任務就會導致界面卡頓捶障，這類任務通常分為3類：排版僧须，繪制，UI對象操作项炼。排版通常包括計算視圖大小担平、計算文本高度、重新計算子式圖的排版等操作锭部。繪制一般有文本繪制 (例如 CoreText)暂论、圖片繪制 (例如預先解壓)、元素繪制 (Quartz)等操作拌禾。UI對象操作通常包括 UIView/CALayer 等 UI 對象的創(chuàng)建取胎、設置屬性和銷毀。
????????其中前兩類操作可以通過各種方法扔到后臺線程執(zhí)行湃窍，而最后一類操作只能在主線程完成闻蛀，并且有時后面的操作需要依賴前面操作的結果 （例如TextView創(chuàng)建時可能需要提前計算出文本的大小）您市。ASDK 所做的觉痛，就是盡量將能放入后臺的任務放入后臺，不能的則盡量推遲 (例如視圖的創(chuàng)建墨坚、屬性的調整)秧饮。
????????為此映挂，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)了一套類似的界面更新的機制：即在主線程的 RunLoop 中添加一個Observer锐极，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件，在收到回調時芳肌，遍歷所有之前放入隊列的待處理的任務灵再，然后一一執(zhí)行。
????????具體的代碼可以看這里：_ASAsyncTransactionGroup亿笤。
5 Runloop實踐思考
5.1 Runloop在動畫重復提交調用中的限制
????????對于控件簡單屬性的賦值等操作翎迁，在同一個Runloop中重復設置，最終起作用的會是最后一次净薛，但是如果對控件的變化通過動畫來實現(xiàn)汪榔，則每一次設置動作都會向系統(tǒng)提交一次動畫執(zhí)行命令，而不只是最后一次動畫肃拜。典型運用場景例如導航條的顯示與隱藏：
?????? 不是簡單通過子類中復寫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
