RunLoop是iOS和OSX開發(fā)中非常基礎(chǔ)的一個概念.首先從CFRunLoop的源碼入手,介紹RunLoop的概念以及底層實現(xiàn)原理.還有蘋果是如何利用RunLoop實現(xiàn)自動釋放池,延遲回調(diào),觸摸事件,屏幕刷新等功能.
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)這種模型的關(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ū)ο蟮腁PI,但是這些API不是線程安全的.
CFRunLoopRef的代碼是開源的,你可以在這里http://opensource.apple.com/tarballs/CF/下載到整個CoreFoundation的源碼來查看.
(Update:Swift開源后,蘋果又維護了一個跨平臺的CoreFoundation版本:https://github.com/apple/swift-corelibs-foundation/,這個版本的源碼可能和現(xiàn)有的iOS系統(tǒng)中的實現(xiàn)略不一樣,但更容易編譯,而且已經(jīng)適配了Linux/Windows)
RunLoop與線程的關(guān)系
首先,iOS開發(fā)中能遇到兩個線程對象:pthread_t和NSThread.過去蘋果有份文檔標明了NSThread只是pthread_t的封裝,但是那份文檔已經(jīng)失效了.現(xiàn)在他們也有可能都是直接包裝自最底層的mac thread.蘋果并沒有提供這兩個對象互相轉(zhuǎn)換的接口.但不管怎么樣,可以肯定的就是pthread_t和NSThread是一一對應的.比如你可以通過pthread_main_thread_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);
///注冊一個回調(diào),當線程銷毀時候,順便也銷毀其對應的RunLoop
_CFSetTSD(...,thread,loop,_CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
return loop;
}
上面的代碼可以看出,線程和RunLoop之間是一一對應的.其關(guān)系是保存在一個全局的字典中,線程剛創(chuàng)建時并沒有RunLoop.如果你不主動獲取.那么他就一直不會有,RunLoop的創(chuàng)建是發(fā)生在第一次獲取時,RunLoop的銷毀是發(fā)生在線程結(jié)束時,你只能在一個線程的內(nèi)部獲取其RunLoop(主線程除外)
RunLoop對外的接口
在CoreFoundation里面關(guān)于RunLoop有5個類.
- CFRunLoopRef
- CFRunLoopModeRef
- CFRunLoopSourceRef
- CFRunLoopTimerRef
- CFRunLoopObserverRef
其中CFRunLoopModeRef類并沒有對外暴露,只是通過CFRunLoopRef的接口進行了封裝.他們的關(guān)系如下:
RunLoop關(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有兩個版本:Source()和Source1.
- 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 ***是基于時間的觸發(fā)器,它和NSTimer是toll-free bridged的.可以混用.其包含一個時間長度和一個回調(diào)(函數(shù)指針).當其加入到RRunLoop時,RunLoop會注冊對應的時間點,當時間點到時,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被重復加入同一個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(Source/Timer/Observer)
CFMutableModeRef _currentMode; //Current RunLoop Mode
CFMutableSetRef _modes; //Set
};
這個有個概念叫"CommonModes":一個Mode可以將自己標記為"Common"屬性(通過將其ModeName添加到RunLoop的"CommonModes"中).每當RunLoop的內(nèi)容變化時,RunLoop都會自動將_commonModeItems里的Source/Timer/Observer同步到具有"Common"標記的所有mode里面.
應用場景舉例:主線程的RunLoop里有兩個預置的Mode:KCFRunLoopDefaultMode和UITrackingRunLoopMode.這兩個Mode都已經(jīng)被標注為"Common"屬性.DefaultMode 是App平時所處的狀態(tài).TrackingRunLoopMode是追蹤ScrollView滑動時候的狀態(tài).當你創(chuàng)建一個Timer并加到DefaultMode時候,Timer會得到重復回調(diào).但此時滑動一個TableView時,RunLoop會將mode切換為TrackingRunLoopMode,這是Timer就不會被回調(diào),并且也不會影響到滑動操作.
重點 有時候你需要一個Timer.在兩個Mode中都能得到回調(diào).一種辦法就是將這個Timer分別加入這兩個Mode中. 還有一種方式,就是將NSTimer加入到頂層的RunLoop的"commonModelItems"中. "commonModelItems"被RunLoop自動更新到所有具有"Common"屬性的model中去.上面剛剛講過. 重復看一遍 CommonModes這個概念的講解
CFRunLoop對外暴露的管理Mode接口只有下面兩個
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName); //Mode可以將自己標記為"Common"屬性(通過這個方法將其ModeName添加到RunLoop的CommonModes中.)
CFRunLoopRunInMode(CFStringRef modeName,...); //來使當前線程的run
loop以指定模式運行起來一段時間或者直到run loop被停止
***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只能增加不能刪除.
蘋果公開提供的Model有兩個:KCFRunLoopDefaultMode(NSDefaultRunLoopMode)和UITrackingRunLoopMode.你可以用這兩個Mode Name來操作其對應的Mode.
同時蘋果還提供了一個操作Common標記的字符串:KCFRunLoopCommonModes(NSRunLoopCommonModes),你可以用這個字符串來操作Common Items,或者標記一個Mode為"Common".使用時注意區(qū)分這個字符串和其他mode name.
一個Mode中可以有多個Source(事件源,輸入源,基于端口事件源,例如鍵盤觸摸等),Observer(觀察者,觀察當前RunLoop運行狀態(tài))和Timer(定時器事件源).但是必須至少有一個Source或者Timer.因為如果Mode為空,RunLoop運行到空模式不會進行空轉(zhuǎn),就會立即退出.
系統(tǒng)默認注冊了5個Mode;
- KCFRunLoopDefaultMode:App默認的Mode.通常主線程是在這個Mode下運行的
- UITrackingRunLoopMode:界面追蹤Mode,用于ScrollView追蹤觸摸滑動.保證界面滑動時不受其他Mode影響.
- UIInitIalizationRunLoopMode: 在剛啟動App時進入的第一個Mode,啟動完成后就不再使用.
- GSEventReceiveRunLoopMode:接受系統(tǒng)事件內(nèi)部Mode.通常用不到.
- KCFRunLoopCommonModes:這是一個占位用的Mode,作為標記KCFRunLoopDefaultMode 和 UITrackingRunLoopMode用.并不是一種真正的Mode.
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找到對應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)大致劃分為上述四個層次:
應用層包括用戶能接觸到的圖形應用,例如spotlight,aqua,springBoard等
應用框架層即開發(fā)人員接觸到的cocoa等框架
核心框架層包括各種核心框架,OPenGL等內(nèi)容.
Darwin即操作系統(tǒng)的核心,包括系統(tǒng)內(nèi)核,驅(qū)動,shell等內(nèi)容.這一層是開源的. 其所有開源都可以在opensource.apple.com里面找到.
我們再深入看一下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ǔ)服務.
BSD層可以作為圍繞Mach層的一個外環(huán),其提供了諸如進程管理,文件系統(tǒng),和網(wǎng)絡的功能.
IOKit層為設(shè)備驅(qū)動提供了一個面向?qū)ο?C++)的一個框架.
Mach本身提供的API非常有限,而且蘋果也不鼓勵使用Mach的API,但是這些API非?；A(chǔ),如果沒有這些API的話,其他任何工作都無法實施,在Mach中,所有的東西都是通過自己的對象實現(xiàn)的, 進程,線程和虛擬內(nèi)存都被稱為"對象",和其他架構(gòu)不同,Mach的對象間不能直接調(diào)用,只能通過消息傳遞的方式實現(xiàn)對象間的通信,"消息"是Mach中最基礎(chǔ)的概念,消息在兩個端口(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()這個地方.
關(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;
- kCFRunLoopDefaultMode: App的默認Mode,通常主線程是在這個Mode下運行的.
- UITrackingRunLoopMode: 界面追蹤Mode,用于ScorllView追蹤觸摸事件,保證界面滑動時不受到其他Mode影響.
- UIInitializationRunLoopMode: 在剛啟動App時進入的第一個Mode,啟動完成后就不會再使用.
- GSEventReceiveRunLoopMode:接受系統(tǒng)事件的內(nèi)部Mode,通常用不到.
- KKCFRunLoopCommonModes:這是一個占位的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標記為待處理.
當有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_CFRunLoopObserverPV().這個函數(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 12:00這幾個時間點,RunLoop為了節(jié)省資源,并不會在非常準確的時間點回調(diào)這個Timer,Timer有個屬性叫做Tolerance(寬容度),標示了當前時間點后,容許有多少最大誤差.
如果某個時間點被錯過了,例如執(zhí)行了一個很長的任務,則那個時間點的回調(diào)也會跳過去,不會延后執(zhí)行就比如等公交,如果10:10的沒有趕上, 就只能等10:40這一趟了.
CADisplayLink是一個和屏幕刷新率一致的定時器(但實際實現(xiàn)原理更復雜,和NSTimer并不一樣,其內(nèi)部實際上是操作了一個Souce),如果在兩次屏幕刷新之間執(zhí)行了一個長任務,那其中就會有一幀被跳過去(和NSTimer類似),造成界面卡頓的感覺,在快速滑動TableView時,即使一幀的卡頓.用戶也會有所察覺,FaceBook開源的AsyncDisplayLink就是為了解決界面卡頓的問題.其內(nèi)部也用到了RunLoop.
PerformSelecter
當調(diào)用NSObject的performSelcter:afterDelay:后,實際上其內(nèi)部會創(chuàng)建一個Timer并添加到當前線程的RunLoop中, 所以如果當前的線程沒有RunLoop,則這個方法會失效.
當調(diào)用performSelctor:onThread:時,實際上其會創(chuàng)建一個Timer加到對應的線程中,同樣的.如果 對應的線程沒有RunLoop該方法也會失效.
關(guān)于GCD
實際上RunLoop底層也會用到GCD的東西,(NSTimer使用了XNU內(nèi)核的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()處理的.
關(guān)于網(wǎng)絡請求
iOS中,關(guān)于網(wǎng)絡請求的接口自下而上有如下幾層
CFSocket
CFNetwork ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession ->AFNetworking2, Alamofire
- CFSocket 是最底層的接口,只負責socket通信
- CFNetwork 是基于CFSocket等接口的上層封裝,ASIHttpRequest工作于這一層.
- NSURLConnection是基于CFNetwork的更高層的封裝,提供面向?qū)ο蟮慕涌?AFNetworking工作于這一層.
- NSURLSession 是iOS7中新增加的接口,表面上和NSURLConnection并列,但底層仍然用到了NSURLConnection的部分功能(比如com.apple.NSURLConnectionLoader線程).
AFNetworking2 和ALAmofire工作于這一層.
下面主要介紹NSURLConnection的工作過程
通常使用NSURLConnection時,你會傳入一個Deleagete,當調(diào)用[connection start]后,這個Delegate就會不停收到事件回調(diào),實際上,start這個函數(shù)的內(nèi)部會獲取CurrentRunLoop,然后在其中的DefaultMode中添加了四個source0(即需要手動觸發(fā)的Source),CFMulitiplexerSource是負責各種Delegate回調(diào)的,CFHTTPCookieStorage是處理各種Cookie的.
當開始網(wǎng)絡傳輸時,我們可以看到NSURLConnection創(chuàng)建了兩個線程:
***com.apple.NSURLConnectionLoader ***和 com.apple.CFSocket.private。其中CFSocket線程是處理底層socket連接的,NSURLConectionLoader這個線程內(nèi)部會使用RunLoop來接收底層socket的事件,并通過之前添加的Source0通知到上層的Delegate.
NSURLConnectionLoader中的RunLoop通過一些基于mach port的Source接受來自頂層CFSocket的通知,當收到通知后,其會在合適的時機向CFMultiplexerSource等Source0發(fā)送通知,同時喚醒Delegate線程的RunLoop來讓其處理這些通知,CFNultiplexerSource會在Delegate線程RunLoop對Delegate執(zhí)行實際的回調(diào).
RunLoop的實際應用舉例
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í)行任務時,AFNetworking通過調(diào)用[NSObject performSelector: onThread:]將這個任務讓盜了后臺線程的RunLoop中.
AsyncDisplayKit
AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架，其原理大致如下：
UI線程中一旦出現(xiàn)繁重的任務就會導致界面卡頓,這類任務通常分為三類:排版,繪制,UI對象操作.
排版通常包括計算視圖大小,計算文本高度,重新計算子視圖的排版等操作.繪制一般有文字繪制(例如CoreText),圖片繪制(比如預先解壓),元素繪制(Quartz)等操作.UI對象操作通常包括UIView/CALayer等UI對象的創(chuàng)建,設(shè)置屬性和銷毀.
其中前兩類操作可以通過各種方法扔到后臺線程執(zhí)行，而最后一類操作只能在主線程完成，并且有時后面的操作需要依賴前面操作的結(jié)果 （例如TextView創(chuàng)建時可能需要提前計算出文本的大?。?。ASDK 所做的，就是盡量將能放入后臺的任務放入后臺，不能的則盡量推遲 (例如視圖的創(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)時，遍歷所有之前放入隊列的待處理的任務，然后一一執(zhí)行。具體的代碼可以看這里：_ASAsyncTransactionGroup。
