iOS學習之深入理解RunLoop

RunLoop的定義與概念

RunLoop的主要作用

main函式中的RunLoop

RunLoop與執行緒的關係

RunLoop的訊息種類

RunLoop的對外介面

RunLoop的mode

RunLoop的內部邏輯

RunLoop在iOS中內部的應用

RunLoop在iOS開發中的實踐

總結

參考文獻

RunLoop的定義與概念

顧名思義 RunLoop，就是一個在Run的loop，就是一個一直在跑的圈。其本質就是無休止的while迴圈。一般的程式都是執行完任務後便結束。但由於手機應用的特殊性，在其不執行任務時，也不能將其殺死，而是暫時休眠狀態，直到有外部或內部因素將其喚醒，繼續run。直到使用者手動將該程式徹底關閉。
這種模型通常被稱作 Event Loop。 Event Loop 在很多系統和框架裡都有實現，比如 Node.js 的事件處理，比如 Windows 程式的訊息迴圈，再比如 OSX/iOS 裡的 RunLoop。實現這種模型的關鍵點在於：如何管理事件/訊息，如何讓執行緒在沒有處理訊息時休眠以避免資源佔用、在有訊息到來時立刻被喚醒。
RunLoop 實際上就是一個物件，這個物件管理了其需要處理的事件和訊息，並提供了一個入口函式來執行上面 Event Loop 的邏輯。執行緒執行了這個函式後，就會一直處於這個函式內部 “接受訊息->等待->處理” 的迴圈中，直到這個迴圈結束（比如傳入 quit 的訊息），函式返回。
程式例程如下：

	// 無Runloop，程式執行完後，直接返回
int main(int argc,char * argv[]){
 	 	NSLog(@"execute main function");---->程式開始
  		return 0; ------------------------->程式結束
}
// 有Runloop
int main(int argc,char * argv[]){
		BOOL running = YES; -------->程式開始
		do {------------------------------
   	// 執行各種任務，處理各種事件------持續執行
		}while(running);---------------------
	    return 0;
}

複製程式碼

OSX/iOS 系統中，提供了兩個這樣的物件：NSRunLoop 和 CFRunLoopRef。
- CFRunLoopRef 是在 CoreFoundation 框架內的，它提供了純 C 函式的 API，所有這些 API 都是執行緒安全的。
- NSRunLoop 是基於 CFRunLoopRef 的封裝，提供了物件導向的 API，但是這些 API 不是執行緒安全的。

RunLoop的主要作用

使程式一直執行並接收使用者的輸入
決定程式在何時處理哪些事件
呼叫解耦（主調方產生很多事件，不用等到被調方處理完事件之後，才能執行其他操作）
節省CPU時間（當程式啟動後，什麼都沒有執行的話，就不用讓CPU來消耗資源來執行，直接進入睡眠狀態）

main函式中的RunLoop

由於手機應用的特殊性，所以在iOS程式中，main 函式內部也啟動了一個RunLoop
程式如下

int main(int argc, char * argv[]) {
  @autoreleasepool {
      return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
  }
}
複製程式碼

其中 UIApplicationMain 函式內部幫我們開啟了主執行緒的 RunLoop ， UIApplicationMain 內部擁有一個無線迴圈的程式碼。這個 UIApplicationMain 函式幫我們啟動的 RunLoop 屬於程式的主執行緒所有，所以我們不需要再為主執行緒開啟 RunLoop。由於我們的程式在主執行緒上擁有一個 RunLoop ，所以我們將程式開啟後，執行完它所需要的任務後，不一定非要退出程式，而是可以選擇將其後臺掛起。一切都是因為主執行緒上RunLoop 的關係，我們的程式才可以長時間持續執行。

RunLoop與執行緒的關係

RunLoop 與執行緒可以說是一一對應的關係。但是不一定一定是一對一，有可能是0對1。因為只有在主執行緒中，我們的iOS程式幫助我們開啟了 RunLoop。而在我們自己定義或系統幫我們開啟的子執行緒中，如果我們不顯式的“建立” RunLoop ,我們的子執行緒就沒有Runloop。這裡所謂的“建立”，並不是直接建立 RunLoop ，而是通過呼叫獲取 RunLoop 的方法來完成 RunLoop 的建立，因為在 RunLoop 的內部，實際上是通過懶載入方法建立的。這也是我們如果不呼叫 獲取 方法，就不會獲得 RunLoop 的原因。
RunLoop 的建立是發生在第一次獲取時，RunLoop 的銷燬是發生線上程結束時。你只能在一個執行緒的內部獲取其 RunLoop（主執行緒除外）。
獲取 Runloop 的方法如下：
- 在 Core Foundation 中
  - CFRunLoopGetMain() // 獲取主執行緒的Runloop
  - CFRunLoopGetCurrent() // 獲取當前執行緒的Runloop
