RunLoop 是 iOS 和 OS X 開發(fā)中非车挡澹基礎(chǔ)的一個概念慢蜓，本文將從 CFRunLoop 的源碼入手，介紹 RunLoop 的概念和底層實現(xiàn)原理郭膛。然后晨抡，講解一下在 iOS 中蘋果是如何利用 RunLoop 實現(xiàn)自動釋放池、延遲回調(diào)则剃、觸摸事件耘柱、屏幕刷新等功能。

內(nèi)容概述

• RunLoop 的概念
• RunLoop 與線程的關(guān)系
• RunLoop 對外的接口
• RunLoop 的 Mode
• RunLoop 的內(nèi)部邏輯
• RunLoop 的底層實現(xiàn)
• RunLoop 實現(xiàn)的功能
  • AutoreleasePool
  • 事件響應(yīng)
  • 手勢識別
  • 界面更新
  • 定時器
  • PerformSelecter
  • 關(guān)于GCD
  • 關(guān)于網(wǎng)絡(luò)請求
• RunLoop 的實際應(yīng)用舉例
  • AFNetworking
  • AsyncDisplayKit

RunLoop 的概念

一般來講棍现，一個線程一次只能執(zhí)行一個任務(wù)调煎，執(zhí)行完成后線程就會退出。如果我們需要一個機制己肮，讓線程能隨時處理事件但并不退出士袄，通常的代碼邏輯是這樣的：

function loop() {
    initialize();
    do {
        var message = get_next_message();
        process_message(message);
    } while (message != quit);
}

這種模型通常被稱作為 Event Loop。 Event Loop 在很多系統(tǒng)和框架里都有實現(xiàn)谎僻，比如 Node.js 的事件處理娄柳，比如 Windows 程序的消息循環(huán)，再比如 OSX/iOS 里的 RunLoop艘绍。實現(xiàn)這種模型的關(guān)鍵點在于：如何管理事件/消息赤拒，如何讓線程在沒有處理消息時休眠以避免資源占用、在有消息到來時立刻被喚醒鞍盗。

所以需了，RunLoop 實際上就是一個對象跳昼，這個對象管理了其需要處理的事件和消息，并提供了一個入口函數(shù)來執(zhí)行上面 Event Loop 的邏輯肋乍。線程執(zhí)行了這個函數(shù)后鹅颊，就會一直處于這個函數(shù)內(nèi)部的循環(huán)（接受消息->等待->處理）中，直到這個循環(huán)結(jié)束（比如傳入 quit 的消息）墓造，函數(shù)返回堪伍。

OSX/iOS 系統(tǒng)中，提供了兩個這樣的對象：NSRunLoop 和 CFRunLoopRef觅闽。

• CFRunLoopRef - 在 CoreFoundation 框架內(nèi)帝雇，它提供了純 C 函數(shù)的 API，所有這些 API 都是線程安全的蛉拙。
• NSRunLoop - 基于 CFRunLoopRef 的封裝尸闸，提供了面向?qū)ο蟮?API，但是這些 API 不是線程安全的孕锄。

CFRunLoopRef 的代碼是開源的吮廉，你也可以下載整個 CoreFoundation 的源碼。為了方便查看和跟蹤畸肆，你可以新建一個 Xcode 工程宦芦，把這堆源碼拖進去查看。

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

首先轴脐，iOS 開發(fā)中能遇到兩個線程對象: pthread_t 和 NSThread调卑。過去蘋果有份 文檔 標明了 NSThread 只是 pthread_t 的封裝，但那份文檔已經(jīng)失效了大咱，現(xiàn)在它們也有可能都是直接包裝自最底層的 mach thread恬涧。蘋果沒有提供這兩個對象相互轉(zhuǎn)換的接口，但不管怎么樣徽级，可以肯定的是 pthread_t 和 NSThread 是一一對應(yīng)的气破，比如，你可以通過 pthread_main_np() 或 [NSThread mainThread] 來獲取主線程餐抢；也可以通過 pthread_self() 或 [NSThread currentThread] 來獲取當前線程。CFRunLoop 是基于 pthread 來管理的低匙。

