概念

一般來講，一個線程一次只能執(zhí)行一個任務(wù)，執(zhí)行完成后線程就會退出。如果我們需要一個機制，讓線程能隨時處理事件但并不退出，那么就得讓它循環(huán)。

所以，Run Loop 實際上就是一個對象，這個對象管理了其需要處理的事件和消息，并提供了一個入口函數(shù)來執(zhí)行任務(wù)。線程執(zhí)行了這個函數(shù)后，就會一直處于這個函數(shù)內(nèi)部 “接受消息->等待->處理” 的循環(huán)中，直到這個循環(huán)結(jié)束（比如傳入 quit 的消息），函數(shù)返回。
如下圖：

進程圖

實際上APP本身就是一個RunLoop，對應(yīng)其主線程

層級結(jié)構(gòu)

稍微介紹一下 OSX/iOS 的系統(tǒng)架構(gòu)。

系統(tǒng)架構(gòu)圖

蘋果官方將整個系統(tǒng)大致劃分為上述4個層次：

• 應(yīng)用層
  面向用戶，包括用戶能接觸到的圖形應(yīng)用。

• 應(yīng)用框架層
  面向開發(fā)，基礎(chǔ)的Foundation框架，NS開頭的類（NextStep的縮寫，OC前身），提供常用OC接口編程，由蘋果封裝，不開源。

• 核心框架層
  包括各種核心框架、OpenGL 等內(nèi)容，其中主要的是CoreFoundation，CF開頭的類（CoreFoundation縮寫），使用C語言為基礎(chǔ)，提供C語言接口。

• Darwin
  操作系統(tǒng)的核心，包括系統(tǒng)內(nèi)核、驅(qū)動、Shell 等內(nèi)容。
  

  darwin

  其中，在硬件層上面的三個組成部分：Mach、BSD、IOKit (還包括一些上面沒標注的內(nèi)容)，共同組成了 XNU 內(nèi)核。
  XNU 內(nèi)核的內(nèi)環(huán)被稱作 Mach，其作為一個微內(nèi)核，僅提供了諸如處理器調(diào)度、IPC (進程間通信)等非常少量的基礎(chǔ)服務(wù)。
  BSD 層可以看作圍繞 Mach 層的一個外環(huán)，其提供了諸如進程管理、文件系統(tǒng)和網(wǎng)絡(luò)等功能。
  IOKit 層是為設(shè)備驅(qū)動提供了一個面向?qū)ο?C++)的一個框架。
  Mach 本身提供的 API 非常有限，而且蘋果也不鼓勵使用 Mach 的 API，但是這些API非常基礎(chǔ)，如果沒有這些API的話，其他任何工作都無法實施。在 Mach 中，所有的東西都是通過自己的對象實現(xiàn)的，進程、線程和虛擬內(nèi)存都被稱為"對象"。和其他架構(gòu)不同， Mach 的對象間不能直接調(diào)用，只能通過消息傳遞的方式實現(xiàn)對象間的通信。"消息"是 Mach 中最基礎(chǔ)的概念，消息在兩個端口 (port) 之間傳遞，這就是 Mach 的 IPC (進程間通信) 的核心。

RunLoop 與線程的關(guān)系

每個線程(包含主線程)都有一個Runloop。創(chuàng)建一個新線程的同時會有相應(yīng)的Runloop，一一對應(yīng)關(guān)系，儲存在一個全局字典中
對于每一個Runloop，系統(tǒng)會隱式創(chuàng)建一個Autorelease pool，這樣所有的release pool會構(gòu)成一個像callstack一樣的一個棧式結(jié)構(gòu)，在每一個Runloop結(jié)束時，當前棧頂?shù)腁utorelease pool會被銷毀，這樣這個pool里的每個Object會被release。

蘋果不允許直接創(chuàng)建 RunLoop，它只提供了兩個自動獲取的函數(shù)：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 這兩個函數(shù)內(nèi)部的邏輯大概是下面這樣:

/// 全局的Dictionary，key 是 pthread_t， value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 訪問 loopsDic 時的鎖
static CFSpinLock_t loopsLock;
  