- 在 Cocoa 中
  - [NSRunLoop currentRunLoop]
- CFRunLoopRef 和 NSRunLoop 可以轉化, NSRunLoop 使用 getCFRunLoop方法就可以得到 CFRunLoopRef 物件
示例程式碼如下：

/// 全域性的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;
}
CFRunLoopRef CFRunLoopGetMain() {
    return _CFRunLoopGet(pthread_main_thread_np());
}
 
CFRunLoopRef CFRunLoopGetCurrent() {
    return _CFRunLoopGet(pthread_self());
}
複製程式碼

由程式碼可以看出，RunLoop 實際上是由字典來進行儲存的，這也更加印證了 RunLoop 與執行緒之間一一對應的關係。

RunLoop的訊息種類

這是apple官方文件的一張圖, 表示了Runloop的訊息種類。
這張圖我也沒有特別看懂，主要是講的Runloop的兩種輸入源。官方文件的解釋是
- InputSources : 用來投遞非同步訊息,通常訊息來自另外的執行緒或者程式.在接受到訊息並呼叫指定的方法時,執行緒對應的 NSRunLoop 物件會通過執行 runUntilDate:方法來退出.
- Timer Source: 用來投遞 timer 事件(Schedule 或者 Repeat)中的同步訊息.在訊息處理時,並不會退出 RunLoop. RunLoop 除了處理以上兩種 Input Soruce,它也會在執行過程中生成不同的 notifications,標識 runloop 所處的狀態,因此可以給 RunLoop 註冊觀察者 Observer,以便監控 RunLoop 的執行過程,並在 RunLoop 進入某些狀態時候進行相應的操作, Apple 只提供了 Core Foundation 的 API來給 RunLoop 註冊觀察者Observer.

RunLoop的對外介面

在 CoreFoundation 裡面關於 RunLoop 有5個類:
- CFRunLoopRef
- CFRunLoopModeRef
- CFRunLoopSourceRef
- CFRunLoopTimerRef
- CFRunLoopObserverRef
其中 CFRunLoopModeRef 類並沒有對外暴露，只是通過 CFRunLoopRef 的介面進行了封裝。他們的關係如下:
由圖片可以看出，一個 Runloop 中，含有數個 mode ，而其中每個 mode 又包含數個 source， observer， timer。每次呼叫 RunLoop 的主函式時，只能指定其中一個 Mode，這個Mode被稱作 CurrentMode。如果需要切換 Mode，只能退出 Loop，再重新指定一個 Mode 進入。這樣做主要是為了分隔開不同組的 Source/Timer/Observer，讓其互不影響。
在這裡需要注意的是，在輔助執行緒啟動 runloop 之前, 你必須至少在其中新增一個 input source 或者 timer（詳見第三章 Runloop的訊息種類）. 如果一個 runloop 中沒有一個事件源sources, runloop 會在你啟動它以後立即退出.
在新增了 source 以後,你可以給 runloop 新增 observers 來監測 runloop 的不同的執行的狀態.為了加入 observer, 你應該建立一個 CFRunLoopObserverRef,使用 CFRunLoopAddObserver 函式新增 observer 到你的 runloop.
下面來具體介紹 Runloop 對外提供的這幾種介面
- CFRunLoopSourceRef 是事件產生的地方。Source有兩個版本：Source0 和 Source1。
  - Source0 只包含了一個回撥（函式指標），它並不能主動觸發事件。使用時，你需要先呼叫 CFRunLoopSourceSignal(source)，將這個 Source 標記為待處理，然後手動呼叫 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop，讓其處理這個事件。
  - Source1 包含了一個 mach_port（很重要的概念）和一個回撥（函式指標），被用於通過核心和其他執行緒相互傳送訊息。這種 Source 能主動喚醒 RunLoop 的執行緒，具體的請看下面的程式碼。
