RunLoop是iOS和OSX開發中非常基礎的一個概念.首先從CFRunLoop的源碼入手,介紹RunLoop的概念以及底層實現原理.還有蘋果是如何利用RunLoop實現自動釋放池,延遲回調,觸摸事件,屏幕刷新等功能.
RunLoop的概念
一般來講,一個線程一次只能執行一個任務,執行完成后線程就會退出,如果我們需要一個機制,讓先逞能隨時處理事件單兵不退出,通常的代碼邏輯是這樣的.
function loop(){
initialize();
do{
var message = get_next_message();
process_message(message);
}while(message != quit);
}
這種模型通常被稱為Event Loop.Event Loop在很多系統和框架里面都有實現,比如Node.js的事件處理,比如Windows程序的消息循環,再比如OSX/iOS的RunLoop.實現這種模型的關鍵點在于, 如何管理事件/消息,如何讓線程在沒有處理消息時休眠以避免資源占用.在有消息到來時立刻被喚醒.
所以,RunLoop實際上就是一個對象,這個對象管理了其需要處理的事件和消息,并提供了一個入口函數來執行上面Event Loop的邏輯.線程執行了這個函數后,就會一直處于這個函數內部"接受消息->等待->處理"的循環中,知道這個循環結束(比如傳入quit的消息),函數返回.
OSX/iOS系統中,提供了兩個這樣的對象:NSRunLoop和CFRunLoopRef
CFRunLoopRef是在CoreFoundation框架內的,他提供了純C函數的API,所有這些API都是線程安全的.
NSRunLoop是基于CFRunLoopRef的封裝,提供了面向對象的API,但是這些API不是線程安全的.
CFRunLoopRef的代碼是開源的,你可以在這里http://opensource.apple.com/tarballs/CF/下載到整個CoreFoundation的源碼來查看.
(Update:Swift開源后,蘋果又維護了一個跨平臺的CoreFoundation版本:https://github.com/apple/swift-corelibs-foundation/,這個版本的源碼可能和現有的iOS系統中的實現略不一樣,但更容易編譯,而且已經適配了Linux/Windows)
RunLoop與線程的關系
首先,iOS開發中能遇到兩個線程對象:pthread_t和NSThread.過去蘋果有份文檔標明了NSThread只是pthread_t的封裝,但是那份文檔已經失效了.現在他們也有可能都是直接包裝自最底層的mac thread.蘋果并沒有提供這兩個對象互相轉換的接口.但不管怎么樣,可以肯定的就是pthread_t和NSThread是一一對應的.比如你可以通過pthread_main_thread_np()或者[NSThread mainThread]來獲取主線程,也可以通過pthread_self()或者[NSthread currentThread]來獲取當前線程.CFRunLoop是基于pthread來管理的.
蘋果不允許直接創建RunLoop.她只提供了兩個自動獲取的函數:CFRunLoopGetMain()和CFRunLoopGetCurrent().這兩個函數內部的邏輯大概是下面這樣:
/// 全局的Dictionary, key是pthread_t, value 是CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 訪問loopsDic時候的鎖
static CFSpinLock_t loopsLock;
/// 獲取一個pthread對應的runloop
CFRunLoopRef _CFRunLoopGet(pthread_t thread){
OSSpinLockLock(&loopsLock);
if(!loopsDic){
///第一次進入時候,初始化全局Dic,并先為主線程創建一個RunLoop
loopsDic = CFDictionaryCreateMutable();
CFRunLoopRef mainloop = _CFRunLoopCreate();
}
CFDictionarySetValue(loopsDic,pthread_main_thread_np(),mainLoop);
/// 直接從Dictionary里獲取
CFRunLoopRef loop = CFDictionaryGetValue(loopsDic,thread));
if(!loop){
///取不到的時候,創建一個
loop = _CFRunLoopCreate();
CFDictionarySetValue(loopsDic,thread,loop);
///注冊一個回調,當線程銷毀時候,順便也銷毀其對應的RunLoop
_CFSetTSD(...,thread,loop,_CFFinalizeRunLoop);
}
OSSpinLockUnLock(&loopsLock);
return loop;
}
上面的代碼可以看出,線程和RunLoop之間是一一對應的.其關系是保存在一個全局的字典中,線程剛創建時并沒有RunLoop.如果你不主動獲取.那么他就一直不會有,RunLoop的創建是發生在第一次獲取時,RunLoop的銷毀是發生在線程結束時,你只能在一個線程的內部獲取其RunLoop(主線程除外)
RunLoop對外的接口
在CoreFoundation里面關于RunLoop有5個類.
- CFRunLoopRef
- CFRunLoopModeRef
- CFRunLoopSourceRef
- CFRunLoopTimerRef
- CFRunLoopObserverRef
其中CFRunLoopModeRef類并沒有對外暴露,只是通過CFRunLoopRef的接口進行了封裝.他們的關系如下:
RunLoop關系表
一個RunLoop包含若干個Mode,每個Mode又包含若干個Source/Timer/Observer.每次調用RunLoop主函數時,只能指定其中一個Mode,這個Mode被稱為CurrentMode.如果需要切換Mode,只能退出Loop.再重新指定一個Mode進入,這樣做主要是為了分隔開不同組的Source/Timer/Observer.讓其互不影響
CFRunLoopSourceRef是事件產生的地方.Source有兩個版本:Source()和Source1.
- Source0只包含了一個回調(函數指針).他并不能主動觸發事件.使用時,你需要先調用CFRunLoopSourceSignal(Source),將這個Source標記為待處理,然后手動調用CFRunLoopWakeUp(runloop)來喚醒RunLoop,讓其處理這個事件
- Source1包含了一個mach_port和一個回調(函數指針),被用于通過內核和其他線程相互發送消息,這種Source能主動喚醒RunLoop的線程.
***CFRunLoopTimerRef ***是基于時間的觸發器,它和NSTimer是toll-free bridged的.可以混用.其包含一個時間長度和一個回調(函數指針).當其加入到RRunLoop時,RunLoop會注冊對應的時間點,當時間點到時,RunLoop會被喚醒以執行那個回調.
CFRunLoopObserverRef是觀察者,每個Observer都包含了一個回調(函數指針),當RunLoop的狀態發生變化時,觀察者就能通過回調接收到這個變化,可以觀察的時間點有以下幾個:
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被統稱為mode item. 一個item可以被同時假如多個mode.但是一個item被重復加入同一個mode時候是不會有效果的.如果一個mode中一個item都沒有,則RunLoop會直接退出.不進入循環.
RunLoop的Mode
CFRunLoopMode和CFRunLoop的結構大體如下
struct _CFRunLoopMode{
CFStringRef name; //Mode Name 比如@"KCFRunLoopDefaultMode"
CFMutableSetRef _sources0; //Set
CFMutableSetRef _sources1; //Set
CFMutableArrayRef _observers; //Array
CFMutableArrayRef _timers; //Array
};
struct _CFRunLoop{
CFMutableSetRef _commonModes; //Set
CFMutableSetRef _CommonModeItems; //Set(Source/Timer/Observer)
CFMutableModeRef _currentMode; //Current RunLoop Mode
CFMutableSetRef _modes; //Set
};
這個有個概念叫"CommonModes":一個Mode可以將自己標記為"Common"屬性(通過將其ModeName添加到RunLoop的"CommonModes"中).每當RunLoop的內容變化時,RunLoop都會自動將_commonModeItems里的Source/Timer/Observer同步到具有"Common"標記的所有mode里面.
應用場景舉例:主線程的RunLoop里有兩個預置的Mode:KCFRunLoopDefaultMode和UITrackingRunLoopMode.這兩個Mode都已經被標注為"Common"屬性.DefaultMode 是App平時所處的狀態.TrackingRunLoopMode是追蹤ScrollView滑動時候的狀態.當你創建一個Timer并加到DefaultMode時候,Timer會得到重復回調.但此時滑動一個TableView時,RunLoop會將mode切換為TrackingRunLoopMode,這是Timer就不會被回調,并且也不會影響到滑動操作.
重點 有時候你需要一個Timer.在兩個Mode中都能得到回調.一種辦法就是將這個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來操作內部的mode.當你傳入一個新的mode name但RunLoop內部沒有對應mode時,RunLoop會自動幫你創建對應的CFRunLoopModeRef.對于一個RunLoop來說. 其內部的mode只能增加不能刪除.
蘋果公開提供的Model有兩個:KCFRunLoopDefaultMode(NSDefaultRunLoopMode)和UITrackingRunLoopMode.你可以用這兩個Mode Name來操作其對應的Mode.
同時蘋果還提供了一個操作Common標記的字符串:KCFRunLoopCommonModes(NSRunLoopCommonModes),你可以用這個字符串來操作Common Items,或者標記一個Mode為"Common".使用時注意區分這個字符串和其他mode name.
一個Mode中可以有多個Source(事件源,輸入源,基于端口事件源,例如鍵盤觸摸等),Observer(觀察者,觀察當前RunLoop運行狀態)和Timer(定時器事件源).但是必須至少有一個Source或者Timer.因為如果Mode為空,RunLoop運行到空模式不會進行空轉,就會立即退出.
系統默認注冊了5個Mode;
- KCFRunLoopDefaultMode:App默認的Mode.通常主線程是在這個Mode下運行的
- UITrackingRunLoopMode:界面追蹤Mode,用于ScrollView追蹤觸摸滑動.保證界面滑動時不受其他Mode影響.
- UIInitIalizationRunLoopMode: 在剛啟動App時進入的第一個Mode,啟動完成后就不再使用.
- GSEventReceiveRunLoopMode:接受系統事件內部Mode.通常用不到.
- KCFRunLoopCommonModes:這是一個占位用的Mode,作為標記KCFRunLoopDefaultMode 和 UITrackingRunLoopMode用.并不是一種真正的Mode.
RunLoop的內部邏輯
根據蘋果在文檔里的說明.RunLoop內部的邏輯大致如下:
其內部代碼整理如下
/// 用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的實現
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
/// 首先根據modeName找到對應mode
CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
/// 如果mode里沒有source/timer/observer, 直接返回。
if (__CFRunLoopModeIsEmpty(currentMode)) return;
/// 1. 通知 Observers: RunLoop 即將進入 loop。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);
/// 內部函數，進入loop
__CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {
Boolean sourceHandledThisLoop = NO;
int retVal = 0;
do {
/// 2. 通知 Observers: RunLoop 即將觸發 Timer 回調。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: RunLoop 即將觸發 Source0 (非port) 回調。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
/// 執行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 4. RunLoop 觸發 Source0 (非port) 回調。
sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
/// 執行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);
/// 5. 如果有 Source1 (基于port) 處于 ready 狀態，直接處理這個 Source1 然后跳轉去處理消息。
if (__Source0DidDispatchPortLastTime) {
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 到時間了，觸發這個Timer的回調。
if (msg_is_timer) {
__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
}
/// 9.2 如果有dispatch到main_queue的block，執行block。
else if (msg_is_dispatch) {
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
}
/// 9.3 如果一個 Source1 (基于port) 發出事件了，處理這個事件
else {
CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
if (sourceHandledThisLoop) {
mach_msg(reply, MACH_SEND_MSG, reply);
}
}
/// 執行加入到Loop的block
__CFRunLoopDoBlocks(runloop, currentMode);
if (sourceHandledThisLoop && stopAfterHandle) {
/// 進入loop時參數說處理完事件就返回。
retVal = kCFRunLoopRunHandledSource;
} else if (timeout) {
/// 超出傳入參數標記的超時時間了
retVal = kCFRunLoopRunTimedOut;
} else if (__CFRunLoopIsStopped(runloop)) {
/// 被外部調用者強制停止了
retVal = kCFRunLoopRunStopped;
} else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
/// source/timer/observer一個都沒有了
retVal = kCFRunLoopRunFinished;
}
/// 如果沒超時，mode里沒空，loop也沒被停止，那繼續loop。
} while (retVal == 0);
}
/// 10. 通知 Observers: RunLoop 即將退出。
__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}
可以看到,實際上RunLoop就是這樣一個函數,其內部是一個do-while循環,當你調用CFRunLoopRun()時,線程就會一直停留在這個循環中,直到超時或者被手動停止,該函數才會返回.
RunLoop的底層實現
從上面代碼可以看出,RunLoop的核心是基于mach port的.其進入休眠時候調用的函數是mach_msg(),為了解釋這個邏輯,下面稍微介紹一下OSX/iOS的系統架構.
蘋果官方將整個系統大致劃分為上述四個層次:
應用層包括用戶能接觸到的圖形應用,例如spotlight,aqua,springBoard等
應用框架層即開發人員接觸到的cocoa等框架
核心框架層包括各種核心框架,OPenGL等內容.
Darwin即操作系統的核心,包括系統內核,驅動,shell等內容.這一層是開源的. 其所有開源都可以在opensource.apple.com里面找到.
我們再深入看一下Darwin這個核心的架構:
其中在硬件層上面的三個組成部分:Mach,BSD,IOKit(還包括一些上面沒標注的內容),共同組成了XNU內核.
XNU內核的內環被稱為Mach,其作為一個微內核,僅提供了諸如處理器調度,IPC(進程間通訊)等非常少量的基礎服務.
BSD層可以作為圍繞Mach層的一個外環,其提供了諸如進程管理,文件系統,和網絡的功能.
IOKit層為設備驅動提供了一個面向對象(C++)的一個框架.
Mach本身提供的API非常有限,而且蘋果也不鼓勵使用Mach的API,但是這些API非常基礎,如果沒有這些API的話,其他任何工作都無法實施,在Mach中,所有的東西都是通過自己的對象實現的, 進程,線程和虛擬內存都被稱為"對象",和其他架構不同,Mach的對象間不能直接調用,只能通過消息傳遞的方式實現對象間的通信,"消息"是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消息實際上就是一個二進制數據包(BLOB),其中頭部定義了當前端口local_port和目標端口remote_port
發送和接受消息是通過同一個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);
為了實現消息的發送和接收,mach_msg()函數實際上是調用了一個Mach陷阱(trap),即函數mach_msg_trap(),陷阱這個概念在Mach中等同于系統調用,當你在用戶態調用mach_msg_trap()時會觸發陷阱機制,切換到內核態,內核態中內核實現的mach_msg()函數會完成實際的工作,如下圖:
這些概念可以參考維基百科:System_call、Trap_(computing)。
RunLoop的核心就是一個mach_msg()(上面代碼第7步),RunLoop調用這個函數去接收消息,如果沒有別人發送port消息過來,內核會將線程置于等待狀態,例如你在模擬器里跑起來一個iOS的app,然后再App靜止的時候點擊暫停,你會看到主線程調用棧是停留在mach_msg_trap()這個地方.
關于具體的如何利用mach port發送消息,可以看看 NSHipster 這一篇文章，或者這里的中文翻譯 。
關于Mach的歷史可以看看這篇很有趣的文章：Mac OS X 背后的故事（三）Mach 之父 Avie Tevanian。
蘋果用RunLoop實現的功能
首先我們可以看一下App啟動后RunLoop的狀態:
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),
}
}
}
可以看到,系統默認注冊了5個Mode;
- kCFRunLoopDefaultMode: App的默認Mode,通常主線程是在這個Mode下運行的.
- UITrackingRunLoopMode: 界面追蹤Mode,用于ScorllView追蹤觸摸事件,保證界面滑動時不受到其他Mode影響.
- UIInitializationRunLoopMode: 在剛啟動App時進入的第一個Mode,啟動完成后就不會再使用.
- GSEventReceiveRunLoopMode:接受系統事件的內部Mode,通常用不到.
- KKCFRunLoopCommonModes:這是一個占位的Mode,沒有實際作用
你可以在這里看到更多的蘋果內部的 Mode，但那些 Mode 在開發中就很難遇到了。
當RunLoop進行回調時,一般都是通過一個很長的函數調出去(call out),當你在你的代碼中下斷點調試時,通常能在調用棧上看到這些函數,下面是這幾個函數的整理版本,如果你在調用棧中看到這些長函數名,在這里查找一下就能定位到具體的調用地點了:
{
/// 1. 通知Observers，即將進入RunLoop
/// 此處有Observer會創建AutoreleasePool: _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
do {
/// 2. 通知 Observers: 即將觸發 Timer 回調。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
/// 3. 通知 Observers: 即將觸發 Source (非基于port的,Source0) 回調。
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 4. 觸發 Source0 (非基于port的) 回調。
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0);
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
/// 6. 通知Observers，即將進入休眠
/// 此處有Observer釋放并新建AutoreleasePool: _objc_autoreleasePoolPop(); _objc_autoreleasePoolPush();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeWaiting);
/// 7. sleep to wait msg.
mach_msg() -> mach_msg_trap();
/// 8. 通知Observers，線程被喚醒
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopAfterWaiting);
/// 9. 如果是被Timer喚醒的，回調Timer
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);
/// 9. 如果是被dispatch喚醒的，執行所有調用 dispatch_async 等方法放入main queue 的 block
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(dispatched_block);
/// 9. 如果如果Runloop是被 Source1 (基于port的) 的事件喚醒了，處理這個事件
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__(source1);
} while (...);
/// 10. 通知Observers，即將退出RunLoop
/// 此處有Observer釋放AutoreleasePool: _objc_autoreleasePoolPop();
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopExit);
}
AutoreleasePool
App啟動后,蘋果在主線程RunLoop里面注冊了兩個Observer,其回調都是_wrapRunLoopWithAutoreleasePoolHandler();
第一個Observer監視的事件是Entry(即將進入的Loop),其回調內會調用_objc_autoreleasePoolPush()創建自動釋放池,其order一直是-2147483647,優先級最高,保證創建釋放池發生在其他所有回調之前.
第二個Observer監視了兩個事件,BeforeWaiting(準備進入休眠)時候調用_objc_autoreleasePoolPop()和_objc_autoreleasePoolPush()釋放舊的池并創建新池;Exit(即將退出Loop)時調用_objc_autoreleasePoolPop()來釋放自動釋放池,這個Observer的order是2147483647,優先級最低,保證其釋放池子發生在其他所有回調之后.
在主線程執行的代碼,通常是寫在諸如事件回調,Timer回調內的,這些回調會被RunLoop創建好的AutoreleasePool環繞著,所以不會出現內存泄露.開發者也不比顯示創建Pool了
事件響應
蘋果注冊了一個Source1(基于mach port的)用來接收系統事件,其回調函數為_IOHIDEventSystemClientQueueCallback();
當一個硬件事件(觸摸/鎖屏/搖晃等)發生后,首先由IOKit.framework生成一個IOHIDEvent事件并由SpringBoard接收,這個過程的詳細情況可以參考這里。SpringBoard只接收按鍵(鎖屏/靜音等),觸摸,加速,接近傳感器等幾種Event,隨后用mach port轉發給需要的App進程,隨后蘋果注冊的那個Source1就會觸發回調,并調用_UIApplicationHandleEventQueue()進行應用內部的分發.
_UIApplicationHandleEventQueue()會把IOHIDEvent處理并包裝成UIEvent進行處理或者分發,其中包括了UIGesture/處理屏幕旋轉/發送給UIWindow等,通常事件比如UIButton點擊,touchesBegin/Move/End/Cancel事件都是在這個回調中完成的.
手勢識別
當上面的_UIApplicationHandleEventQueue()識別了一個手勢,其首先會調用Cancel將當前的touchesBegin/Move/End系列回調打斷,隨后系統將對應的UIGestureRecognizer標記為待處理.
當有UIGestureRecognizer變化(創建/銷毀/狀態改變)時,這個回調都會進行相應處理.
界面更新
當在操作UI時,比如改變了frame,更新了UIView/CALayer的層次時,或者手動調用了UIView/CALayer的setNeedsLayout/setNeedsDisPlay方法后,這個UIView/CALayer就被標記為待處理,并被提交到一個全局的容器中.
蘋果注冊了一個Observer監聽BeforeWaiting(即將進入休眠)和Exit(即將推出Loop)事件,回調去執行一個很長的函數:
_ZN2CA11Transaction17observer_callbackEP19_CFRunLoopObserverPV().這個函數里會遍歷所有待處理的UIView/CALayer以執行實際的描繪和調整.并更新UI界面.
這個函數內部的調用棧大概是這樣的.
_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為了節省資源,并不會在非常準確的時間點回調這個Timer,Timer有個屬性叫做Tolerance(寬容度),標示了當前時間點后,容許有多少最大誤差.
如果某個時間點被錯過了,例如執行了一個很長的任務,則那個時間點的回調也會跳過去,不會延后執行就比如等公交,如果10:10的沒有趕上, 就只能等10:40這一趟了.
CADisplayLink是一個和屏幕刷新率一致的定時器(但實際實現原理更復雜,和NSTimer并不一樣,其內部實際上是操作了一個Souce),如果在兩次屏幕刷新之間執行了一個長任務,那其中就會有一幀被跳過去(和NSTimer類似),造成界面卡頓的感覺,在快速滑動TableView時,即使一幀的卡頓.用戶也會有所察覺,FaceBook開源的AsyncDisplayLink就是為了解決界面卡頓的問題.其內部也用到了RunLoop.
PerformSelecter
當調用NSObject的performSelcter:afterDelay:后,實際上其內部會創建一個Timer并添加到當前線程的RunLoop中, 所以如果當前的線程沒有RunLoop,則這個方法會失效.
當調用performSelctor:onThread:時,實際上其會創建一個Timer加到對應的線程中,同樣的.如果 對應的線程沒有RunLoop該方法也會失效.
關于GCD
實際上RunLoop底層也會用到GCD的東西,(NSTimer使用了XNU內核的mk_timer驅動,并非GCD驅動),但同時GCD提供的某些接口夜用到了RunLoop,例如dispatch_async().
當調用dispatch_async(dispatch_get_main_queue(),block)時,libDispatch會向主線程的RunLoop發送消息,RunLoop會被喚醒,并從消息中取得這個block,并在回調CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里執行這個 block。但這個邏輯僅限于dispatch到主線程,dispatch到其他線程仍然是由libDispatch()處理的.
關于網絡請求
iOS中,關于網絡請求的接口自下而上有如下幾層
CFSocket
CFNetwork ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession ->AFNetworking2, Alamofire
- CFSocket 是最底層的接口,只負責socket通信
- CFNetwork 是基于CFSocket等接口的上層封裝,ASIHttpRequest工作于這一層.
- NSURLConnection是基于CFNetwork的更高層的封裝,提供面向對象的接口,AFNetworking工作于這一層.
- NSURLSession 是iOS7中新增加的接口,表面上和NSURLConnection并列,但底層仍然用到了NSURLConnection的部分功能(比如com.apple.NSURLConnectionLoader線程).
AFNetworking2 和ALAmofire工作于這一層.
下面主要介紹NSURLConnection的工作過程
通常使用NSURLConnection時,你會傳入一個Deleagete,當調用[connection start]后,這個Delegate就會不停收到事件回調,實際上,start這個函數的內部會獲取CurrentRunLoop,然后在其中的DefaultMode中添加了四個source0(即需要手動觸發的Source),CFMulitiplexerSource是負責各種Delegate回調的,CFHTTPCookieStorage是處理各種Cookie的.
當開始網絡傳輸時,我們可以看到NSURLConnection創建了兩個線程:
***com.apple.NSURLConnectionLoader ***和 com.apple.CFSocket.private。其中CFSocket線程是處理底層socket連接的,NSURLConectionLoader這個線程內部會使用RunLoop來接收底層socket的事件,并通過之前添加的Source0通知到上層的Delegate.
NSURLConnectionLoader中的RunLoop通過一些基于mach port的Source接受來自頂層CFSocket的通知,當收到通知后,其會在合適的時機向CFMultiplexerSource等Source0發送通知,同時喚醒Delegate線程的RunLoop來讓其處理這些通知,CFNultiplexerSource會在Delegate線程RunLoop對Delegate執行實際的回調.
RunLoop的實際應用舉例
AFNetworking
AFURLConnectionOperation 這個類是基于 NSURLConnection 構建的，其希望能在后臺線程接收Delegate回調,為此AFNetworking單獨創建了一個線程,并在這個線程中啟動了一個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啟動前內部必須要至少一個Timer/Observer/Source. 所以AFNetworking在[runloop run]之前先創建了一個新的NSMachPort添加進去了.通常情況下,調用者需要持有這個NSMachPort(mach_port)并在外部線程通過這個port發送消息到loop內,但此處添加port只是為了讓RunLoop不至于退出,并沒有用于實際的發送消息
- (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];
}
當需要這個后臺線程執行任務時,AFNetworking通過調用[NSObject performSelector: onThread:]將這個任務讓盜了后臺線程的RunLoop中.
AsyncDisplayKit
AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架，其原理大致如下：
UI線程中一旦出現繁重的任務就會導致界面卡頓,這類任務通常分為三類:排版,繪制,UI對象操作.
排版通常包括計算視圖大小,計算文本高度,重新計算子視圖的排版等操作.繪制一般有文字繪制(例如CoreText),圖片繪制(比如預先解壓),元素繪制(Quartz)等操作.UI對象操作通常包括UIView/CALayer等UI對象的創建,設置屬性和銷毀.
其中前兩類操作可以通過各種方法扔到后臺線程執行，而最后一類操作只能在主線程完成，并且有時后面的操作需要依賴前面操作的結果 （例如TextView創建時可能需要提前計算出文本的大小）。ASDK 所做的，就是盡量將能放入后臺的任務放入后臺，不能的則盡量推遲 (例如視圖的創建、屬性的調整)。
為此，ASDK 創建了一個名為 ASDisplayNode 的對象，并在內部封裝了 UIView/CALayer，它具有和 UIView/CALayer 相似的屬性，例如 frame、backgroundColor等。所有這些屬性都可以在后臺線程更改，開發者可以只通過 Node 來操作其內部的 UIView/CALayer，這樣就可以將排版和繪制放入了后臺線程。但是無論怎么操作，這些屬性總需要在某個時刻同步到主線程的 UIView/CALayer 去。
ASDK 仿照 QuartzCore/UIKit 框架的模式，實現了一套類似的界面更新的機制：即在主線程的 RunLoop 中添加一個 Observer，監聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件，在收到回調時，遍歷所有之前放入隊列的待處理的任務，然后一一執行。具體的代碼可以看這里：_ASAsyncTransactionGroup。
