一、RunLoop 的概念

字面意思是“消息循環、運行循環”，RunLoop 實際上就是一個事件循環對象，這個對象管理了其需要處理的事件和消息，并提供了一個入口函數來執行do-while循環邏輯。線程執行了這個函數后，就會一直處于這個函數內部 “接受消息->等待->處理” 的循環中，直到這個循環結束（比如傳入 quit 的消息），函數返回。

1、runloop的作用：

• 保證程序不退出
• 負責處理各種事件（source、timer、observer）
• 如果沒有事件發生，會讓程序進入休眠狀態。這樣可以節省CPU資源，提高程序性能，有事做就去處理，沒事做就休息。

2、API

OSX/iOS 系統中提供了兩套API來訪問和使用runloop：
CFRunLoopRef（CoreFoundation 框架），純 C 函數 API，所有API都是線程安全的。
NSRunLoop（Foundation框架）， 是基于 CFRunLoopRef 的OC封裝，提供了面向對象的 API，但是這些 API 不是線程安全的。

3、main 函數中的 RunLoop

UIApplicationMain函數內部就啟動了一個RunLoop，所以UIApplicationMain 函數一直沒有返回，保持了程序的持續運行。這個默認啟動的 RunLoop 是跟主線程相關聯的

二、RunLoop 與線程

CFRunLoop 是基于 pthread 來管理的，而pthread和NSThread是一一對應的。

主線程的runloop自動創建，子線程的runloop默認不創建。
runloop是不能夠通過alloc init來創建。要獲取runloop可以通過這兩個函數CFRunLoopGetMain()和 CFRunLoopGetCurrent()來獲得主線程、當前線程runloop（實質是一種懶加載）。（在NSRunloop中對應就是- mainRunloop和- currentRunloop方法）
這兩個函數內部的邏輯大概是下面這樣:

// 全局的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 之間是一一對應的，其關系是保存在一個全局的 Dictionary 里。線程剛創建時并沒有 RunLoop，如果你不主動獲取，那它一直都不會有。RunLoop 的創建是發生在第一次獲取時，RunLoop 的銷毀是發生在線程結束時。你只能在一個線程的內部獲取其 RunLoop（主線程除外）。

三、RunLoop 相關類

在 CoreFoundation 里面關于 RunLoop 有5個類:

CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef

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

RunLoop_0

• 一個 RunLoop可以有多個Mode，每個 Mode 又包含若干個 Source/Timer/Observer。
• Source/Timer/Observer又叫Mode Item。不同Mode下的Mode Item互不影響
• 一個 Item可被加入不同的Mode。但一個 Item 被重復加入同一個 Mode 時是不會有效果的。如果一個 Mode 中一個 Item 都沒有，RunLoop退出。（不過如果僅僅依賴沒有Mode Item來讓runloop退出，這做法是不可靠的）

1、Mode Item

1.1、Source--CFRunLoopSourceRef

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

• source0 非基于端口(port)的：負責App內部事件，由App負責管理觸發，例如UIEvent、UITouch事件。包含了一個回調，不能主動觸發事件。使用時，你需要先調用 CFRunLoopSourceSignal(source)，將這個 Source 標記為待處理，然后手動調用 CFRunLoopWakeUp(runloop)來喚醒 RunLoop，讓其處理這個事件。
  -performSelector:onThread:withObject:waitUntilDone: inModes:創建的是source0任務。
• source1 基于port的：包含一個 mach_port 和一個回調，可監聽系統端口和通過內核和其他線程發送的消息，能主動喚醒runloop，接收分發系統事件。

Source1和Timer都屬于端口事件源，不同的是所有的Timer都共用一個端口(Timer Port)，而每個Source1都有不同的對應端口。
Source0屬于input Source中的一部分，Input Source還包括cuntom自定義源，由其他線程手動發出。

1.2、Timer--CFRunLoopTimerRef