- CFRunLoopTimerRef 是基於時間的觸發器，它和 NSTimer 是toll-free bridged 的，可以混用。其包含一個時間長度和一個回撥（函式指標）。當其加入到 RunLoop 時，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), // 即將進入休眠 32
    kCFRunLoopAfterWaiting  = (1UL << 6), // 剛從休眠中喚醒 64
    kCFRunLoopExit          = (1UL << 7), // 即將退出Loop 128
};
複製程式碼

上面的 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/Observer/Timer>
    CFRunLoopModeRef _currentMode;    // Current Runloop Mode
    CFMutableSetRef _modes;           // Set
    ...
};

複製程式碼

系統預設註冊了5個Mode:
1. kCFRunLoopDefaultMode: App的預設 Mode，通常主執行緒是在這個 Mode 下執行的。
2. UITrackingRunLoopMode: 介面跟蹤 Mode，用於 ScrollView 追蹤觸控滑動，保證介面滑動時不受其他 Mode 影響。
3. UIInitializationRunLoopMode: 在剛啟動 App 時第進入的第一個 Mode，啟動完成後就不再使用。
4. GSEventReceiveRunLoopMode: 接受系統事件的內部 Mode，通常用不到。
5. kCFRunLoopCommonModes: 這是一個佔位的 Mode，沒有實際作用。
我們平時主要應用的 mode 有 kCFRunLoopDefaultMode 和 UITrackingRunLoopMode 兩種，其中 kCFRunLoopDefaultMode(在cocoa中也叫NSDefaultRunLoopMode)是我們開啟一個 RunLoop 時預設的 mode 方式。而 UITrackingRunLoopMode 主要是追蹤 ScrollView 滑動時的狀態。
這裡有個概念叫 “CommonModes”：一個 Mode 可以將自己標記為”Common”屬性（通過將其 ModeName 新增到 RunLoop 的 “commonModes” 中）。每當 RunLoop 的內容發生變化時，RunLoop 都會自動將 _commonModeItems 裡的 Source/Observer/Timer 同步到具有 “Common” 標記的所有Mode裡。需要注意的是： “CommonModes”並不是一個真正的 mode ，它實際上是一個陣列裡面放入了 kCFRunLoopDefaultMode 和 UITrackingRunLoopMode
應用場景舉例：主執行緒的 RunLoop 裡有兩個預置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。這兩個 Mode 都已經被標記為”Common”屬性。DefaultMode 是 App 平時所處的狀態，UITrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態。當你建立一個 Timer 並加到 DefaultMode 時，Timer 會得到重複回撥，但此時滑動一個TableView時，RunLoop 會將 mode 切換為 UITrackingRunLoopMode，這時 Timer 就不會被回撥，並且也不會影響到滑動操作。有時你需要一個 Timer，在兩個 Mode 中都能得到回撥，一種辦法就是將這個 Timer 分別加入這兩個 Mode。還有一種方式，就是將 Timer 加入到頂層的 RunLoop 的 “commonModeItems” 中。”commonModeItems” 被 RunLoop 自動更新到所有具有”Common”屬性的 Mode 裡去。
CFRunLoop對外暴露的管理 Mode 介面只有下面2個:

CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);
複製程式碼

Mode 暴露的管理 mode item 的介面有下面幾個

CFRunLoopAddSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopAddObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopAddTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
CFRunLoopRemoveSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopRemoveObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopRemoveTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
複製程式碼

你只能通過 mode name 來操作內部的 mode，當你傳入一個新的 mode name 但 RunLoop 內部沒有對應 mode 時，RunLoop會自動幫你建立對應的 CFRunLoopModeRef。對於一個 RunLoop 來說，其內部的 mode 只能增加不能刪除。

RunLoop的內部邏輯

先放一張我認為非常好的圖,其中還是有些錯誤之處，根據官方文件，第7步：休眠，等待喚醒的source種類應該是source1，而不是source0。
內部程式碼實現如下如果嫌太長，直接看註釋即可。

/// 用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);
}

複製程式碼

