本文大量參考YY大神的深入理解RunLoop歧斟，整理了一下思路，化繁為簡偏形，僅作為學(xué)習(xí)資料整理静袖。

RunLoop，顧名思義就是跑圈俊扭，相信每個(gè)iOS開發(fā)者都聽聞過队橙，但是好多人都是一知半解，毋庸置疑萨惑，RunLoop是iOS進(jìn)階過程中不可逃避的一個(gè)坎捐康，面試的時(shí)候也遇到過不少相關(guān)問題吧，所以咯咒钟，逃不出的圈子 -- RunLoop

問題

• 當(dāng)scroll滑動(dòng)時(shí)吹由，同頁面上的定時(shí)器為什么會(huì)暫停咒林？
• 怎么在tableview滑動(dòng)時(shí)延遲加載圖片來提高流暢度僵井？
• 常說的AFNetworking常駐線程焙瞿酰活是什么原理噪珊？
  ...

基本概念

其實(shí)上述問題都與RunLoop有關(guān)系手趣，要想弄清楚其中的原因耐床，就需要理解RunLoop到底是什么雷逆？

RunLoop：讓線程能隨時(shí)處理事件但并不退出的一種機(jī)制

我們知道每個(gè)程序的入口都是main函數(shù)：

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

就這么幾行代碼尾组，可是不應(yīng)該是代碼執(zhí)行完后程序就結(jié)束了嗎壤追？那我們見到的程序是怎么能長時(shí)間保持在活躍狀態(tài)的磕道？這一切都是RunLoop的功勞，其實(shí)UIApplicationMain()會(huì)創(chuàng)建主線程行冰，主線程內(nèi)部會(huì)主動(dòng)開啟一個(gè)RunLoop溺蕉，而RunLoop本質(zhì)上就是一個(gè)do-while循環(huán)，只要條件滿足悼做，就會(huì)不停的循環(huán)疯特，進(jìn)而程序一直保持運(yùn)行的狀態(tài)。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);
}

原來程序是這樣子一直運(yùn)行的呀肛走，一直單純這樣循環(huán)是不是會(huì)影響性能漓雅？所以RunLoop在這機(jī)制的關(guān)鍵在于：如何管理事件/消息，如何讓線程在沒有處理消息時(shí)休眠以避免資源占用、在有消息到來時(shí)立刻被喚醒

要了解這種機(jī)制邻吞，我們只有進(jìn)一步分析源代碼了组题。我們先看看RunLoop相關(guān)的API：

• CFRunLoopRef：CoreFoundation 框架內(nèi)的，基于C語言
• NSRunLoop：基于CFRunLoopRef的進(jìn)一步封裝抱冷，提供了面向?qū)ο蟮?API

所以我們下面都是基于對(duì)CFRunLoopRef的源碼分析崔列，在 CoreFoundation 里面關(guān)于 RunLoop 有5個(gè)類:

CFRunLoopRef //就是RunLoop，提供CFRunLoopGetMain()和CFRunLoopGetCurrent()
CFRunLoopModeRef //RunLoop運(yùn)行模式
CFRunLoopSourceRef //RunLoop里面內(nèi)容 -- 事件源徘层，輸入源
CFRunLoopTimerRef //RunLoop里面內(nèi)容 -- 定時(shí)器
CFRunLoopObserverRef //RunLoop里面內(nèi)容 -- 觀察者

RunLoop_0.png

CFRunLoopModeRef

創(chuàng)建RunLoop時(shí)桶癣，系統(tǒng)默認(rèn)注冊(cè)了五種mode：

1. kCFRunLoopDefaultMode: 默認(rèn) mode拥褂，通常主線程在這個(gè) mode 下運(yùn)行
2. UITrackingRunLoopMode: 追蹤mode，保證Scrollview滑動(dòng)順暢不受其他 mode 影響
3. UIInitializationRunLoopMode: 啟動(dòng)程序后的過渡mode牙寞，啟動(dòng)完成后就不再使用
4: GSEventReceiveRunLoopMode: Graphic相關(guān)事件的mode饺鹃，通常用不到
5: kCFRunLoopCommonModes: 占位用的mode，作為標(biāo)記kCFRunLoopDefaultMode和UITrackingRunLoopMode用

當(dāng)scroll滑動(dòng)時(shí)间雀，同頁面上的定時(shí)器為什么會(huì)暫停悔详？

這個(gè)問題在這里就能得到解釋了，當(dāng)你用

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

