什么是RunLoop？RunLoop的本質(zhì)：
Runloop-Demo
RunLoop 的概念：顧名思義囤官，運行循環(huán)屡久，在程序運行過程中循環(huán)做一些事情。
思考：我們應用程序中的main函數(shù)為什么可以保持無退出呢蛉鹿？
實際上呢，在我們的main函數(shù)中會調(diào)用UIApplicationMain函數(shù)，在這個函數(shù)中會啟動一個運行循環(huán)（也就是我們所說的RunLoop）叨咖，在這個運行循環(huán)中可以處理很多事件，例如屏幕的點擊啊胶，滑動列表甸各，或者網(wǎng)絡請求的返回等等，在處理完事件之后焰坪，會進入等待趣倾，在這個循環(huán)中，并不是一個單純的for循環(huán)或者while循環(huán)某饰，而是從用戶態(tài)到內(nèi)核態(tài)的切換儒恋，以及再從內(nèi)核態(tài)到用戶態(tài)的切換，這里面的等待也不等于死循環(huán)露乏，這里面最重要的是狀態(tài)的切換
Runloop對象
iOS中提供了兩個這樣的對象：NSRunLoop 和 CFRunLoopRef
CFRunLoopRef 是在 CoreFoundation 框架內(nèi)的碧浊，它提供了純 C 函數(shù)的 API，所有這些 API 都是線程安全的瘟仿。
NSRunLoop 是基于 CFRunLoopRef的封裝箱锐，提供了面向?qū)ο蟮?API，但是這些 API 不是線程安全的劳较。
CFRunLoopRef的代碼是開源的驹止，你可以在這里 下載到整個 CoreFoundation 的源碼來查看。
Swift 開源后观蜗，蘋果又維護了一個跨平臺的 CoreFoundation 版本臊恋，這個版本的源碼可能和現(xiàn)有 iOS 系統(tǒng)中的實現(xiàn)略不一樣，但更容易編譯墓捻，而且已經(jīng)適配了 Linux/Windows抖仅。
RunLoop的數(shù)據(jù)結(jié)構
CFRunLoop
- pthread：代表的是線程，RunLoop與線程的關系是一一對應的
- currentMode：是一個CFRunLoopMode這樣一個數(shù)據(jù)結(jié)構
- modes：是一個包含CFRunLoopMode類型的集合（NSMutableSet<CFRunLoopMode*>）
- commonModes：是一個包含NSString類型的集合（NSMutableSet<NSString*>）
- commonModeItems：也是一個集合砖第，在這個集合中包含多個元素撤卢，其中包括多個
Observer，多個Timer梧兼，多個Source
CFRunLoopMode
- name：名稱放吩，例如NSDefaultRunLoopMode，所以說是通過這樣一個名稱來切換對應的模式羽杰，例如在上面的commonModes里面都是名稱字符串渡紫，也就是說通過這些名稱來支持多種模式
- source0：集合類型的數(shù)據(jù)結(jié)構
- source1：集合類型的數(shù)據(jù)結(jié)構
- obsevers：數(shù)組類型的數(shù)據(jù)結(jié)構
- timers：數(shù)組類型的數(shù)據(jù)結(jié)構
CFRunLoopSource
CFRunLoopTimer
CFRunLoopObserver
- kCFRunLoopEntry：RunLoop的入口時機到推，RunLoop將要啟動的時候的回調(diào)通知
- kCFRunLoopBeforeTimers：RunLoop將要處理Timer事件的時候
- kCFRunLoopBeforeSources：RunLoop將要處理Source事件的時候
- kCFRunLoopBeforeWaiting：RunLoop將要進入休眠的時候，將要進行用戶態(tài)到內(nèi)核態(tài)的切換
- kCFRunLoopAfterWaiting：RunLoop將要進入喚醒的時候惕澎，內(nèi)核態(tài)到用戶態(tài)的切換后不久
- kCFRunLoopExit：RunLoop退出的時候
Runloop對外的接口
在 CoreFoundation 里面關于 RunLoop 有5個類:
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef
其中CFRunLoopModeRef類并沒有對外暴露莉测，只是通過 CFRunLoopRef 的接口進行了封裝。他們的關系如下:
一個 RunLoop 包含若干個 Mode集灌，每個 Mode 又包含若干個 Source/Timer/Observer悔雹。每次調(diào)用 RunLoop 的主函數(shù)時，只能指定其中一個 Mode欣喧，這個Mode被稱作 CurrentMode腌零。如果需要切換 Mode，只能退出 Loop唆阿，再重新指定一個 Mode 進入益涧。這樣做主要是為了分隔開不同組的 Source/Timer/Observer，讓其互不影響驯鳖。
CFRunLoopSourceRef
CFRunLoopSourceRef是事件產(chǎn)生的地方闲询。
Source有兩個版本：
? Source0 只包含了一個回調(diào)（函數(shù)指針），它并不能主動觸發(fā)事件浅辙。使用時扭弧，你需要先調(diào)用 CFRunLoopSourceSignal(source)，將這個 Source 標記為待處理记舆，然后手動調(diào)用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop鸽捻，讓其處理這個事件。
? Source1 包含了一個 mach_port 和一個回調(diào)（函數(shù)指針）泽腮，被用于通過內(nèi)核和其他線程相互發(fā)送消息御蒲。這種 Source 能主動喚醒 RunLoop 的線程，其原理在下面會講到诊赊。
CFRunLoopTimerRef
CFRunLoopTimerRef 是基于時間的觸發(fā)器厚满，它和NSTimer是``toll-free bridged的，可以混用碧磅。其包含一個時間長度和一個回調(diào)`（函數(shù)指針）碘箍。當其加入到 RunLoop 時，RunLoop會注冊對應的時間點鲸郊，當時間點到時敲街，RunLoop會被喚醒以執(zhí)行那個回調(diào)。
CFRunLoopObserverRef
CFRunLoopObserverRef是觀察者严望，每個 Observer 都包含了一個回調(diào)（函數(shù)指針），當 RunLoop 的狀態(tài)發(fā)生變化時逻恐，觀察者就能通過回調(diào)接受到這個變化像吻【颍可以觀測的時間點有以下幾個：
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)惭每。
RunLoop 的 Mode
CFRunLoopMode 和 CFRunLoop 的結(jié)構大致如下：
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<Source/Observer/Timer>
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里台腥。
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
同時蘋果還提供了一個操作 Common 標記的字符串：
kCFRunLoopCommonModes (NSRunLoopCommonModes)
你可以用這個字符串來操作 Common Items峻汉，或標記一個 Mode 為 “Common”贴汪。使用時注意區(qū)分這個字符串和其他 mode name。
下面來看下Runloop的mode圖：
在RunLoop中休吠，假如在mode1中運行扳埂，那么在mode2中事件的回調(diào)就會接收不到,RunLoop只接受在當前mode中的回調(diào)。
那么這里有一個經(jīng)典問題瘤礁，當我們在滑動列表時阳懂，為什么會出現(xiàn)cell上的定時器停止的情況以及如何解決?
原因：
因為在列表滑動的時候當前RunLoop的mode從Default切換到了Tracking，所以導致原來mode中的事件回調(diào)接收不到蔚携，想要解決便可將其加入commonModes中
有時你需要一個 Timer希太，在兩個 Mode 中都能得到回調(diào)。
- 一種辦法就是將這個 Timer 分別加入這兩個 Mode酝蜒。
- 還有一種方式誊辉，就是將 Timer 加入到頂層的 RunLoop 的
commonModeItems中。commonModeItems被RunLoop自動更新到所有具有Common屬性的 Mode 里去亡脑。
CommonMode的特殊性
RunLoop 的內(nèi)部邏輯即事件循環(huán)機制
根據(jù)蘋果在文檔里的說明堕澄，RunLoop 內(nèi)部的邏輯大致如下:
- 在RunLoop啟動之后會發(fā)送一個通知，來告知觀察者
- 將要處理Timer/Source0事件這樣一個通知的發(fā)送
- 處理Source0事件
- 如果有Source1要處理霉咨，這時會通過一個go to語句的實現(xiàn)來進行代碼邏輯的跳轉(zhuǎn)蛙紫，處理喚醒是收到的消息
- 如果沒有Source1要處理，線程就將要休眠途戒，同時發(fā)送一個通知坑傅，告訴觀察者
- 然后線程進入一個用戶態(tài)到內(nèi)核態(tài)的切換，休眠喷斋，然后等待喚醒唁毒，喚醒的條件大約包括三種：
1蒜茴、Source1
2、Timer事件
3浆西、外部手動喚醒 - 線程剛被喚醒之后也要發(fā)送一個通知告訴觀察者粉私，然后處理喚醒時收到的消息
- 回到將要處理Timer/Source0事件這樣一個通知的發(fā)送
- 然后再次進行上面步驟，這就是一個RunLoop的事件循環(huán)機制
內(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 回調(diào)窖杀。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: RunLoop 即將觸發(fā) Source0 (非port) 回調(diào)。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
/// 執(zhí)行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 4. RunLoop 觸發(fā) Source0 (非port) 回調(diào)入篮。
sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
/// 執(zhí)行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 5. 如果有 Source1 (基于port) 處于 ready 狀態(tài)陈瘦，直接處理這個 Source1 然后跳轉(zhuǎn)去處理消息。
if (__Source0DidDispatchPortLastTime) {
Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
if (hasMsg) goto handle_msg;
}
/// 通知 Observers: RunLoop 的線程即將進入休眠(sleep)潮售。
if (!sourceHandledThisLoop) {
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
}
/// 7. 調(diào)用 mach_msg 等待接受 mach_port 的消息痊项。線程將進入休眠, 直到被下面某一個事件喚醒。
/// ? 一個基于 port 的Source 的事件酥诽。
/// ? 一個 Timer 到時間了
/// ? RunLoop 自身的超時時間到了
/// ? 被其他什么調(diào)用者手動喚醒
__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort) {
mach_msg(msg, MACH_RCV_MSG, port); // thread wait for receive msg
}
/// 8. 通知 Observers: RunLoop 的線程剛剛被喚醒了鞍泉。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);
/// 收到消息，處理消息肮帐。
handle_msg:
/// 9.1 如果一個 Timer 到時間了咖驮，觸發(fā)這個Timer的回調(diào)。
if (msg_is_timer) {
__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
}
/// 9.2 如果有dispatch到main_queue的block训枢，執(zhí)行block托修。
else if (msg_is_dispatch) {
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
}
/// 9.3 如果一個 Source1 (基于port) 發(fā)出事件了，處理這個事件
else {
CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
if (sourceHandledThisLoop) {
mach_msg(reply, MACH_SEND_MSG, reply);
}
}
/// 執(zhí)行加入到Loop的block
__CFRunLoopDoBlocks(runloop, currentMode);
if (sourceHandledThisLoop && stopAfterHandle) {
/// 進入loop時參數(shù)說處理完事件就返回恒界。
retVal = kCFRunLoopRunHandledSource;
} else if (timeout) {
/// 超出傳入?yún)?shù)標記的超時時間了
retVal = kCFRunLoopRunTimedOut;
} else if (__CFRunLoopIsStopped(runloop)) {
/// 被外部調(diào)用者強制停止了
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)。當你調(diào)用 CFRunLoopRun()時虾宇，線程就會一直停留在這個循環(huán)里搓彻；直到超時或被手動停止，該函數(shù)才會返回
有一個這樣的問題：當我們點擊一個app，從我們點擊到程序啟動好唯、程序運行再到程序殺死這個過程竭沫，系統(tǒng)都發(fā)生了什么呢？
實際上當我們調(diào)用了main函數(shù)之后骑篙，會調(diào)用UIApplicationMain函數(shù)，
在這個函數(shù)內(nèi)部會啟動主線程的RunLoop森书，然后經(jīng)過一系列的處理靶端，最終主線程的RunLoop會處于一個休眠狀態(tài)
然后我們此時如果點擊一下屏幕，會轉(zhuǎn)化成一個Source1來讓我們的主線程喚醒凛膏，
然后當我們殺死程序時杨名，會調(diào)用RunLoop的退出，同時發(fā)送通知告訴觀察者
RunLoop 的底層實現(xiàn)
RunLoop 的核心是基于mach port的猖毫，其進入休眠時調(diào)用的函數(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)核沛厨、驅(qū)動宙地、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)核，僅提供了諸如處理器調(diào)度牢贸、IPC (進程間通信)等非常少量的基礎服務竹观。
BSD 層可以看作圍繞 Mach 層的一個外環(huán)，其提供了諸如進程管理、文件系統(tǒng)和網(wǎng)絡等功能臭增。
IOKit 層是為設備驅(qū)動提供了一個面向?qū)ο?C++)的一個框架懂酱。
Mach 本身提供的 API 非常有限，而且蘋果也不鼓勵使用 Mach 的 API誊抛，但是這些API非沉形基礎妻往，如果沒有這些API的話草冈，其他任何工作都無法實施。在 Mach 中勇劣，所有的東西都是通過自己的對象實現(xiàn)的随夸，進程九默、線程和虛擬內(nèi)存都被稱為”對象”。和其他架構不同宾毒， Mach 的對象間不能直接調(diào)用驼修，只能通過消息傳遞的方式實現(xiàn)對象間的通信≌╊酰”消息”是 Mach 中最基礎的概念乙各，消息在兩個端口 (port) 之間傳遞，這就是 Mach 的 IPC (進程間通信) 的核心癌瘾。
Mach 的消息定義是在 <mach/message.h> 頭文件的觅丰，很簡單：
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ù)實際上是調(diào)用了一個 Mach 陷阱 (trap)咬荷，即函數(shù)mach_msg_trap()冠句，陷阱這個概念在 Mach 中等同于系統(tǒng)調(diào)用。當你在用戶態(tài)調(diào)用 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 調(diào)用這個函數(shù)去接收消息腔召，如果沒有別人發(fā)送 port 消息過來杆查，內(nèi)核會將線程置于等待狀態(tài)。例如你在模擬器里跑起一個 iOS 的 App臀蛛，然后在 App 靜止時點擊暫停亲桦，你會看到主線程調(diào)用棧是停留在 mach_msg_trap() 這個地方崖蜜。
關于具體的如何利用 mach port 發(fā)送信息，可以看看 NSHipster 這一篇文章客峭，或者這里的中文翻譯 豫领。
關于Mach的歷史可以看看這篇很有趣的文章：Mac OS X 背后的故事（三）Mach 之父 Avie Tevanian。
RunLoop 與線程的關系
蘋果不允許直接創(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);
/// 注冊一個回調(diào)，當線程銷毀時样傍，順便也銷毀其對應的 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ā)生在線程結(jié)束時。你只能在一個線程的內(nèi)部獲取其 RunLoop（主線程除外）蚊荣。
實現(xiàn)一個常駐線程
- 為當前線程開啟一個RunLoop
- 向該RunLoop中添加一個Port/Source等維持RunLoop的事件循環(huán)
- 啟動該RunLoop
蘋果用 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 進行回調(diào)時，一般都是通過一個很長的函數(shù)調(diào)用出去 (call out), 當你在你的代碼中下斷點調(diào)試時界睁，通常能在調(diào)用棧上看到這些函數(shù)觉增。下面是這幾個函數(shù)的整理版本，如果你在調(diào)用棧中看到這些長函數(shù)名翻斟，在這里查找一下就能定位到具體的調(diào)用地點了：
{
/// 1. 通知Observers逾礁，即將進入RunLoop
/// 此處有Observer會創(chuàng)建AutoreleasePool: _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
do {
/// 2. 通知 Observers: 即將觸發(fā) Timer 回調(diào)。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: 即將觸發(fā) Source (非基于port的,Source0) 回調(diào)访惜。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 4. 觸發(fā) Source0 (非基于port的) 回調(diào)嘹履。
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 6. 通知Observers，即將進入休眠
/// 此處有Observer釋放并新建AutoreleasePool: _objc_autoreleasePoolPop(); _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeWaiting);
/// 7. sleep to wait msg.
mach_msg() -> mach_msg_trap();
/// 8. 通知Observers债热，線程被喚醒
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopAfterWaiting);
/// 9. 如果是被Timer喚醒的砾嫉，回調(diào)Timer
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);
/// 9. 如果是被dispatch喚醒的，執(zhí)行所有調(diào)用 dispatch_async 等方法放入main queue 的 block
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(dispatched_block);
/// 9. 如果如果Runloop是被 Source1 (基于port的) 的事件喚醒了窒篱，處理這個事件
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__(source1);
} while (...);
/// 10. 通知Observers焕刮，即將退出RunLoop
/// 此處有Observer釋放AutoreleasePool: _objc_autoreleasePoolPop();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopExit);
}
-
AutoreleasePool
App啟動后，蘋果在主線程 RunLoop 里注冊了兩個 Observer墙杯，其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()配并。
第一個 Observer 監(jiān)視的事件是 Entry(即將進入Loop)，其回調(diào)內(nèi)會調(diào)用 _objc_autoreleasePoolPush() 創(chuàng)建自動釋放池高镐。其 order 是-2147483647溉旋，優(yōu)先級最高，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前嫉髓。
第二個 Observer 監(jiān)視了兩個事件： BeforeWaiting(準備進入休眠) 時調(diào)用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池并創(chuàng)建新池观腊；Exit(即將退出Loop) 時調(diào)用 _objc_autoreleasePoolPop() 來釋放自動釋放池。這個 Observer 的 order 是 2147483647岩喷，優(yōu)先級最低恕沫，保證其釋放池子發(fā)生在其他所有回調(diào)之后。
在主線程執(zhí)行的代碼纱意，通常是寫在諸如事件回調(diào)婶溯、Timer回調(diào)內(nèi)的。這些回調(diào)會被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著偷霉，所以不會出現(xiàn)內(nèi)存泄漏迄委，開發(fā)者也不必顯示創(chuàng)建 Pool 了。
-
事件響應
蘋果注冊了一個 Source1 (基于 mach port 的) 用來接收系統(tǒng)事件类少，其回調(diào)函數(shù)為 __IOHIDEventSystemClientQueueCallback()叙身。
當一個硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后，首先由 IOKit.framework 生成一個 IOHIDEvent 事件并由 SpringBoard 接收硫狞。這個過程的詳細情況可以參考這里信轿。SpringBoard 只接收按鍵(鎖屏/靜音等)晃痴，觸摸，加速财忽，接近傳感器等幾種 Event倘核，隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進程。隨后蘋果注冊的那個 Source1 就會觸發(fā)回調(diào)即彪，并調(diào)用 _UIApplicationHandleEventQueue() 進行應用內(nèi)部的分發(fā)紧唱。
_UIApplicationHandleEventQueue() 會把 IOHIDEvent 處理并包裝成 UIEvent 進行處理或分發(fā)，其中包括識別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等隶校。通常事件比如 UIButton 點擊漏益、touchesBegin/Move/End/Cancel 事件都是在這個回調(diào)中完成的。
-
手勢識別
當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時深胳，其首先會調(diào)用 Cancel 將當前的 touchesBegin/Move/End 系列回調(diào)打斷绰疤。隨后系統(tǒng)將對應的 UIGestureRecognizer 標記為待處理。
蘋果注冊了一個 Observer 監(jiān)測 BeforeWaiting (Loop即將進入休眠) 事件舞终，這個Observer的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()峦睡，其內(nèi)部會獲取所有剛被標記為待處理的 GestureRecognizer，并執(zhí)行GestureRecognizer的回調(diào)权埠。
當有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時，這個回調(diào)都會進行相應處理煎谍。
-
界面更新
當在操作 UI 時攘蔽，比如改變了 Frame、更新了 UIView/CALayer 的層次時呐粘，或者手動調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后满俗，這個 UIView/CALayer 就被標記為待處理，并被提交到一個全局的容器去作岖。
蘋果注冊了一個 Observer 監(jiān)聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件唆垃，回調(diào)去執(zhí)行一個很長的函數(shù)：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數(shù)里會遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實際的繪制和調(diào)整痘儡，并更新 UI 界面辕万。
這個函數(shù)內(nèi)部的調(diào)用棧大概是這樣的：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
QuartzCore:CA::Transaction::observer_callback:
CA::Transaction::commit();
CA::Context::commit_transaction();
CA::Layer::layout_and_display_if_needed();
CA::Layer::layout_if_needed();
[CALayer layoutSublayers];
[UIView layoutSubviews];
CA::Layer::display_if_needed();
[CALayer display];
[UIView drawRect];
-
定時器
NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的沉删。一個 NSTimer 注冊到 RunLoop 后渐尿，RunLoop 會為其重復的時間點注冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點矾瑰。RunLoop為了節(jié)省資源砖茸，并不會在非常準確的時間點回調(diào)這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)殴穴，標示了當時間點到后凉夯，容許有多少最大誤差货葬。
如果某個時間點被錯過了，例如執(zhí)行了一個很長的任務劲够，則那個時間點的回調(diào)也會跳過去震桶，不會延后執(zhí)行。就比如等公交再沧，如果 10:10 時我忙著玩手機錯過了那個點的公交尼夺，那我只能等 10:20 這一趟了。
CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復雜炒瘸，和 NSTimer 并不一樣淤堵，其內(nèi)部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執(zhí)行了一個長任務顷扩，那其中就會有一幀被跳過去（和 NSTimer 相似）拐邪，造成界面卡頓的感覺。在快速滑動TableView時隘截，即使一幀的卡頓也會讓用戶有所察覺扎阶。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題，其內(nèi)部也用到了 RunLoop婶芭，這個稍后我會再單獨寫一頁博客來分析东臀。
-
PerformSelecter
當調(diào)用 NSObject 的 performSelecter:afterDelay: 后，實際上其內(nèi)部會創(chuàng)建一個 Timer 并添加到當前線程的 RunLoop 中犀农。所以如果當前線程沒有 RunLoop惰赋，則這個方法會失效。
當調(diào)用 performSelector:onThread: 時呵哨，實際上其會創(chuàng)建一個 Timer 加到對應的線程去赁濒，同樣的，如果對應線程沒有 RunLoop 該方法也會失效孟害。
-
關于GCD
實際上 RunLoop 底層也會用到 GCD 的東西拒炎，比如 RunLoop 是用 dispatch_source_t 實現(xiàn)的 Timer（評論中有人提醒，NSTimer 是用了 XNU 內(nèi)核的 mk_timer挨务，我也仔細調(diào)試了一下击你，發(fā)現(xiàn) NSTimer 確實是由 mk_timer 驅(qū)動，而非 GCD 驅(qū)動的）耘子。但同時 GCD 提供的某些接口也用到了 RunLoop果漾， 例如 dispatch_async()。
當調(diào)用 dispatch_async(dispatch_get_main_queue(), block) 時谷誓，libDispatch 會向主線程的 RunLoop 發(fā)送消息绒障，RunLoop會被喚醒，并從消息中取得這個 block捍歪，并在回調(diào) CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里執(zhí)行這個 block户辱。但這個邏輯僅限于 dispatch 到主線程鸵钝，dispatch 到其他線程仍然是由 libDispatch 處理的。
-
關于網(wǎng)絡請求
OS 中庐镐，關于網(wǎng)絡請求的接口自下至上有如下幾層:
CFSocket
CFNetwork ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession ->AFNetworking2, Alamofire
CFSocket 是最底層的接口恩商，只負責 socket 通信。
? CFNetwork 是基于 CFSocket 等接口的上層封裝必逆，ASIHttpRequest 工作于這一層怠堪。
? NSURLConnection 是基于 CFNetwork 的更高層的封裝，提供面向?qū)ο蟮慕涌诿迹珹FNetworking 工作于這一層粟矿。
? NSURLSession 是 iOS7 中新增的接口，表面上是和 NSURLConnection 并列的损拢，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)陌粹，AFNetworking2 和 Alamofire 工作于這一層。
下面主要介紹下 NSURLConnection 的工作過程福压。
通常使用 NSURLConnection 時掏秩，你會傳入一個 Delegate，當調(diào)用了 [connection start] 后荆姆，這個 Delegate 就會不停收到事件回調(diào)蒙幻。實際上，start 這個函數(shù)的內(nèi)部會會獲取 CurrentRunLoop胆筒，然后在其中的 DefaultMode 添加了4個 Source0 (即需要手動觸發(fā)的Source)杆煞。CFMultiplexerSource 是負責各種 Delegate 回調(diào)的，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í)行實際的回調(diào)。
RunLoop 的實際應用舉例
- 控制線程生命周期（線程钡活）
- 解決NSTimer在滑動時停止工作問題
- 監(jiān)控應用卡頓
- 性能優(yōu)化
- AFNetworking
- AsyncDisplayKit
未完待續(xù)~~
RunLoop相關問題總結(jié)
Run Loops 官方文檔
Runloop圖解鞏固
main函數(shù)不退出撕阎，就是runloop
數(shù)據(jù)之間的關系：一對多
同一個timer添加到多個mode
問題：
//添加到commonMode上
參考文章：
RunLoop本質(zhì)、數(shù)據(jù)結(jié)構以及常駐線程實現(xiàn)
深入理解RunLoop
iOS觸摸點擊事件之runloop做了什么碌补？