蘋果不允許直接創(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 包含若干個 Mode淳玩，每個 Mode 又包含若干個 Source/Timer/Observer直撤。每次調(diào)用 RunLoop 的主函數(shù)時，只能指定其中一個 Mode蜕着，這個Mode被稱作 CurrentMode谋竖。如果需要切換 Mode，只能退出 Loop承匣，再重新指定一個 Mode 進入蓖乘。這樣做主要是為了分隔開不同組的 Source/Timer/Observer，讓其互不影響韧骗。

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 里去。

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

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

Mode 暴露的管理 mode item 的接口有下面幾個：

CFRunLoopAddSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopAddObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopAddTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
CFRunLoopRemoveSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopRemoveObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopRemoveTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);

你只能通過 Mode Name 來操作內(nèi)部的 Mode塘娶，當你傳入一個新的 Mode Name 但 RunLoop 內(nèi)部沒有對應(yīng) Mode 時归斤，RunLoop會自動幫你創(chuàng)建對應(yīng)的 CFRunLoopModeRef。對于一個 RunLoop 來說刁岸，其內(nèi)部的 mode 只能增加不能刪除脏里。

蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode，你可以用這兩個 Mode Name 來操作其對應(yīng)的 Mode虹曙。

同時蘋果還提供了一個操作 Common 標記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)迫横，你可以用這個字符串來操作 Common Items，或標記一個 Mode 為 "Common"酝碳。使用時注意區(qū)分這個字符串和其他 Mode Name矾踱。

RunLoop 的內(nèi)部邏輯

根據(jù)蘋果在文檔里的說明，RunLoop 內(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ù)才會返回麻车。

RunLoop 的底層實現(xiàn)

從上面代碼可以看到缀皱，RunLoop 的核心是基于 mach port 的，其進入休眠時調(diào)用的函數(shù)是 mach_msg()动猬。為了解釋這個邏輯啤斗，下面稍微介紹一下 OSX/iOS 的系統(tǒng)架構(gòu)。

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

1枣察、應(yīng)用層包括用戶能接觸到的圖形應(yīng)用争占，例如 Spotlight、Aqua序目、SpringBoard 等臂痕。
2、應(yīng)用框架層即開發(fā)人員接觸到的 Cocoa 等框架猿涨。
3握童、核心框架層包括各種核心框架、OpenGL 等內(nèi)容叛赚。
4澡绩、Darwin 即操作系統(tǒng)的核心，包括系統(tǒng)內(nèi)核俺附、驅(qū)動肥卡、Shell 等內(nèi)容，這一層是開源的事镣，其所有源碼都可以查看步鉴。

我們在深入看一下 Darwin 這個核心的架構(gòu)：

其中，在硬件層上面的三個組成部分：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 (進程間通信) 的核心吻育。

Mach 的消息定義是在頭文件的念秧，很簡單：

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 消息實際上就是一個二進制數(shù)據(jù)包 (BLOB)，其頭部定義了當前端口 local_port 和目標端口 remote_port布疼，

發(fā)送和接受消息是通過同一個 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);

為了實現(xiàn)消息的發(fā)送和接收，mach_msg() 函數(shù)實際上是調(diào)用了一個 Mach 陷阱 (trap)游两，即函數(shù)mach_msg_trap()砾层，陷阱這個概念在 Mach 中等同于系統(tǒng)調(diào)用。當你在用戶態(tài)調(diào)用 mach_msg_trap() 時會觸發(fā)陷阱機制贱案，切換到內(nèi)核態(tài)肛炮，內(nèi)核態(tài)中內(nèi)核實現(xiàn)的 mach_msg() 函數(shù)會完成實際的工作，如下圖：

這些概念可以參考維基百科: System_call轰坊、Trap_(computing)铸董。

RunLoop 的核心就是一個 mach_msg() (見上面代碼的第7步)，RunLoop 調(diào)用這個函數(shù)去接收消息肴沫，如果沒有別人發(fā)送 port 消息過來粟害，內(nèi)核會將線程置于等待狀態(tài)。例如你在模擬器里跑起一個 iOS 的 App颤芬，然后在 App 靜止時點擊暫停悲幅，你會看到主線程調(diào)用棧是停留在 mach_msg_trap() 這個地方套鹅。

