iOS學習之深入理解RunLoop

_silhouette發表於2017-12-25
原文網址 : https://juejin.im/post/5a352c6c5188251fbd33b345
iOSOOP

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的訊息種類

  • 這張圖我也沒有特別看懂，主要是講的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的包含元素
  • 由圖片可以看出，一個 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。

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

複製程式碼
  • 可以注意到，在這段程式碼在第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() 函式會完成實際的工作，如下圖：
    image

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 的方式無效。所以導致了記憶體暴增，圖如下

    image

image

  • 方法2 如圖，由於它是一個非執行緒阻塞的方法，所以有時線上程還已經退出後，才開始暫停這個執行緒，自然會使得程式崩潰。

    image

  • 方法3 才是我推薦的方法 ，它可以正確的建立一個後臺常駐執行緒。

    image

    • 執行結果如下
      image

  • 下面解釋一下原理吧

    • 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~

參考文獻

相關文章