創(chuàng)建一個(gè)timer時(shí)惹挟，系統(tǒng)默認(rèn)把timer添加到kCFRunLoopDefaultMode模式中茄螃，但是當(dāng)頁面滾動(dòng)的時(shí)候，RunLoop的Mode會(huì)自動(dòng)切換成UITrackingRunLoopMode模式连锯，因此timer失效归苍，當(dāng)停止滑動(dòng)，RunLoop又會(huì)切換回NSDefaultRunLoopMode模式运怖，因此timer又會(huì)重新啟動(dòng)了拼弃。
kCFRunLoopCommonModes的存在就是來解決這個(gè)問題的，RunLoop運(yùn)行時(shí)驳规，會(huì)把kCFRunLoopCommonModes中的資源下發(fā)到每一個(gè)NSDefaultRunLoopMode和UITrackingRunLoopMode中肴敛，所以加入到kCFRunLoopCommonModes中的timer不管在頁面有沒有滑動(dòng)時(shí)都會(huì)運(yùn)行。解決方法：

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

怎么在tableview滑動(dòng)時(shí)延遲加載圖片來提高流暢度？

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

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

CFRunLoopSourceRef

事件產(chǎn)生的地方砸狞，分為 **Source0 **和 Source1 兩種

• **Source0 **： 只包含了一個(gè)回調(diào)（函數(shù)指針），它并不能主動(dòng)觸發(fā)事件镀梭。使用時(shí)刀森，你需要先調(diào)用 CFRunLoopSourceSignal(source)，將這個(gè) Source 標(biāo)記為待處理报账，然后手動(dòng)調(diào)用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop研底，讓其處理這個(gè)事件
• **Source1 **： 包含了一個(gè) mach_port 和一個(gè)回調(diào)（函數(shù)指針），被用于通過內(nèi)核和其他線程相互發(fā)送消息透罢。這種 Source 能主動(dòng)喚醒 RunLoop 的線程

CFRunLoopTimerRef

基于時(shí)間的觸發(fā)器榜晦，它和 NSTimer 是toll-free bridged 的，可以混用羽圃。其包含一個(gè)時(shí)間長度和一個(gè)回調(diào)（函數(shù)指針）乾胶。當(dāng)其加入到 RunLoop 時(shí)，RunLoop會(huì)注冊(cè)對(duì)應(yīng)的時(shí)間點(diǎn)朽寞，當(dāng)時(shí)間點(diǎn)到時(shí)识窿，RunLoop會(huì)被喚醒以執(zhí)行那個(gè)回調(diào)

CFRunLoopObserverRef

觀察者，每個(gè) Observer 都包含了一個(gè)回調(diào)（函數(shù)指針）脑融，當(dāng) RunLoop 的狀態(tài)發(fā)生變化時(shí)喻频，觀察者就能通過回調(diào)接受到這個(gè)變化≈庥可以觀測的時(shí)間點(diǎn)有以下幾個(gè)：

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry         = (1UL << 0), // 即將進(jìn)入Loop
    kCFRunLoopBeforeTimers  = (1UL << 1), // 即將處理 Timer
    kCFRunLoopBeforeSources = (1UL << 2), // 即將處理 Source
    kCFRunLoopBeforeWaiting = (1UL << 5), // 即將進(jìn)入休眠
    kCFRunLoopAfterWaiting  = (1UL << 6), // 剛從休眠中喚醒
    kCFRunLoopExit          = (1UL << 7), // 即將退出Loop
};

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

/// 用DefaultMode啟動(dòng)
void CFRunLoopRun(void) {
    CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}
 
/// 用指定的Mode啟動(dòng)膜宋，允許設(shè)置RunLoop超時(shí)時(shí)間
int CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean stopAfterHandle) {
    return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}
 