CFRunLoopTimerRef是基于時間的觸發器，基本上說的就是NSTimer。在預設的時間點喚醒runloop執行回調。因為它是基于RunLoop的，因此它不是實時的（就是NSTimer 是不準確的。 因為RunLoop只負責分發源的消息。如果線程當前正在處理繁重的任務，就有可能導致Timer本次延時，或者少執行一次）。

1.3、Observer--CFRunLoopObserverRef

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

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

2、Mode--CFRunLoopModeRef

每次啟動RunLoop時，只能指定其中一個 Mode，這個就是CurrentMode。要切換 Mode，只能退出 Loop，再重新指定一個 Mode 進入
CFRunLoopMode 和 CFRunLoop 的結構大致如下：

struct __CFRunLoopMode {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;  /* must have the run loop locked before locking this */
//mode名
    CFStringRef _name;
    Boolean _stopped;
    char _padding[3];
//source0 源
    CFMutableSetRef _sources0;
//source1 源
    CFMutableSetRef _sources1;
//observer 源
    CFMutableArrayRef _observers;
//timer 源
    CFMutableArrayRef _timers;

//mach port 到 mode的映射,為了在runloop主邏輯中過濾runloop自己的port消息。
    CFMutableDictionaryRef _portToV1SourceMap;

//記錄了所有當前mode中需要監聽的port，作為調用監聽消息函數的參數。
    __CFPortSet _portSet;
    CFIndex _observerMask;
#if USE_DISPATCH_SOURCE_FOR_TIMERS
    dispatch_source_t _timerSource;
    dispatch_queue_t _queue;
    Boolean _timerFired; // set to true by the source when a timer has fired
    Boolean _dispatchTimerArmed;
#endif
#if USE_MK_TIMER_TOO
//使用 mk timer， 用到的mach port，和source1類似，都依賴于mach port
    mach_port_t _timerPort;
    Boolean _mkTimerArmed;
#endif
//timer觸發的理想時間
    uint64_t _timerSoftDeadline; /* TSR */
//timer觸發的實際時間，理想時間加上tolerance（偏差）
    uint64_t _timerHardDeadline; /* TSR */
};

系統默認注冊了5個mode，以下兩個是比較常用的：

kCFRunLoopDefaultMode  //App的默認Mode，通常主線程是在這個 Mode 下運行的
UITrackingRunLoopMode  //界面跟蹤 Mode，用于ScrollView 追蹤觸摸滑動，保證界面滑動時不受其他Mode 影響
UIInitializationRunLoopMode  //在剛啟動 App 時第進入的第一個Mode，啟動完成之后就不再使用。
GSEventReceiveRunLoopMode  //接收系統時間的內部 Mode，通常用不到。
kCFRunLoopCommonModes(比較特殊)  //這時一個占位用的 Mode，不是一種真正的 Mode。

CFRunLoop對外暴露的管理 Mode 接口只有下面2個:

CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);

對于傳入的 mode name 如果runLoop 內部沒有對應 mode 時，runLoop會自動創建對應的 CFRunLoopModeRef。mode只能添加不能刪除

2.1、 kCFRunLoopCommonModes

它是一個占位用的mode，它不是真正意義上的mode。
如果要在線程中開啟runloop，這樣寫是不對的：[[NSRunLoop currentRunLoop] runMode:NSRunLoopCommonModes beforeDate:[NSDate distantFuture]];

下面來看看CFRunLoop中有關CommonMode的結構:

struct __CFRunLoop {
    CFMutableSetRef _commonModes;     // Set
    CFMutableSetRef _commonModeItems; // Set<Source/Observer/Timer>
    CFRunLoopModeRef _currentMode;    // Current Runloop Mode
    CFMutableSetRef _modes;           // Set
    ...
};

