|
RunLoop 是 iOS 和 OS X 開發(fā)中非?；A(chǔ)的一個概念，這篇文章將從 CFRunLoop 的源碼入手,，介紹 RunLoop 的概念以及底層實現(xiàn)原理,。之后會介紹一下在 iOS 中，蘋果是如何利用 RunLoop 實現(xiàn)自動釋放池,、延遲回調(diào),、觸摸事件、屏幕刷新等功能的,。 目錄
RunLoop 的概念 一般來講,，一個線程一次只能執(zhí)行一個任務(wù)，執(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)這種模型的關(guān)鍵點在于：如何管理事件/消息,，如何讓線程在沒有處理消息時休眠以避免資源占用、在有消息到來時立刻被喚醒,。 所以,，RunLoop 實際上就是一個對象，這個對象管理了其需要處理的事件和消息,，并提供了一個入口函數(shù)來執(zhí)行上面 Event Loop 的邏輯,。線程執(zhí)行了這個函數(shù)后，就會一直處于這個函數(shù)內(nèi)部 '接受消息->等待->處理' 的循環(huán)中,，直到這個循環(huán)結(jié)束（比如傳入 quit 的消息），函數(shù)返回,。 OSX/iOS 系統(tǒng)中,，提供了兩個這樣的對象：NSRunLoop 和 CFRunLoopRef。 CFRunLoopRef 是在 CoreFoundation 框架內(nèi)的,，它提供了純 C 函數(shù)的 API,，所有這些 API 都是線程安全的。 NSRunLoop 是基于 CFRunLoopRef 的封裝,，提供了面向?qū)ο蟮?API,，但是這些 API 不是線程安全的。 CFRunLoopRef 的代碼是開源的,，你可以在這里 http://opensource.apple.com/tarballs/CF/CF-855.17.tar.gz 下載到整個 CoreFoundation 的源碼,。為了方便跟蹤和查看，你可以新建一個 Xcode 工程,，把這堆源碼拖進去看,。 RunLoop 與線程的關(guān)系 首先，iOS 開發(fā)中能遇到兩個線程對象: pthread_t 和 NSThread,。過去蘋果有份文檔標明了 NSThread 只是 pthread_t 的封裝,，但那份文檔已經(jīng)失效了，現(xiàn)在它們也有可能都是直接包裝自最底層的 mach thread,。蘋果并沒有提供這兩個對象相互轉(zhuǎn)換的接口,，但不管怎么樣，可以肯定的是 pthread_t 和 NSThread 是一一對應(yīng)的,。比如,，你可以通過 pthread_main_np() 或 [NSThread mainThread] 來獲取主線程；也可以通過 pthread_self() 或 [NSThread currentThread] 來獲取當前線程,。CFRunLoop 是基于 pthread 來管理的,。 蘋果不允許直接創(chuàng)建 RunLoop，它只提供了兩個自動獲取的函數(shù)：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 這兩個函數(shù)內(nèi)部的邏輯大概是下面這樣: /// 全局的Dictionary,，key 是 pthread_t,， value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 訪問 loopsDic 時的鎖
static CFSpinLock_t loopsLock;
/// 獲取一個 pthread 對應(yīng)的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {
OSSpinLockLock(&loopsLock);
if (!loopsDic) {
// 第一次進入時,，初始化全局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)，當線程銷毀時,，順便也銷毀其對應(yīng)的 RunLoop,。
_CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
return loop;
}
CFRunLoopRef CFRunLoopGetMain() {
return _CFRunLoopGet(pthread_main_thread_np());
}
CFRunLoopRef CFRunLoopGetCurrent() {
return _CFRunLoopGet(pthread_self());
}從上面的代碼可以看出，線程和 RunLoop 之間是一一對應(yīng)的,，其關(guān)系是保存在一個全局的 Dictionary 里,。線程剛創(chuàng)建時并沒有 RunLoop，如果你不主動獲取,，那它一直都不會有,。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時，RunLoop 的銷毀是發(fā)生在線程結(jié)束時,。你只能在一個線程的內(nèi)部獲取其 RunLoop（主線程除外）,。 RunLoop 對外的接口 在 CoreFoundation 里面關(guān)于 RunLoop 有5個類:
其中 CFRunLoopModeRef 類并沒有對外暴露，只是通過 CFRunLoopRef 的接口進行了封裝,。他們的關(guān)系如下:
一個 RunLoop 包含若干個 Mode,，每個 Mode 又包含若干個 Source/Timer/Observer。每次調(diào)用 RunLoop 的主函數(shù)時,，只能指定其中一個 Mode,，這個Mode被稱作 CurrentMode。如果需要切換 Mode,，只能退出 Loop,，再重新指定一個 Mode 進入。這樣做主要是為了分隔開不同組的 Source/Timer/Observer,，讓其互不影響,。 CFRunLoopSourceRef 是事件產(chǎn)生的地方。Source有兩個版本：Source0 和 Source1,。
CFRunLoopTimerRef 是基于時間的觸發(fā)器，它和 NSTimer 是toll-free bridged 的,，可以混用,。其包含一個時間長度和一個回調(diào)（函數(shù)指針）。當其加入到 RunLoop 時,，RunLoop會注冊對應(yīng)的時間點,，當時間點到時，RunLoop會被喚醒以執(zhí)行那個回調(diào),。 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 被重復(fù)加入同一個 mode 時是不會有效果的,。如果一個 mode 中一個 item 都沒有,，則 RunLoop 會直接退出，不進入循環(huán),。 RunLoop 的 Mode CFRunLoopMode 和 CFRunLoop 的結(jié)構(gòu)大致如下： 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 的內(nèi)容發(fā)生變化時，RunLoop 都會自動將 _commonModeItems 里的 Source/Observer/Timer 同步到具有 'Common' 標記的所有Mode里,。 應(yīng)用場景舉例：主線程的 RunLoop 里有兩個預(yù)置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode,。這兩個 Mode 都已經(jīng)被標記為'Common'屬性。DefaultMode 是 App 平時所處的狀態(tài),，TrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態(tài),。當你創(chuàng)建一個 Timer 并加到 DefaultMode 時，Timer 會得到重復(fù)回調(diào),，但此時滑動一個TableView時,，RunLoop 會將 mode 切換為 TrackingRunLoopMode，這時 Timer 就不會被回調(diào),，并且也不會影響到滑動操作,。 有時你需要一個 Timer,，在兩個 Mode 中都能得到回調(diào)，一種辦法就是將這個 Timer 分別加入這兩個 Mode,。還有一種方式,，就是將 Timer 加入到頂層的 RunLoop 的 'commonModeItems' 中。'commonModeItems' 被 RunLoop 自動更新到所有具有'Common'屬性的 Mode 里去,。 CFRunLoop對外暴露的管理 Mode 接口只有下面2個: CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName); CFRunLoopRunInMode(CFStringRef modeName, ...); Mode 暴露的管理 mode item 的接口有下面幾個： CFRunLoopAddSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName); CFRunLoopAddObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName); CFRunLoopAddTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode); CFRunLoopRemoveSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName); CFRunLoopRemoveObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName); CFRunLoopRemoveTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode); 你只能通過 mode name 來操作內(nèi)部的 mode,，當你傳入一個新的 mode name 但 RunLoop 內(nèi)部沒有對應(yīng) mode 時，RunLoop會自動幫你創(chuàng)建對應(yīng)的 CFRunLoopModeRef,。對于一個 RunLoop 來說,，其內(nèi)部的 mode 只能增加不能刪除。 蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode,，你可以用這兩個 Mode Name 來操作其對應(yīng)的 Mode,。 同時蘋果還提供了一個操作 Common 標記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，你可以用這個字符串來操作 Common Items,，或標記一個 Mode 為 'Common',。使用時注意區(qū)分這個字符串和其他 mode name。 RunLoop 的內(nèi)部邏輯 根據(jù)蘋果在文檔里的說明,，RunLoop 內(nèi)部的邏輯大致如下:
其內(nèi)部代碼整理如下 （太長了不想看可以直接跳過去,，后面會有說明）： /// 用DefaultMode啟動
void CFRunLoopRun(void) {
CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}
/// 用指定的Mode啟動，允許設(shè)置RunLoop超時時間
int CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean stopAfterHandle) {
return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}
/// RunLoop的實現(xiàn)
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
/// 首先根據(jù)modeName找到對應(yīng)mode
CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
/// 如果mode里沒有source/timer/observer, 直接返回,。
if (__CFRunLoopModeIsEmpty(currentMode)) return;
/// 1. 通知 Observers: RunLoop 即將進入 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ù)才會返回,。 RunLoop 的底層實現(xiàn) 從上面代碼可以看到，RunLoop 的核心是基于 mach port 的,，其進入休眠時調(diào)用的函數(shù)是 mach_msg(),。為了解釋這個邏輯，下面稍微介紹一下 OSX/iOS 的系統(tǒng)架構(gòu),。
蘋果官方將整個系統(tǒng)大致劃分為上述4個層次：
我們在深入看一下 Darwin 這個核心的架構(gòu)：
其中,，在硬件層上面的三個組成部分：Mach,、BSD、IOKit (還包括一些上面沒標注的內(nèi)容),，共同組成了 XNU 內(nèi)核,。 XNU 內(nèi)核的內(nèi)環(huán)被稱作 Mach，其作為一個微內(nèi)核,，僅提供了諸如處理器調(diào)度,、IPC (進程間通信)等非常少量的基礎(chǔ)服務(wù),。 BSD 層可以看作圍繞 Mach 層的一個外環(huán)，其提供了諸如進程管理,、文件系統(tǒng)和網(wǎng)絡(luò)等功能,。 IOKit 層是為設(shè)備驅(qū)動提供了一個面向?qū)ο?C )的一個框架。 Mach 本身提供的 API 非常有限,，而且蘋果也不鼓勵使用 Mach 的 API,，但是這些API非常基礎(chǔ),，如果沒有這些API的話,，其他任何工作都無法實施。在 Mach 中,，所有的東西都是通過自己的對象實現(xiàn)的,，進程、線程和虛擬內(nèi)存都被稱為'對象',。和其他架構(gòu)不同,， Mach 的對象間不能直接調(diào)用，只能通過消息傳遞的方式實現(xiàn)對象間的通信,。'消息'是 Mach 中最基礎(chǔ)的概念,，消息在兩個端口 (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ù)實際上是調(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() 這個地方,。 關(guān)于具體的如何利用 mach port 發(fā)送信息，可以看看 NSHipster 這一篇文章,，或者這里的中文翻譯 ,。 關(guān)于Mach的歷史可以看看這篇很有趣的文章：Mac OS X 背后的故事（三）Mach 之父 Avie Tevanian。 蘋果用 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 了。 事件響應(yīng) 蘋果注冊了一個 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() 進行應(yīng)用內(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)將對應(yī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)都會進行相應(yīng)處理。 界面更新 當在操作 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 會為其重復(fù)的時間點注冊好事件,。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節(jié)省資源,，并不會在非常準確的時間點回調(diào)這個Timer,。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到后,，容許有多少最大誤差,。 如果某個時間點被錯過了，例如執(zhí)行了一個很長的任務(wù),，則那個時間點的回調(diào)也會跳過去,，不會延后執(zhí)行。就比如等公交,，如果 10:10 時我忙著玩手機錯過了那個點的公交,，那我只能等 10:20 這一趟了。 CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復(fù)雜,，和 NSTimer 并不一樣,，其內(nèi)部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執(zhí)行了一個長任務(wù),，那其中就會有一幀被跳過去（和 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 加到對應(yīng)的線程去,，同樣的，如果對應(yīng)線程沒有 RunLoop 該方法也會失效,。 關(guān)于GCD 實際上 RunLoop 底層也會用到 GCD 的東西,，比如 RunLoop 是用 dispatch_source_t 實現(xiàn)的 Timer。但同時 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 處理的。 關(guān)于網(wǎng)絡(luò)請求 iOS 中,，關(guān)于網(wǎng)絡(luò)請求的接口自下至上有如下幾層: CFSocket CFNetwork ->ASIHttpRequest NSURLConnection ->AFNetworking NSURLSession ->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)絡(luò)傳輸時,，我們可以看到 NSURLConnection 創(chuàng)建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private,。其中 CFSocket 線程是處理底層 socket 連接的。NSURLConnectionLoader 這個線程內(nèi)部會使用 RunLoop 來接收底層 socket 的事件,，并通過之前添加的 Source0 通知到上層的 Delegate,。
NSURLConnectionLoader 中的 RunLoop 通過一些基于 mach port 的 Source 接收來自底層 CFSocket 的通知。當收到通知后,，其會在合適的時機向 CFMultiplexerSource 等 Source0 發(fā)送通知,，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執(zhí)行實際的回調(diào),。 RunLoop 的實際應(yīng)用舉例 AFNetworking AFURLConnectionOperation 這個類是基于 NSURLConnection 構(gòu)建的,，其希望能在后臺線程接收 Delegate 回調(diào)。為此 AFNetworking 單獨創(chuàng)建了一個線程,，并在這個線程中啟動了一個 RunLoop： (void)networkRequestThreadEntryPoint:(id)__unused object {
@autoreleasepool {
[[NSThread currentThread] setName:@'AFNetworking'];
NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runLoop run];
}
}
(NSThread *)networkRequestThread {
static NSThread *_networkRequestThread = nil;
static dispatch_once_t oncePredicate;
dispatch_once(&oncePredicate, ^{
_networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
[_networkRequestThread start];
});
return _networkRequestThread;
}RunLoop 啟動前內(nèi)部必須要有至少一個 Timer/Observer/Source,，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個新的 NSMachPort 添加進去了。通常情況下,，調(diào)用者需要持有這個 NSMachPort (mach_port) 并在外部線程通過這個 port 發(fā)送消息到 loop 內(nèi),；但此處添加 port 只是為了讓 RunLoop 不至于退出，并沒有用于實際的發(fā)送消息,。 - (void)start {
[self.lock lock];
if ([self isCancelled]) {
[self performSelector:@selector(cancelConnection) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
} else if ([self isReady]) {
self.state = AFOperationExecutingState;
[self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
}
[self.lock unlock];
}當需要這個后臺線程執(zhí)行任務(wù)時,，AFNetworking 通過調(diào)用 [NSObject performSelector:onThread:..] 將這個任務(wù)扔到了后臺線程的 RunLoop 中。 AsyncDisplayKit AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架,，其原理大致如下： UI 線程中一旦出現(xiàn)繁重的任務(wù)就會導(dǎo)致界面卡頓,，這類任務(wù)通常分為3類：排版，繪制,，UI對象操作,。 排版通常包括計算視圖大小、計算文本高度,、重新計算子式圖的排版等操作,。 繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預(yù)先解壓),、元素繪制 (Quartz)等操作,。 UI對象操作通常包括 UIView/CALayer 等 UI 對象的創(chuàng)建、設(shè)置屬性和銷毀,。 其中前兩類操作可以通過各種方法扔到后臺線程執(zhí)行,，而最后一類操作只能在主線程完成，并且有時后面的操作需要依賴前面操作的結(jié)果 （例如TextView創(chuàng)建時可能需要提前計算出文本的大?。?。ASDK 所做的,，就是盡量將能放入后臺的任務(wù)放入后臺，不能的則盡量推遲 (例如視圖的創(chuàng)建,、屬性的調(diào)整),。 為此，ASDK 創(chuàng)建了一個名為 ASDisplayNode 的對象,，并在內(nèi)部封裝了 UIView/CALayer，它具有和 UIView/CALayer 相似的屬性,，例如 frame,、backgroundColor等。所有這些屬性都可以在后臺線程更改,，開發(fā)者可以只通過 Node 來操作其內(nèi)部的 UIView/CALayer,，這樣就可以將排版和繪制放入了后臺線程。但是無論怎么操作,，這些屬性總需要在某個時刻同步到主線程的 UIView/CALayer 去,。 ASDK 仿照 QuartzCore/UIKit 框架的模式，實現(xiàn)了一套類似的界面更新的機制：即在主線程的 RunLoop 中添加一個 Observer,，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件,，在收到回調(diào)時，遍歷所有之前放入隊列的待處理的任務(wù),，然后一一執(zhí)行,。 具體的代碼可以看這里：_ASAsyncTransactionGroup。 |
|
|