/// 獲取一個 pthread 對應(yīng)的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {
    OSSpinLockLock(&loopsLock);
     
    if (!loopsDic) {
        // 第一次進入時，初始化全局Dic，并先為主線程創(chuàng)建一個 RunLoop。
        loopsDic = CFDictionaryCreateMutable();
        CFRunLoopRef mainLoop = _CFRunLoopCreate();
        CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
    }
     
    /// 直接從 Dictionary 里獲取。
    CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));
     
    if (!loop) {
        /// 取不到時，創(chuàng)建一個
        loop = _CFRunLoopCreate();
        CFDictionarySetValue(loopsDic, thread, loop);
        /// 注冊一個回調(diào)，當線程銷毀時，順便也銷毀其對應(yīng)的 RunLoop。
        _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
    }
     
    OSSpinLockUnLock(&loopsLock);
    return loop;
}
  
CFRunLoopRef CFRunLoopGetMain() {
    return _CFRunLoopGet(pthread_main_thread_np());
}
  
CFRunLoopRef CFRunLoopGetCurrent() {
    return _CFRunLoopGet(pthread_self());
}

從上面的代碼可以看出，線程和 RunLoop 之間是一一對應(yīng)的，其關(guān)系是保存在一個全局的 Dictionary 里。線程剛創(chuàng)建時并沒有 RunLoop，如果你不主動獲取，那它一直都不會有。RunLoop 的創(chuàng)建是發(fā)生在第一次獲取時，RunLoop 的銷毀是發(fā)生在線程結(jié)束時。你只能在一個線程的內(nèi)部獲取其 RunLoop（主線程除外）。

RunLoop 對外的接口

在 CoreFoundation 里面關(guān)于 RunLoop 有5個類:

• CFRunLoopRef
• CFRunLoopModeRef
• CFRunLoopSourceRef
• CFRunLoopTimerRef
• CFRunLoopObserverRef

其中 CFRunLoopModeRef 類并沒有對外暴露，只是通過 CFRunLoopRef 的接口進行了封裝。他們的關(guān)系如下:

RunLoop

CFRunLoopSourceRef是事件產(chǎn)生的地方。Source有兩個版本：Source0 和 Source1。

• Source0 只包含了一個回調(diào)（函數(shù)指針），它并不能主動觸發(fā)事件。使用時，你需要先調(diào)用 CFRunLoopSourceSignal(source)，將這個 Source 標記為待處理，然后手動調(diào)用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop，讓其處理這個事件。
• Source1 包含了一個 mach_port 和一個回調(diào)（函數(shù)指針），被用于通過內(nèi)核和其他線程相互發(fā)送消息。這種 Source 能主動喚醒 RunLoop 的線程，其原理在下面會講到。

CFRunLoopTimerRef 是基于時間的觸發(fā)器，它和 NSTimer 是toll-free bridged 的，可以混用。其包含一個時間長度和一個回調(diào)（函數(shù)指針）。當其加入到 RunLoop 時，RunLoop會注冊對應(yīng)的時間點，當時間點到時，RunLoop會被喚醒以執(zhí)行那個回調(diào)。

CFRunLoopObserverRef是觀察者，每個 Observer 都包含了一個回調(diào)（函數(shù)指針），當 RunLoop 的狀態(tài)發(fā)生變化時，觀察者就能通過回調(diào)接受到這個變化。可以觀測的時間點有以下幾個：

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

上面的 Source/Timer/Observer 被統(tǒng)稱為 mode item，一個 item 可以被同時加入多個 mode。但一個 item 被重復加入同一個 mode 時是不會有效果的。如果一個 mode 中一個 item 都沒有，則 RunLoop 會直接退出，不進入循環(huán)。

RunLoop 的 Mode

CFRunLoopMode 和 CFRunLoop 的結(jié)構(gòu)大致如下：

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

這里有個概念叫 "CommonModes"：一個 Mode 可以將自己標記為"Common"屬性（通過將其 ModeName 添加到 RunLoop 的 "commonModes" 中）。每當 RunLoop 的內(nèi)容發(fā)生變化時，RunLoop 都會自動將 _commonModeItems 里的 Source/Observer/Timer 同步到具有 "Common" 標記的所有Mode里。

應(yīng)用場景舉例：主線程的 RunLoop 里有兩個預置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。這兩個 Mode 都已經(jīng)被標記為"Common"屬性。DefaultMode 是 App 平時所處的狀態(tài)，TrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態(tài)。當你創(chuàng)建一個 Timer 并加到 DefaultMode 時，Timer 會得到重復回調(diào)，但此時滑動一個TableView時，RunLoop 會將 mode 切換為 TrackingRunLoopMode，這時 Timer 就不會被回調(diào)，并且也不會影響到滑動操作。