有兩個要說明的地方：
1.關于mode：一個mode可以標記為common屬性（用CFRunLoopAddCommonMode函數），然后它就會保存在_commonModes。主線程已有的兩個modekCFRunLoopDefaultMode 和 UITrackingRunLoopMode 都已經是CommonModes了。
2.關于item：_commonModeItems里面存放的source, observer, timer等，在每次runLoop運行的時候都會被同步到具有Common標記的Modes里。比如這樣：[[NSRunLoop currentRunLoop] addTimer:_timer forMode:NSRunLoopCommonModes];就是把timer放到commonItem里。

四、RunLoop 的內部邏輯

根據蘋果在文檔里的說明，RunLoop 內部的邏輯大致如下:

RunLoop_1

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

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

五、RunLoop 的底層實現

從上面代碼可以看到，RunLoop 的核心是基于 mach port 的，其進入休眠時調用的函數是 mach_msg()。為了解釋這個邏輯，下面稍微介紹一下 OSX/iOS 的系統架構。

RunLoop_3

應用層包括用戶能接觸到的圖形應用，例如 Spotlight、Aqua、SpringBoard 等。
應用框架層即開發人員接觸到的 Cocoa 等框架。
核心框架層包括各種核心框架、OpenGL 等內容。
Darwin 即操作系統的核心，包括系統內核、驅動、Shell 等內容，這一層是開源的，其所有源碼都可以在 opensource.apple.com 里找到。

我們在深入看一下 Darwin 這個核心的架構：

RunLoop_4

Mach 本身提供的 API 非常有限，而且蘋果也不鼓勵使用 Mach 的 API，但是這些API非常基礎，如果沒有這些API的話，其他任何工作都無法實施。在 Mach 中，所有的東西都是通過自己的對象實現的，進程、線程和虛擬內存都被稱為”對象”。和其他架構不同， Mach 的對象間不能直接調用，只能通過消息傳遞的方式實現對象間的通信。”消息”是 Mach 中最基礎的概念，消息在兩個端口 (port) 之間傳遞，這就是 Mach 的 IPC (進程間通信) 的核心。
Mach 的消息定義是在 <mach/message.h> 頭文件的，很簡單：

typedef struct {
  mach_msg_header_t header;
  mach_msg_body_t body;
} mach_msg_base_t;
 
typedef struct {
  mach_msg_bits_t msgh_bits;
  mach_msg_size_t msgh_size;
  mach_port_t msgh_remote_port;
  mach_port_t msgh_local_port;
  mach_port_name_t msgh_voucher_port;
  mach_msg_id_t msgh_id;
} mach_msg_header_t;

一條 Mach 消息實際上就是一個二進制數據包 (BLOB)，其頭部定義了當前端口 local_port 和目標端口 remote_port，發送和接受消息是通過同一個 API 進行的，其 option 標記了消息傳遞的方向：

mach_msg_return_t mach_msg(
 mach_msg_header_t *msg,
 mach_msg_option_t option,
 mach_msg_size_t send_size,
 mach_msg_size_t rcv_size,
 mach_port_name_t rcv_name,
 mach_msg_timeout_t timeout,
 mach_port_name_t notify);

為了實現消息的發送和接收，mach_msg() 函數實際上是調用了一個 Mach 陷阱 (trap)，即函數mach_msg_trap()，陷阱這個概念在 Mach 中等同于系統調用。當你在用戶態調用 mach_msg_trap() 時會觸發陷阱機制，切換到內核態；內核態中內核實現的 mach_msg()函數會完成實際的工作，如下圖：

RunLoop_5

關于具體的如何利用 mach port 發送信息，可以看看 NSHipster 這一篇文章，或者這里的中文翻譯 。

六、蘋果用 RunLoop 實現的功能

1、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 了。

與主線程的 RunLoop 運行邏輯類似，在程序中自定義的自動釋放池，也是在即將退出 RunLoop 的時候，釋放創建的自動釋放池。

2、定時器

NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。

上面有講到 RunLoop 本身就是一個圈。更進一步說：不斷地圍著圈跑。

這個特性，很像城市里環城巴士。

一個 NSTimer 注冊到 RunLoop 后，RunLoop 會為其重復的時間點注冊好事件。