關(guān)于具體的如何利用 mach port 發(fā)送信息，可以看看 NSHipster 這一篇文章汰具，或者這里的中文翻譯卓鹿。

關(guān)于 Mach 的歷史可以閱讀這篇很有趣的文章：Mac OS X 背后的故事（三）Mach 之父 Avie Tevanian。

蘋果用 RunLoop 實現(xiàn)的功能

首先我們可以看一下 App 啟動后 RunLoop 的狀態(tài)：

CFRunLoop {
    current mode = kCFRunLoopDefaultMode
    common modes = {
        UITrackingRunLoopMode
        kCFRunLoopDefaultMode
    }
 
    common mode items = {
 
        // source0 (manual)
        CFRunLoopSource {order =-1, {
            callout = _UIApplicationHandleEventQueue}}
        CFRunLoopSource {order =-1, {
            callout = PurpleEventSignalCallback }}
        CFRunLoopSource {order = 0, {
            callout = FBSSerialQueueRunLoopSourceHandler}}
 
        // source1 (mach port)
        CFRunLoopSource {order = 0,  {port = 17923}}
        CFRunLoopSource {order = 0,  {port = 12039}}
        CFRunLoopSource {order = 0,  {port = 16647}}
        CFRunLoopSource {order =-1, {
            callout = PurpleEventCallback}}
        CFRunLoopSource {order = 0, {port = 2407,
            callout = _ZL20notify_port_callbackP12__CFMachPortPvlS1_}}
        CFRunLoopSource {order = 0, {port = 1c03,
            callout = __IOHIDEventSystemClientAvailabilityCallback}}
        CFRunLoopSource {order = 0, {port = 1b03,
            callout = __IOHIDEventSystemClientQueueCallback}}
        CFRunLoopSource {order = 1, {port = 1903,
            callout = __IOMIGMachPortPortCallback}}
 
        // Ovserver
        CFRunLoopObserver {order = -2147483647, activities = 0x1, // Entry
            callout = _wrapRunLoopWithAutoreleasePoolHandler}
        CFRunLoopObserver {order = 0, activities = 0x20,          // BeforeWaiting
            callout = _UIGestureRecognizerUpdateObserver}
        CFRunLoopObserver {order = 1999000, activities = 0xa0,    // BeforeWaiting | Exit
            callout = _afterCACommitHandler}
        CFRunLoopObserver {order = 2000000, activities = 0xa0,    // BeforeWaiting | Exit
            callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}
        CFRunLoopObserver {order = 2147483647, activities = 0xa0, // BeforeWaiting | Exit
            callout = _wrapRunLoopWithAutoreleasePoolHandler}
 
        // Timer
        CFRunLoopTimer {firing = No, interval = 3.1536e+09, tolerance = 0,
            next fire date = 453098071 (-4421.76019 @ 96223387169499),
            callout = _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv (QuartzCore.framework)}
    },
 
    modes ＝ {
        CFRunLoopMode  {
            sources0 =  { /* same as 'common mode items' */ },
            sources1 =  { /* same as 'common mode items' */ },
            observers = { /* same as 'common mode items' */ },
            timers =    { /* same as 'common mode items' */ },
        },
 
        CFRunLoopMode  {
            sources0 =  { /* same as 'common mode items' */ },
            sources1 =  { /* same as 'common mode items' */ },
            observers = { /* same as 'common mode items' */ },
            timers =    { /* same as 'common mode items' */ },
        },
 
        CFRunLoopMode  {
            sources0 = {
                CFRunLoopSource {order = 0, {
                    callout = FBSSerialQueueRunLoopSourceHandler}}
            },
            sources1 = (null),
            observers = {
                CFRunLoopObserver >{activities = 0xa0, order = 2000000,
                    callout = _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv}
            )},
            timers = (null),
        },
 
        CFRunLoopMode  {
            sources0 = {
                CFRunLoopSource {order = -1, {
                    callout = PurpleEventSignalCallback}}
            },
            sources1 = {
                CFRunLoopSource {order = -1, {
                    callout = PurpleEventCallback}}
            },
            observers = (null),
            timers = (null),
        },
        
        CFRunLoopMode  {
            sources0 = (null),
            sources1 = (null),
            observers = (null),
            timers = (null),
        }
    }
}