有時你需要一個 Timer，在兩個 Mode 中都能得到回調(diào)，一種辦法就是將這個 Timer 分別加入這兩個 Mode。還有一種方式，就是將 Timer 加入到頂層的 RunLoop 的 "commonModeItems" 中。"commonModeItems" 被 RunLoop 自動更新到所有具有"Common"屬性的 Mode 里去。

  [[NSRunLoop currentRunLoop]addTimer:timer...forMode:NSRunLoopCommonModes];

簡單說：如果把定時器加到runloop中，如果mode指定為default類型，那么滑動時定時器不工作，只有指定為common，才會跟runloop中原內(nèi)容不沖突，兩邊的回調(diào)事件均能進行。

RunLoop 的內(nèi)部邏輯

根據(jù)蘋果在文檔里的說明，RunLoop 內(nèi)部的邏輯大致如下:

內(nèi)部邏輯

其內(nèi)部代碼整理如下 ：

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

可以看到，實際上 RunLoop 就是這樣一個函數(shù)，其內(nèi)部是一個 do-while 循環(huán)。當你調(diào)用 CFRunLoopRun() 時，線程就會一直停留在這個循環(huán)里；直到超時或被手動停止，該函數(shù)才會返回。

AutoreleasePool

App啟動后，蘋果在主線程 RunLoop 里注冊了兩個 Observer，其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()。

第一個 Observer 監(jiān)視的事件是 Entry(即將進入Loop)，其回調(diào)內(nèi)會調(diào)用 _objc_autoreleasePoolPush() 創(chuàng)建自動釋放池。其 order 是-2147483647，優(yōu)先級最高，保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前。

第二個 Observer 監(jiān)視了兩個事件： BeforeWaiting(準備進入休眠) 時調(diào)用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 釋放舊的池并創(chuàng)建新池；Exit(即將退出Loop) 時調(diào)用 _objc_autoreleasePoolPop() 來釋放自動釋放池。這個 Observer 的 order 是 2147483647，優(yōu)先級最低，保證其釋放池子發(fā)生在其他所有回調(diào)之后。

在主線程執(zhí)行的代碼，通常是寫在諸如事件回調(diào)、Timer回調(diào)內(nèi)的。這些回調(diào)會被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著，所以不會出現(xiàn)內(nèi)存泄漏，開發(fā)者也不必顯示創(chuàng)建 Pool 了。

AutoreleasePool在runloop時會被創(chuàng)建，然后在進入休眠前會被釋放和重新創(chuàng)建，最后在程序關(guān)閉時再被釋放

事件響應(yīng)

蘋果注冊了一個 Source1 (基于 mach port 的) 用來接收系統(tǒng)事件，其回調(diào)函數(shù)為 __IOHIDEventSystemClientQueueCallback()。

當一個硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后，首先由 IOKit.framework 生成一個 IOHIDEvent 事件并由 SpringBoard 接收。這個過程的詳細情況可以參考這里。SpringBoard 只接收按鍵(鎖屏/靜音等)，觸摸，加速，接近傳感器等幾種 Event，隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進程。隨后蘋果注冊的那個 Source1 就會觸發(fā)回調(diào)，并調(diào)用 _UIApplicationHandleEventQueue() 進行應(yīng)用內(nèi)部的分發(fā)。

_UIApplicationHandleEventQueue() 會把 IOHIDEvent 處理并包裝成 UIEvent 進行處理或分發(fā)，其中包括識別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等。通常事件比如 UIButton 點擊、touchesBegin/Move/End/Cancel 事件都是在這個回調(diào)中完成的。

手勢識別

當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會調(diào)用 Cancel 將當前的 touchesBegin/Move/End 系列回調(diào)打斷。隨后系統(tǒng)將對應(yīng)的 UIGestureRecognizer 標記為待處理。

蘋果注冊了一個 Observer 監(jiān)測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()，其內(nèi)部會獲取所有剛被標記為待處理的 GestureRecognizer，并執(zhí)行GestureRecognizer的回調(diào)。

當有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時，這個回調(diào)都會進行相應(yīng)處理。

界面更新

當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，這個 UIView/CALayer 就被標記為待處理，并被提交到一個全局的容器去。