例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop為了節省資源，并不會在非常準確的時間點回調這個Timer。

Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到后，容許有多少最大誤差。

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

3、事件響應

蘋果注冊了一個 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 事件都是在這個回調中完成的。

4、手勢識別

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

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

當有 UIGestureRecognizer 的變化(創建/銷毀/狀態改變)時，這個回調都會進行相應處理。

5、界面更新

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

蘋果注冊了一個 Observer 監聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調去執行一個很長的函數：_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數里會遍歷所有待處理的 UIView/CAlayer 以執行實際的繪制和調整，并更新 UI 界面。

這個函數內部的調用棧大概是這樣的：

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
    QuartzCore:CA::Transaction::observer_callback:
        CA::Transaction::commit();
            CA::Context::commit_transaction();
                CA::Layer::layout_and_display_if_needed();
                    CA::Layer::layout_if_needed();
                        [CALayer layoutSublayers];
                            [UIView layoutSubviews];
                    CA::Layer::display_if_needed();
                        [CALayer display];
                            [UIView drawRect];

6、PerformSelecter

當調用 NSObject 的 performSelecter:afterDelay: 后，實際上其內部會創建一個 Timer 并添加到當前線程的 RunLoop 中。所以如果當前線程沒有 RunLoop，則這個方法會失效。
當調用 performSelector:onThread: 時，實際上其會創建一個 Timer 加到對應的線程去，同樣的，如果對應線程沒有 RunLoop 該方法也會失效。

7、關于GCD

RunLoop 底層會用到 GCD 的東西，GCD 的某些 API 也用到了 RunLoop。如當調用了 dispatch_async(dispatch_get_main_queue(), block)時，主隊列會把該 block 放到對應的線程（恰好是主線程）中，主線程的 RunLoop 會被喚醒，從消息中取得這個 block，回調CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里執行這個 block。但這個邏輯僅限于 dispatch 到主線程，dispatch 到其他線程仍然是由 libDispatch 處理的。

8、關于網絡請求

iOS 中，關于網絡請求的接口自下至上有如下幾層:

CFSocket
CFNetwork ->ASIHttpRequest
NSURLConnection ->AFNetworking
NSURLSession ->AFNetworking2, Alamofire

CFSocket 是最底層的接口，只負責 socket 通信。? CFNetwork 是基于 CFSocket 等接口的上層封裝，ASIHttpRequest 工作于這一層。
NSURLConnection 是基于 CFNetwork 的更高層的封裝，提供面向對象的接口，AFNetworking 工作于這一層。
NSURLSession 是 iOS7 中新增的接口，表面上是和 NSURLConnection 并列的，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)，AFNetworking2 和 Alamofire 工作于這一層。

8.1、下面主要介紹下 NSURLConnection 的工作過程。

通常使用 NSURLConnection 時，你會傳入一個 Delegate，當調用了 [connection start] 后，這個 Delegate 就會不停收到事件回調。實際上，start 這個函數的內部會會獲取 CurrentRunLoop，然后在其中的 DefaultMode 添加了4個 Source0 (即需要手動觸發的Source)。CFMultiplexerSource 是負責各種 Delegate 回調的，CFHTTPCookieStorage 是處理各種 Cookie 的。

當開始網絡傳輸時，我們可以看到 NSURLConnection 創建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的。NSURLConnectionLoader 這個線程內部會使用 RunLoop 來接收底層 socket 的事件，并通過之前添加的 Source0 通知到上層的 Delegate。

RunLoop_network

七、第三方庫 RunLoop 的運用

1、AFNetWorking 里面的常駐線程

(友情提醒：NSURLConnection 在 AFNetWorking 3.0 及以后已經棄用)

子線程默認是完成任務后結束。當要經常使用子線程，每次開啟子線程比較耗性能。此時可以開啟子線程的 RunLoop，保持 RunLoop 運行，則使子線程保持不死。AFNetworking 基于 NSURLConnection 時正是這樣做的，希望在后臺線程能保持活著，從而能接收到 delegate 的回調。