/// RunLoop的實(shí)現(xiàn)
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
    
    /// 首先根據(jù)modeName找到對(duì)應(yīng)mode
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
    /// 如果mode里沒有source/timer/observer, 直接返回窿侈。
    if (__CFRunLoopModeIsEmpty(currentMode)) return;
    
    /// 1. 通知 Observers: RunLoop 即將進(jìn)入 loop。
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);
    
    /// 內(nèi)部函數(shù)秋茫，進(jìn)入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)圆兵，直接處理這個(gè) Source1 然后跳轉(zhuǎn)去處理消息。
            if (__Source0DidDispatchPortLastTime) {
                Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
                if (hasMsg) goto handle_msg;
            }
            
            /// 通知 Observers: RunLoop 的線程即將進(jìn)入休眠(sleep)枢贿。
            if (!sourceHandledThisLoop) {
                __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
            }
            
            /// 7. 調(diào)用 mach_msg 等待接受 mach_port 的消息殉农。線程將進(jìn)入休眠, 直到被下面某一個(gè)事件喚醒。
            /// ? 一個(gè)基于 port 的Source 的事件局荚。
            /// ? 一個(gè) Timer 到時(shí)間了
            /// ? RunLoop 自身的超時(shí)時(shí)間到了
            /// ? 被其他什么調(diào)用者手動(dòng)喚醒
            __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 如果一個(gè) Timer 到時(shí)間了轮傍，觸發(fā)這個(gè)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 如果一個(gè) Source1 (基于port) 發(fā)出事件了杭跪，處理這個(gè)事件
            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) {
                /// 進(jìn)入loop時(shí)參數(shù)說處理完事件就返回。
                retVal = kCFRunLoopRunHandledSource;
            } else if (timeout) {
                /// 超出傳入?yún)?shù)標(biāo)記的超時(shí)時(shí)間了
                retVal = kCFRunLoopRunTimedOut;
            } else if (__CFRunLoopIsStopped(runloop)) {
                /// 被外部調(diào)用者強(qiáng)制停止了
                retVal = kCFRunLoopRunStopped;
            } else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
                /// source/timer/observer一個(gè)都沒有了
                retVal = kCFRunLoopRunFinished;
            }
            
            /// 如果沒超時(shí)驰吓，mode里沒空涧尿，loop也沒被停止，那繼續(xù)loop檬贰。
        } while (retVal == 0);
    }
    
    /// 10. 通知 Observers: RunLoop 即將退出姑廉。
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}

具體流程表現(xiàn)為下圖：

RunLoop_1.png

看到有些人指出圖中第七步中，Source0應(yīng)該改為Source1偎蘸，因?yàn)橹挥蠸ource1能主動(dòng)喚醒RunLoop庄蹋，但是這里沒有強(qiáng)調(diào)是主動(dòng)喚醒，Source0也可以通過手動(dòng)來喚醒迷雪。而且這里Source0后面有標(biāo)注基于port，猜測這種Source0可能是基于port 的Source1分發(fā)出來的虫蝶。

RunLoop 的核心就是一個(gè) mach_msg()章咧，當(dāng)一個(gè)RunLoop處理完事件后，即將進(jìn)入休眠時(shí)能真，會(huì)經(jīng)歷下面幾步：

1. 指定一個(gè)將來喚醒自己的mach_port端口
2. 調(diào)用mach_msg來監(jiān)聽這個(gè)端口赁严，保持mach_msg_trap狀態(tài)
3. 由另一個(gè)線程（比如有可能有一個(gè)專門處理鍵盤輸入事件的loop在后臺(tái)一直運(yùn)行）向內(nèi)核發(fā)送這個(gè)端口的msg后，mach_msg_trap狀態(tài)被喚醒粉铐，RunLoop繼續(xù)運(yùn)行

mach相關(guān)方法涉及到內(nèi)核疼约，這里不做深入

常說的AFNetworking常駐線程保活是什么原理蝙泼？
我們知道程剥，當(dāng)子線程中的任務(wù)執(zhí)行完畢之后就被銷毀了，那么如果我們需要開啟一個(gè)子線程汤踏，在程序運(yùn)行過程中永遠(yuǎn)都存在织鲸，那么我們就會(huì)面臨一個(gè)問題，如何讓子線程永遠(yuǎn)活著溪胶，答案就是給子線程開啟一個(gè)RunLoop搂擦，下面是AFNetworking相關(guān)源碼：