可以注意到，在這段程式碼在第5步，跳轉到第9步執行source1的事件時，使用了 goto 語句，可見，專注底層的大神就是跟我們普通人不一樣啊哈哈哈。
實際上 RunLoop 就是這樣一個函式，其內部是一個 do-while 迴圈。當你呼叫 CFRunLoopRun() 時，執行緒就會一直停留在這個迴圈裡；直到超時或被手動停止，該函式才會返回。
RunLoop 的核心就是一個 mach_msg() (見上面程式碼的第7步)，RunLoop 呼叫這個函式去接收訊息，如果沒有別人傳送 port 訊息過來，核心會將執行緒置於等待狀態。例如你在模擬器裡跑起一個 iOS 的 App，然後在 App 靜止時點選暫停，你會看到主執行緒呼叫棧是停留在 mach_msg_trap() 這個地方。
為了實現訊息的傳送和接收，mach_msg() 函式實際上是呼叫了一個 Mach 陷阱 (trap)，即函式mach_msg_trap()，陷阱這個概念在 Mach 中等同於系統呼叫。當你在使用者態呼叫 mach_msg_trap() 時會觸發陷阱機制，切換到核心態；核心態中核心實現的 mach_msg() 函式會完成實際的工作，如下圖：

RunLoop在iOS中內部的應用

當 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 事件都是在這個回撥中完成的。
需要注意的是基於UI的事件響應，都是屬於 source1 的，雖然列印資訊棧時，顯示的是 source0 ，但實際上，首先是由Source1 接收 IOHIDEvent ，之後在回撥 __IOHIDEventSystemClientQueueCallback() 內觸發的 Source0，Source0 再觸發的 _UIApplicationHandleEventQueue()。所以 UIButton 事件看到是在 Source0 內的。

手勢識別

當上面的_UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會呼叫 Cancel 將當前的 touchesBegin/Move/End 系列回撥打斷。隨後系統將對應的 UIGestureRecognizer 標記為待處理。蘋果註冊了一個 Observer 監測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回撥函式是 _UIGestureRecognizerUpdateObserver()，其內部會獲取所有剛被標記為待處理的 GestureRecognizer，並執行GestureRecognizer的回撥。當有 UIGestureRecognizer 的變化(建立/銷燬/狀態改變)時，這個回撥都會進行相應處理。

介面更新

當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動呼叫了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法後，這個 UIView/CALayer 就被標記為待處理，並被提交到一個全域性的容器去。
蘋果註冊了一個 Observer 監聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回撥去執行一個很長的函式： _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函式裡會遍歷所有待處理的 UIView/CAlayer 以執行實際的繪製和調整，並更新 UI 介面。

定時器

NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 註冊到 RunLoop 後，RunLoop 會為其重複的時間點註冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節省資源，並不會在非常準確的時間點回撥這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到後，容許有多少最大誤差。
如果某個時間點被錯過了，例如執行了一個很長的任務，則那個時間點的回撥也會跳過去，不會延後執行。就比如等公交，如果 10:10 時我忙著玩手機錯過了那個點的公交，那我只能等 10:20 這一趟了。
CADisplayLink 是一個和螢幕重新整理率一致的定時器（但實際實現原理更復雜，和 NSTimer 並不一樣，其內部實際是操作了一個 Source）。如果在兩次螢幕重新整理之間執行了一個長任務，那其中就會有一幀被跳過去（和 NSTimer 相似），造成介面卡頓的感覺。在快速滑動TableView時，即使一幀的卡頓也會讓使用者有所察覺。

PerformSelecter

當呼叫 NSObject 的 performSelecter:afterDelay: 後，實際上其內部會建立一個 Timer 並新增到當前執行緒的 RunLoop 中。所以如果當前執行緒沒有 RunLoop，則這個方法會失效。
當呼叫 performSelector:onThread: 時，實際上其會建立一個 Timer 加到對應的執行緒去，同樣的，如果對應執行緒沒有 RunLoop 該方法也會失效。

關於GCD

GCD 本身與 RunLoop 是屬於平級的關係。他們誰也不包含誰，但是他們之間存在著協作的關係。
當呼叫 dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主執行緒的 RunLoop 傳送訊息，RunLoop會被喚醒，並從訊息中取得這個 block，並在回撥 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 裡執行這個 block。但這個邏輯僅限於 dispatch 到主執行緒，dispatch 到其他執行緒仍然是由 libDispatch 處理的。

Runloop在iOS開發中的實踐

AFNetworking