這一點充分體現了：我們控制了runloop ,就是控制了app 的生死。

具體做法是：

            /* 返回一個線程 */
+ (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;
    }
/* 在新開的線程中執行的第一個方法 */
+ (void)networkRequestThreadEntryPoint:(id)__unused object {
    @autoreleasepool {
        [[NSThread currentThread] setName:@"AFNetworking"];
        // 獲取當前線程對應的 RunLoop
        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        // 為 RunLoop 添加 source，模式為 DefaultMode
        [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        // 開始運行 RunLoop
        [runLoop run];
    }
}

因為 RunLoop 啟動前必須設置一個 mode，而 mode 要存在則至少需要一個 source / timer。所以上面的做法是為 RunLoop 的 DefaultMode 添加一個 NSMachPort 對象，雖然消息是可以通過 NSMachPort 對象發送到 loop 內，但這里添加的 port 只是為了 RunLoop 一直不退出，而沒有發送什么消息。當然我們也可以添加一個超長啟動時間的 timer 來既保持 RunLoop 不退出也不占用資源。

2、AsyncDisplayKit

AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架，其原理大致如下：
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。

八、開發中常見 RunLoop 使用

上面系統介紹了蘋果官方對于 RunLoop 的使用和常見的第三方類庫的使用。
但是，我們實際應用最多的可能會是下面這些具體場景。

1、UIImageView 延遲加載圖片

假設我們有一個UITableView，UITableView上面有很多UITableViewCell，UITableViewCell上面有一個UIImageView（你可以想象QQ的聊天頁面）。這時候一般我們的需求都是那個UIImageView的圖片需要你從網絡上下載，并且異步，下載成功之后更新到UIImageView上。

實際上這個時候我們就會碰到問題，因為我們的UITableView是可以任意拖動的，所以如果不更改NSURLConnection的運行模式，那么只要 UItableView 出現滑動，NSURLConnection 所在的DefaultMode 就會退出，切換到 UITrackingRunLoopMode 。

給 UIImageView 設置圖片可能耗時不少，如果此時要滑動 tableView 等則可能影響到界面的流暢。

解決是：使用 performSelector:withObject:afterDelay:inModes: 方法，將設置圖片的方法放到 DefaultMode 中執行。
為了流暢性，把圖片加載延遲。

2、UITableView 與 NSTimer 沖突

由于 UItabelView 在滑動的時候，會從當前的 RunLoop 默認的模式 kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 退出，進入到 UITrackingRunLoopMode。

這個時候，處于 NSDefaultRunLoopMode 里面的 NSTimer 由于切換了模式造成計時器無法繼續運行。

可以兩個解決方法：（目的就是：即使 mode 切換，計時器依然工作）
此處參考：iOS下RunLoop的實際應用場景探究

九、RunLoop 可能的面試套路

RunLoop面試小結
什么是RunLoop?
從字面上看:運行循環、跑圈
其實它內部就是do-while循環,在這個循環內部不斷的處理各種任務(比如Source、Timer、Observer)

一個線程對應一個RunLoop,主線程的RunLoop默認已經啟動,子線程的RunLoop需要手動啟動(調用run方法)RunLoop只能選擇一個Mode啟動,如果當前Mode中沒有任何Soure、Timer、Observer,那么就直接退出RunLoop

在開發中如何使用RunLoop? 什么應用場景?
開啟一個常駐線程(讓一個子線程不進入消亡狀態,等待其他線程發來消息,處理其他事件) 在子線程中開啟一個定時器 在子線程中進行一些長期監控

可以控制定時器在特定模式下執行可以讓某些事件(行為、任務)在特定模式下執行可以添加Observer監聽RunLoop的狀態,比如監聽點擊事件的處理(在所有點擊事件之前做一些事情)

參考鏈接：

1、深入理解RunLoop
2、RunLoop 詳解
3、視頻-runloop線下分享
4、RunLoop實際應用