原文

RunLoop，顧名思義就是跑圈，相信每個iOS開發者都聽聞過，但是好多人都是一知半解，毋庸置疑，RunLoop是iOS進階過程中不可逃避的一個坎，面試的時候也遇到過不少相關問題吧，所以咯，逃不出的圈子 -- RunLoop

問題

• 當scroll滑動時，同頁面上的定時器為什麼會暫停？

• 怎麼在tableview滑動時延遲加載圖片來提高流暢度？

• 常說的AFNetworking常駐線程保活是什麼原理？

基本概念

其實上述問題都與RunLoop有關系，要想弄清楚其中的原因，就需要理解RunLoop到底是什麼？

RunLoop：讓線程能隨時處理事件但並不退出的一種機制

我們知道每個程序的入口都是main函數：

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

就這麼幾行代碼，可是不應該是代碼執行完後程序就結束了嗎？那我們見到的程序是怎麼能長時間保持在活躍狀態的？這一切都是RunLoop的功勞，其實UIApplicationMain()會創建主線程，主線程內部會主動開啟一個RunLoop，而RunLoop本質上就是一個do-while循環，只要條件滿足，就會不停的循環，進而程序一直保持運行的狀態。RunLoop源碼：

void CFRunLoopRun(void) {    /* DOES CALLOUT */
    int32_t result;
    do {
        result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
        CHECK_FOR_FORK();
    } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
}

原來程序是這樣子一直運行的呀，一直單純這樣循環是不是會影響性能？所以RunLoop在這機制的關鍵在於：如何管理事件/消息，如何讓線程在沒有處理消息時休眠以避免資源占用、在有消息到來時立刻被喚醒

要了解這種機制，我們只有進一步分析源代碼了。我們先看看RunLoop相關的API：

• CFRunLoopRef：CoreFoundation 框架內的，基於C語言

• NSRunLoop：基於CFRunLoopRef的進一步封裝，提供了面向對象的 API

所以我們下面都是基於對CFRunLoopRef的源碼分析，在 CoreFoundation 裡面關於 RunLoop 有5個類:

CFRunLoopRef //就是RunLoop，提供CFRunLoopGetMain()和CFRunLoopGetCurrent()
CFRunLoopModeRef //RunLoop運行模式
CFRunLoopSourceRef //RunLoop裡面內容 -- 事件源，輸入源
CFRunLoopTimerRef //RunLoop裡面內容 -- 定時器
CFRunLoopObserverRef //RunLoop裡面內容 -- 觀察者

上面是RunLoop的結構圖，可以看出，一個RunLoop裡面可以有多個mode，每個mode又可以多個source，observer，timer。**可是每次RunLoop只能指定一個mode運行，如果想要切換mode，就必須先退出RunLoop，然後重新指定mode運行，這樣做的目的就是避免mode之間相互影響**

CFRunLoopModeRef

創建RunLoop時，系統默認注冊了五種mode：

1. kCFRunLoopDefaultMode: 默認 mode，通常主線程在這個 mode 下運行
2. UITrackingRunLoopMode: 追蹤mode，保證Scrollview滑動順暢不受其他 mode 影響
3. UIInitializationRunLoopMode: 啟動程序後的過渡mode，啟動完成後就不再使用
4: GSEventReceiveRunLoopMode: Graphic相關事件的mode，通常用不到
5: kCFRunLoopCommonModes: 占位用的mode，作為標記kCFRunLoopDefaultMode和UITrackingRunLoopMode用

當scroll滑動時，同頁面上的定時器為什麼會暫停？

這個問題在這裡就能得到解釋了，當你用

func scheduledTimer(withTimeInterval interval: TimeInterval, repeats: Bool, block: @escaping (Timer) -> Swift.Void) -> Timer

創建一個timer時，系統默認把timer添加到kCFRunLoopDefaultMode模式中，但是當頁面滾動的時候，RunLoop的Mode會自動切換成UITrackingRunLoopMode模式，因此timer失效，當停止滑動，RunLoop又會切換回NSDefaultRunLoopMode模式，因此timer又會重新啟動了。

kCFRunLoopCommonModes的存在就是來解決這個問題的，RunLoop運行時，會把kCFRunLoopCommonModes中的資源下發到每一個NSDefaultRunLoopMode和UITrackingRunLoopMode中，所以

let timer = Timer.init(timeInterval: 1, repeats: true) { }
RunLoop.main.add(timer, forMode: .commonModes)

怎麼在tableview滑動時延遲加載圖片來提高流暢度？

這個問題也是同理，把加載圖片放入NSDefaultRunLoopMode模式中就可以避免了：

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

CFRunLoopSourceRef

事件產生的地方，分為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), // 即將進入休眠
    kCFRunLoopAfterWaiting  = (1UL << 6), // 剛從休眠中喚醒
    kCFRunLoopExit          = (1UL << 7), // 即將退出Loop
};

其中最重要就是，休眠與喚醒之間的切換，核心代碼：

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

