RunLoop，顧名思義就是跑圈，相信每個(gè)iOS開發(fā)者都聽聞過，但是好多人都是一知半解，毋庸置疑，RunLoop是iOS進(jìn)階過程中不可逃避的一個(gè)坎，面試的時(shí)候也遇到過不少相關(guān)問題吧，所以咯，逃不出的圈子 -- RunLoop
問題
當(dāng)scroll滑動(dòng)時(shí)，同頁(yè)面上的定時(shí)器為什么會(huì)暫停？

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

常說的AFNetworking常駐線程?；钍鞘裁丛恚?/p>

基本概念
其實(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é)束了嗎？那我們見到的程序是怎么能長(zhǎng)時(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語(yǔ)言

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)容 -- 觀察者

1487818820616563.png

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í)，同頁(yè)面上的定時(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)頁(yè)面滾動(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中，所以

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í)間長(zhǎng)度和一個(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è)變化。可以觀測(cè)的時(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)為下圖：

Paste_Image.png

看到有些人指出圖中第七步中，Source0應(yīng)該改為Source1，因?yàn)橹挥蠸ource1能主動(dòng)喚醒RunLoop，但是這里沒有強(qiáng)調(diào)是主動(dòng)喚醒，Source0也可以通過手動(dòng)來喚醒。而且這里Source0后面有標(biāo)注基于port，猜測(cè)這種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:

1487819244561630.png