可以看到留荔，系統(tǒng)默認注冊了5個Mode：

1吟孙、kCFRunLoopDefaultMode：App 的默認 Mode，通常主線程是在這個 Mode 下運行的聚蝶。
2杰妓、UITrackingRunLoopMode：界面跟蹤 Mode，用于 ScrollView 追蹤觸摸滑動碘勉，保證界面滑動時不受其他 Mode 影響巷挥。
3、UIInitializationRunLoopMode：在剛啟動 App 時第進入的第一個 Mode验靡，啟動完成后就不再使用倍宾。
4、GSEventReceiveRunLoopMode：接受系統(tǒng)事件的內(nèi)部 Mode胜嗓，通常用不到高职。
5、kCFRunLoopCommonModes：這是一個占位的 Mode兼蕊，沒有實際作用初厚。

你可以在這里看到更多的蘋果內(nèi)部的 Mode，但那些 Mode 在開發(fā)中就很難遇到了孙技。

當 RunLoop 進行回調(diào)時产禾，一般都是通過一個很長的函數(shù)調(diào)用出去 (call out), 當你在你的代碼中下斷點調(diào)試時，通常能在調(diào)用棧上看到這些函數(shù)牵啦。下面是這幾個函數(shù)的整理版本亚情，如果你在調(diào)用棧中看到這些長函數(shù)名，在這里查找一下就能定位到具體的調(diào)用地點了：

{
    /// 1. 通知 Observers哈雏，即將進入 RunLoop
    /// 此處有 Observer 會創(chuàng)建 AutoreleasePool: _objc_autoreleasePoolPush();
    __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
    do {
 
        /// 2. 通知 Observers: 即將觸發(fā) Timer 回調(diào)楞件。
        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
        /// 3. 通知 Observers: 即將觸發(fā) Source (非基于 port 的 Source0) 回調(diào)。
        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
 
        /// 4. 觸發(fā) Source0 (非基于 port  的) 回調(diào)裳瘪。
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0);
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
 
        /// 6. 通知Observers土浸，即將進入休眠
        /// 此處有 Observer 釋放并新建 AutoreleasePool: _objc_autoreleasePoolPop(); _objc_autoreleasePoolPush();
        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeWaiting);
 
        /// 7. sleep to wait msg.
        mach_msg() -> mach_msg_trap();
        
        /// 8. 通知 Observers，線程被喚醒
        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopAfterWaiting);
 
        /// 9. 如果是被Timer喚醒的彭羹，回調(diào)Timer
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);
 
        /// 9. 如果是被 dispatch 喚醒的黄伊，執(zhí)行所有調(diào)用 dispatch_async 等方法放入 main queue 的 block
        __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(dispatched_block);
 
        /// 9. 如果如果 Runloop 是被 Source1 (基于 port 的) 的事件喚醒了，處理這個事件
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__(source1);
 
    } while (...);
 
    /// 10. 通知 Observers派殷，即將退出 RunLoop
    /// 此處有 Observer 釋放 AutoreleasePool: _objc_autoreleasePoolPop();
    __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopExit);
}

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

事件響應(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 界面套蒂。

這個函數(shù)內(nèi)部的調(diào)用棧大概是這樣的：

_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];

定時器

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ò)請求

iOS 中砰识，關(guān)于網(wǎng)絡(luò)請求的接口自下至上有如下幾層:

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

1能扒、CFSocket 是最底層的接口，只負責 socket 通信辫狼。

2初斑、CFNetwork 是基于 CFSocket 等接口的上層封裝，ASIHttpRequest 工作于這一層膨处。

3见秤、NSURLConnection 是基于 CFNetwork 的更高層的封裝，提供面向?qū)ο蟮慕涌谡娲唬珹FNetworking 工作于這一層鹃答。

4、NSURLSession 是 iOS7 中新增的接口突硝，表面上是和 NSURLConnection 并列的测摔，但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)，AFNetworking2 和 Alamofire 工作于這一層。