蘋果注冊了一個 Observer 監(jiān)聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調(diào)去執(zhí)行一個很長的函數(shù)：

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數(shù)里會遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實際的繪制和調(diào)整，并更新 UI 界面。

定時器

NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 注冊到 RunLoop 后，RunLoop 會為其重復的時間點注冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節(jié)省資源，并不會在非常準確的時間點回調(diào)這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到后，容許有多少最大誤差。

如果某個時間點被錯過了，例如執(zhí)行了一個很長的任務(wù)，則那個時間點的回調(diào)也會跳過去，不會延后執(zhí)行。就比如等公交，如果 10:10 時我忙著玩手機錯過了那個點的公交，那我只能等 10:20 這一趟了。

CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復雜，和 NSTimer 并不一樣，其內(nèi)部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執(zhí)行了一個長任務(wù)，那其中就會有一幀被跳過去（和 NSTimer 相似），造成界面卡頓的感覺。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題，其內(nèi)部也用到了 RunLoop，這個稍后我會再單獨寫一頁博客來分析。

PerformSelecter

當調(diào)用 NSObject 的 performSelecter:afterDelay: 后，實際上其內(nèi)部會創(chuàng)建一個 Timer 并添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop，則這個方法會失效。

當調(diào)用 performSelector:onThread: 時，實際上其會創(chuàng)建一個 Timer 加到對應(yīng)的線程去，同樣的，如果對應(yīng)線程沒有 RunLoop 該方法也會失效。

關(guān)于GCD

實際上 RunLoop 底層也會用到 GCD 的東西，比如 RunLoop 是用 dispatch_source_t 實現(xiàn)的 Timer。但同時 GCD 提供的某些接口也用到了 RunLoop， 例如 dispatch_async()。

當調(diào)用 dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主線程的 RunLoop 發(fā)送消息，RunLoop會被喚醒，并從消息中取得這個 block，并在回調(diào) CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里執(zhí)行這個 block。但這個邏輯僅限于 dispatch 到主線程，dispatch 到其他線程仍然是由 libDispatch 處理的。

關(guān)于網(wǎng)絡(luò)請求

通常使用 NSURLConnection 時，你會傳入一個 Delegate，當調(diào)用了 [connection start] 后，這個 Delegate 就會不停收到事件回調(diào)。

實際上，start 這個函數(shù)的內(nèi)部會獲取 CurrentRunLoop，然后在其中的 DefaultMode 添加 Source0 (即需要手動觸發(fā)的Source)。當開始網(wǎng)絡(luò)傳輸時，我們可以看到 NSURLConnection 創(chuàng)建了新線程。

NSURLConnectionLoader 這個線程內(nèi)部會使用 RunLoop 基于 mach port 的 Source 接收來自底層 CFSocket 的通知，并通過之前添加的 Source0 通知到 RunLoop 來讓其處理這些通知，再通過Delegate執(zhí)行實際網(wǎng)絡(luò)連接的回調(diào)。

AFNetWorking 中創(chuàng)建RunLoop

AFNetWorking創(chuàng)建了自己的RunLoop用于后臺下載。

- (void)networkRequestThreadEntryPoint:(id)_unuserd  object{
  @autoreleasepool{
       [[NSThread currentThread] setName:@"AFNetworking"];
       NSRunLoop *runloop = [NSRunLoop currentRunLoop];
       [runLoop addPort:[NSMachPort port] forMode:NSDefalutRunLoopMode]//一直活著
       [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;

一個TableView延遲加載圖片的新思路

tableView在刷新滑動過程中setImage可能會造成卡頓，新的解決方法是滑動過程中圖片先用defaultImage，然后在滑動結(jié)束的時候runLoop由trickingMode切換會defaultMode的以后再執(zhí)行setImage。

[self.avatarImageView performSelector:@selector(serImage:)    
                        withObjetc:downloadedImage
                        afterDelay:0
                        inModes:@[NSDefaultRunLoopMode]]

讓Crash的App回光返照 只針對Signal Crash

截取程序崩潰，給予友好提示。

CFRunLoopRef runloop = CFRunLoopGetCurrent();
NSArray *allModes = CFBridgingRelease(CFRunLoopCopyAllModes(runLoop));
while(1){
    for (NSString *mode in allModes){
        CFRunLoopInMode((CFStringRef)mode,0.001,false);
    }
}