具體流程表現為下圖：

看到有些人指出圖中第七步中，Source0應該改為Source1，因為只有Source1能主動喚醒RunLoop，但是這裡沒有強調是主動喚醒，Source0也可以通過手動來喚醒。而且這裡Source0後面有標注基於port，猜測這種Source0可能是基於port 的Source1分發出來的。

RunLoop 的核心就是一個 mach_msg()，當一個RunLoop處理完事件後，即將進入休眠時，會經歷下面幾步：

1. 指定一個將來喚醒自己的mach_port端口

2. 調用mach_msg來監聽這個端口，保持mach_msg_trap狀態

3. 由另一個線程（比如有可能有一個專門處理鍵盤輸入事件的loop在後台一直運行）向內核發送這個端口的msg後，mach_msg_trap狀態被喚醒，RunLoop繼續運行

mach相關方法涉及到內核，這裡不做深入。

常說的AFNetworking常駐線程保活是什麼原理？

我們知道，當子線程中的任務執行完畢之後就被銷毀了，那麼如果我們需要開啟一個子線程，在程序運行過程中永遠都存在，那麼我們就會面臨一個問題，如何讓子線程永遠活著，答案就是給子線程開啟一個RunLoop，下面是AFNetworking相關源碼：

+ (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/Source，所以 AFNetworking 在 [runLoop run] 之前先創建了一個新的 NSMachPort 添加進去了。通常情況下，調用者需要持有這個 NSMachPort (mach_port) 並在外部線程通過這個 port 發送消息到 loop 內；但此處添加 port 只是為了讓 RunLoop 不至於退出，並沒有用於實際的發送消息。

ps.RunLoop 啟動前內部就算有一個observer也是會返回的。源代碼：

__CFRunLoopModeIsEmpty
{
if (NULL != rlm->_sources0 && 0 _sources0)) return false;
if (NULL != rlm->_sources1 && 0 _sources1)) return false;
if (NULL != rlm->_timers && 0 _timers)) return false;
}

注意點

• AutoreleasePool

App啟動後，蘋果在主線程 RunLoop 裡注冊了兩個 Observer：

第一個 Observer 監視的事件是 Entry(即將進入Loop)，其回調內會調用 _objc_autoreleasePoolPush() 創建自動釋放池。其 order 是-2147483647，優先級最高，保證創建釋放池發生在其他所有回調之前。

第二個 Observer 監視了兩個事件： BeforeWaiting(准備進入休眠) 時調用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池並創建新池；Exit(即將退出Loop) 時調用 _objc_autoreleasePoolPop() 來釋放自動釋放池。這個 Observer 的 order 是 2147483647，優先級最低，保證其釋放池子發生在其他所有回調之後。

在主線程執行的代碼，通常是寫在諸如事件回調、Timer回調內的。這些回調會被 RunLoop 創建好的 AutoreleasePool 環繞著，所以不會出現內存洩漏，開發者也不必顯示創建 Pool 了

• GCD

GCD與RunLoop是平級合作關系，GCD的timer跟RunLoop沒關系，只是調用點在RunLoop上，需要注意的是，GCD中的dispatch到mainqueue的block被分發到RunLoop.main執行

• 事件響應

當一個事件(觸摸/鎖屏/搖晃等)發生後，首先由 SpringBoard 接收，隨後用 mach port 轉發給需要的App進程，從而觸發進程的Source1 （基於 mach port ，提前注冊用來接收系統事件的Source）的回調_UIApplicationHandleEventQueue()，把事件包裝成 UIEvent 進行處理或分發（之後的事件分發處理，可以看[從用戶點擊屏幕到程序作出反應之間都發生了什麼？ --- iOS事件響應](http://www.jianshu.com/p/6ff87b3ab2cb)）。通常事件比如 UIButton 點擊、touchesBegin/Move/End/Cancel 事件都是在這個回調中完成的

這裡有一點值得注意，當我們點擊一個按鈕後，進行斷點調試可以發現調用的函數棧裡顯示的是Source0:

原因：首先是由那個Source1 接收事件，之後在回調內觸發的 Source0，Source0 再觸發的 _UIApplicationHandleEventQueue()進行事件分發和處理。所以UIButton事件看到是在 Source0 內的。

• 線程

RunLoop的寄生於線程：一個線程只能有唯一對應的RunLoop，但這個根RunLoop裡可以嵌套子RunLoop，主線程的RunLoop自動創建，子線程的RunLoop默認不創建，在子線程中調用NSRunLoop.current獲取RunLoop對象的時候，就會創建RunLoop

• 界面刷新

當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動調用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法後，這個 UIView/CALayer 就被標記為待處理，並被提交到一個全局的容器去。蘋果注冊了一個 Observer 監聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調去執行一個很長的函數：

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數裡會遍歷所有待處理的 UIView/CAlayer 以執行實際的繪制和調整，並更新 UI 界面。

參考：

• 深入理解RunLoop

• iOS線下分享《RunLoop》by 孫源@sunnyxx