這裡有一個已經被將爛了的例子，即 AFNetworking 內部的 AFURLConnectionOperation 類，使用 RunLoop 來保持“長連線”，目的是為了讓 RunLoop 不至於退出，並沒有用於實際的傳送訊息。因為RunLoop 啟動前內部必須要有至少一個 Timer/Observer/Source，所以 AFNetworking 在 [runLoop run] 之前先建立了一個新的 NSMachPort 新增進去了。
程式碼如下：

+ (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;
}
複製程式碼

這裡有一個坑，是否 AFNetworking 這樣做了，我們就可以跟著這樣做來保持回撥的 “長連線” 呢？答案是否定的。

AsyncDisplayKit

UI 執行緒中一旦出現繁重的任務就會導致介面卡頓，這類任務通常分為3類：排版，繪製，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。

ImageView推遲顯示

利用PerformSelector設定當前執行緒的RunLoop的執行模式

[self.imageView performSelector:@selector(setImage:) withObject:[UIImage imageNamed:@"tupian"] afterDelay:4.0 inModes:NSDefaultRunLoopMode];

複製程式碼

後臺常駐執行緒（很常用）

解釋上述 AFNetworking 長時間連線問題。
方法1即 AFNetworking 中使用的方法，它使得 thread 在開啟後，使用結束方法CFRunLoopStop(CFRunLoopGetCurrent())並沒有正常結束，該結束方法對這個建立 Thread 的方式無效。所以導致了記憶體暴增，圖如下

方法2 如圖，由於它是一個非執行緒阻塞的方法，所以有時線上程還已經退出後，才開始暫停這個執行緒，自然會使得程式崩潰。
方法3 才是我推薦的方法，它可以正確的建立一個後臺常駐執行緒。
- 執行結果如下
下面解釋一下原理吧
- CFRunLoopStop() 方法只會結束當前的 runMode:beforeDate: 呼叫，而不會結束後續的呼叫。
- 而我們所知道，系統所謂的 run() 方法，實際上就是在內部不斷地呼叫runMode:beforeDate:方法，而所謂的runUntilDate:方法，也是有限的呼叫runMode:beforeDate:方法。只是它們所傳的引數都是DefaultMode罷了。
- 而正常結束一個 RunLoop 的方法只有兩種
  - 設定超時時間
  - 使用CFRunLoopStop()方法手動將 RunLoop 結束。
- 一般我們使用設定超時時間即可，但是在網路傳輸中，我們想達到的目標就是在精準的時間點結束 RunLoop，所以我們需要使用CFRunLoopStop()方法手動將 RunLoop 結束。
- 而CFRunLoopStop()方法的定義中說了。
The difference is that you can use this technique on run loops you started unconditionally.
- 官方文件在 run 方法的定義中則說
If you want the run loop to terminate, you shouldn't use this method
- 這也就表示了，如果還想從 RunLoop 中退出，就不能使用 run 方法來 run 一個 loop。
- 並且重要的是， CFRunLoopStop() 方法只會結束當前的 runMode:beforeDate: 呼叫，而不會結束後續的呼叫。這也就是為什麼 Runloop 的文件中說CFRunLoopStop() 可以 exit(退出) 一個 RunLoop，而在 run 等方法的文件中又說這樣會導致 RunLoop 無法 terminate(終結)。

總結

以前對 RunLoop 可以說是一竅不通，只知道有這麼個名詞，在實際的程式設計中，也從來沒有使用過，一直都想深入研究一下，索性這兩天比較用時間，就花了兩天時間找了大量的資料來理解，總結 RunLoop，在這個過程中難免會有很多疏漏，也請有緣看到這篇文章的你們不吝賜教。謝謝O(∩_∩)O~

iOS學習之深入理解RunLoop

RunLoop的定義與概念

RunLoop的主要作用

main函式中的RunLoop

RunLoop與執行緒的關係

RunLoop的訊息種類

RunLoop的對外介面

RunLoop的mode

RunLoop的內部邏輯

RunLoop在iOS中內部的應用

AutoreleasePool （非常重要）

事件響應

手勢識別

介面更新

定時器

PerformSelecter

關於GCD

Runloop在iOS開發中的實踐

AFNetworking

AsyncDisplayKit

ImageView推遲顯示

後臺常駐執行緒（很常用）

總結

參考文獻

相關文章