下面主要介紹下 NSURLConnection 的工作過程锋八。

通常使用 NSURLConnection 時浙于，你會傳入一個 Delegate，當調(diào)用了 [connection start] 后挟纱，這個 Delegate 就會不停收到事件回調(diào)羞酗。實際上，start 這個函數(shù)的內(nèi)部會會獲取 CurrentRunLoop樊销，然后在其中的 DefaultMode 添加了4個 Source0 (即需要手動觸發(fā)的 Source)整慎。CFMultiplexerSource 是負責各種 Delegate 回調(diào)的，CFHTTPCookieStorage 是處理各種 Cookie 的围苫。

當開始網(wǎng)絡(luò)傳輸時裤园，我們可以看到 NSURLConnection 創(chuàng)建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的剂府。NSURLConnectionLoader 這個線程內(nèi)部會使用 RunLoop 來接收底層 socket 的事件拧揽，并通過之前添加的 Source0 通知到上層的 Delegate。

NSURLConnectionLoader 中的 RunLoop 通過一些基于 mach port 的 Source 接收來自底層 CFSocket 的通知腺占。當收到通知后淤袜，其會在合適的時機向 CFMultiplexerSource 等 Source0 發(fā)送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知衰伯。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執(zhí)行實際的回調(diào)铡羡。

RunLoop 的實際應(yīng)用舉例

AFNetworking

AFURLConnectionOperation 這個類是基于 NSURLConnection 構(gòu)建的，其希望能在后臺線程接收 Delegate 回調(diào)意鲸。為此 AFNetworking 單獨創(chuàng)建了一個線程烦周，并在這個線程中啟動了一個 RunLoop：