+ (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 啟動(dòng)前內(nèi)部必須要有至少一個(gè) Timer/Source，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個(gè)新的 NSMachPort 添加進(jìn)去了哗脖。通常情況下瀑踢，調(diào)用者需要持有這個(gè) NSMachPort (mach_port) 并在外部線程通過這個(gè) port 發(fā)送消息到 loop 內(nèi)扳还；但此處添加 port 只是為了讓 RunLoop 不至于退出，并沒有用于實(shí)際的發(fā)送消息橱夭。
ps.RunLoop 啟動(dòng)前內(nèi)部就算有一個(gè)observer也是會(huì)返回的氨距。源代碼：

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

注意點(diǎn)

• AutoreleasePool
  App啟動(dòng)后，蘋果在主線程 RunLoop 里注冊(cè)了兩個(gè) Observer：
  第一個(gè) Observer 監(jiān)視的事件是 Entry(即將進(jìn)入Loop)徘钥，其回調(diào)內(nèi)會(huì)調(diào)用 _objc_autoreleasePoolPush() 創(chuàng)建自動(dòng)釋放池衔蹲。其 order 是-2147483647，優(yōu)先級(jí)最高呈础，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前舆驶。
  第二個(gè) Observer 監(jiān)視了兩個(gè)事件： BeforeWaiting(準(zhǔn)備進(jìn)入休眠) 時(shí)調(diào)用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池并創(chuàng)建新池；Exit(即將退出Loop) 時(shí)調(diào)用 _objc_autoreleasePoolPop() 來釋放自動(dòng)釋放池而钞。這個(gè) Observer 的 order 是 2147483647沙廉，優(yōu)先級(jí)最低，保證其釋放池子發(fā)生在其他所有回調(diào)之后臼节。
  在主線程執(zhí)行的代碼撬陵，通常是寫在諸如事件回調(diào)、Timer回調(diào)內(nèi)的网缝。這些回調(diào)會(huì)被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著巨税，所以不會(huì)出現(xiàn)內(nèi)存泄漏，開發(fā)者也不必顯示創(chuàng)建 Pool 了

• GCD
  GCD與RunLoop是平級(jí)合作關(guān)系粉臊，GCD的timer跟RunLoop沒關(guān)系草添，只是調(diào)用點(diǎn)在RunLoop上，需要注意的是扼仲，GCD中的dispatch到mainqueue的block被分發(fā)到RunLoop.main執(zhí)行

• 事件響應(yīng)
  當(dāng)一個(gè)事件(觸摸/鎖屏/搖晃等)發(fā)生后远寸，首先由 SpringBoard 接收，隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進(jìn)程屠凶，從而觸發(fā)進(jìn)程的Source1 （基于 mach port 驰后，提前注冊(cè)用來接收系統(tǒng)事件的Source）的回調(diào)_UIApplicationHandleEventQueue()，把事件包裝成 UIEvent 進(jìn)行處理或分發(fā)（之后的事件分發(fā)處理矗愧，可以看從用戶點(diǎn)擊屏幕到程序作出反應(yīng)之間都發(fā)生了什么灶芝？ --- iOS事件響應(yīng)）。通常事件比如 UIButton 點(diǎn)擊贱枣、touchesBegin/Move/End/Cancel 事件都是在這個(gè)回調(diào)中完成的
  這里有一點(diǎn)值得注意监署，當(dāng)我們點(diǎn)擊一個(gè)按鈕后，進(jìn)行斷點(diǎn)調(diào)試可以發(fā)現(xiàn)調(diào)用的函數(shù)棧里顯示的是Source0:

btnClick.png

原因：首先是由那個(gè)Source1 接收事件纽哥，之后在回調(diào)內(nèi)觸發(fā)的 Source0钠乏，Source0 再觸發(fā)的 _UIApplicationHandleEventQueue()進(jìn)行事件分發(fā)和處理。所以UIButton事件看到是在 Source0 內(nèi)的春塌。

• 線程
  RunLoop的寄生于線程：一個(gè)線程只能有唯一對(duì)應(yīng)的RunLoop晓避，但這個(gè)根RunLoop里可以嵌套子RunLoop簇捍，主線程的RunLoop自動(dòng)創(chuàng)建，子線程的RunLoop默認(rèn)不創(chuàng)建俏拱，在子線程中調(diào)用NSRunLoop.current獲取RunLoop對(duì)象的時(shí)候暑塑，就會(huì)創(chuàng)建RunLoop

• 界面刷新
  當(dāng)在操作 UI 時(shí)，比如改變了 Frame锅必、更新了 UIView/CALayer 的層次時(shí)事格，或者手動(dòng)調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，這個(gè) UIView/CALayer 就被標(biāo)記為待處理搞隐，并被提交到一個(gè)全局的容器去驹愚。蘋果注冊(cè)了一個(gè) Observer 監(jiān)聽 BeforeWaiting(即將進(jìn)入休眠) 和 Exit (即將退出Loop) 事件，回調(diào)去執(zhí)行一個(gè)很長的函數(shù)：
  _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()劣纲。這個(gè)函數(shù)里會(huì)遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實(shí)際的繪制和調(diào)整逢捺，并更新 UI 界面。

參考：
深入理解RunLoop
iOS線下分享《RunLoop》by 孫源@sunnyxx