+ (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 啟動前內(nèi)部必須要有至少一個 Timer/Observer/Source，所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個新的 NSMachPort 添加進去了怎顾。通常情況下读慎，調(diào)用者需要持有這個 NSMachPort (mach_port) 并在外部線程通過這個 port 發(fā)送消息到 loop 內(nèi)；但此處添加 port 只是為了讓 RunLoop 不至于退出槐雾，并沒有用于實際的發(fā)送消息夭委。

- (void)start {
    [self.lock lock];
    if ([self isCancelled]) {
        [self performSelector:@selector(cancelConnection) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    } else if ([self isReady]) {
        self.state = AFOperationExecutingState;
        [self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    }
    [self.lock unlock];
}

當需要這個后臺線程執(zhí)行任務(wù)時，AFNetworking 通過調(diào)用 [NSObject performSelector:onThread:..] 將這個任務(wù)扔到了后臺線程的 RunLoop 中募强。

AsyncDisplayKit

AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架株灸，其原理大致如下：

UI 線程中一旦出現(xiàn)繁重的任務(wù)就會導致界面卡頓，這類任務(wù)通常分為3類：排版钻注，繪制蚂且，UI對象操作。

• 排版通常包括計算視圖大小幅恋、計算文本高度杏死、重新計算子式圖的排版等操作。
• 繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預先解壓)淑翼、元素繪制 (Quartz) 等操作腐巢。
• UI對象操作通常包括 UIView/CALayer 等 UI 對象的創(chuàng)建、設(shè)置屬性和銷毀玄括。

其中前兩類操作可以通過各種方法扔到后臺線程執(zhí)行冯丙，而最后一類操作只能在主線程完成，并且有時后面的操作需要依賴前面操作的結(jié)果 （例如T extView 創(chuàng)建時可能需要提前計算出文本的大性饩）胃惜。ASDK 所做的，就是盡量將能放入后臺的任務(wù)放入后臺哪雕，不能的則盡量推遲 (例如視圖的創(chuàng)建船殉、屬性的調(diào)整)。

為此斯嚎，ASDK 創(chuàng)建了一個名為 ASDisplayNode 的對象利虫，并在內(nèi)部封裝了 UIView/CALayer，它具有和 UIView/CALayer 相似的屬性堡僻，例如 frame糠惫、backgroundColor等。所有這些屬性都可以在后臺線程更改钉疫，開發(fā)者可以只通過 Node 來操作其內(nèi)部的 UIView/CALayer硼讽，這樣就可以將排版和繪制放入了后臺線程。但是無論怎么操作牲阁，這些屬性總需要在某個時刻同步到主線程的 UIView/CALayer 去理郑。

ASDK 仿照 QuartzCore/UIKit 框架的模式，實現(xiàn)了一套類似的界面更新的機制：即在主線程的 RunLoop 中添加一個 Observer咨油，監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件，在收到回調(diào)時柒爵，遍歷所有之前放入隊列的待處理的任務(wù)役电，然后一一執(zhí)行。

具體的代碼可以看這里：_ASAsyncTransactionGroup棉胀。

開發(fā)中常見 RunLoop 使用

上文中介紹了蘋果官方和常見的第三方類庫對 RunLoop 的使用法瑟，但是，我們實際應(yīng)用最多的可能會是下面這些具體場景唁奢。

1霎挟、UIImageView 延遲加載圖片

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

實際上這個時候我們就會碰到問題熬北，因為我們的 UITableView 是可以任意拖動的疙描，所以如果不更改 NSURLConnection 的運行模式，那么只要 UITableView 出現(xiàn)滑動讶隐，NSURLConnection 所在的DefaultMode 就會退出起胰，切換到 UITrackingRunLoopMode 。

給 UIImageView 設(shè)置圖片可能耗時不少巫延，如果此時要滑動 UITableView 等效五，則可能影響到界面的流暢。

解決是：使用 performSelector:withObject:afterDelay:inModes: 方法炉峰，將設(shè)置圖片的方法放到 DefaultMode 中執(zhí)行畏妖。

為了流暢性，把圖片加載延遲讲冠。

2瓜客、UITableView 與 NSTimer 沖突

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

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

可以兩個解決方法：（目的就是：即使 mode 切換疯攒，計時器也依然工作）

此處參考：iOS下RunLoop的實際應(yīng)用場景探究

RunLoop 面試題

一、什么是RunLoop列荔？

• 從字面意思看就是運行循環(huán)敬尺，其實內(nèi)部就是 do－while 循環(huán)，這個循環(huán)內(nèi)部不斷地處理各種任務(wù)（比如 Source贴浙，Timer砂吞，Observer）。
• 一個線程對應(yīng)一個 RunLoop崎溃，主線程的 RunLoop 默認已經(jīng)啟動蜻直，子線程的 RunLoop 需要手動啟動（調(diào)用 run 方法）。
• RunLoop 只能選擇一個 Mode 啟動袁串，如果當前 Mode 中沒有任何Source概而，Timer，Observer囱修，那么就直接退出 RunLoop赎瑰。
• 基本的作用就是保持程序的持續(xù)運行，處理 App 中的各種事件破镰。通過 Runloop餐曼，有事運行压储，沒事就休息，可以節(jié)省 CPU 資源晋辆，提高程序性能渠脉。

二、你在開發(fā)過程中怎么使用 RunLoop瓶佳？什么應(yīng)用場景芋膘？

• 開啟一個常駐線程（讓一個子線程不進入消亡狀態(tài)，等待其他線程發(fā)來的消息霸饲，處理其他事件）
• 在子線程中開啟一個定時器
• 在子線程中進行一些長期監(jiān)控
• 可以控制定時器在特定模式下運行
• 可以讓某些事件（行為为朋，任務(wù)）在特定模式下執(zhí)行
• 可以添加 Observer 監(jiān)聽 RunLoop 的狀態(tài)，比如監(jiān)聽點擊事件的處理（比如在所有點擊事件前做一些處理）

三厚脉、自動釋放池什么時候釋放习寸？

• 在 RunLoop 睡眠之前釋放（kCFRunLoopBeforeWaiting）

參考

• 深入理解RunLoop - ibireme
• RunLoop 詳解 - Gang Yang
• RunLoop 原理+使用場景+面試總結(jié)
• RunLoop詳解面試題(面試必備NSTimer)
• iOS RunLoop面試題
• 官方文檔
• CFRunLoop.c

點贊+關(guān)注，第一時間獲取技術(shù)干貨和最新知識點傻工，謝謝你的支持霞溪！

最后祝大家生活愉快~