一、RunLoop基礎

        一條線程正常情況下在其涉及的任務執行完畢之後，就會自動退出執行。但是我們一個App啓動之後，其主線程卻能夠一直保持存活，這就是因爲主線程有一個Runloop。從上面描述來看，Runloop具有線程保活的功能；除了線程保活，其他一些重要功能也是基於Runloop來實現的，如，事件處理、自動釋放池、線程休眠等。
        與RunLoop相關的源碼如下（CFRunLoopRef的源碼、跨平臺Runloop的源碼）。
        默認主線程的RunLoop是由系統自動創建的，其他線程沒有與之對應的RunLoop對象。獲取主線程關聯的RunLoop可以調用CFRunLoopGetMain()方法，創建與其他線程相關的RunLoop需要調用CFRunLoopGetCurrent()方法。這兩個函數的內部實現類似如下代碼：

/// 全局的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常見的有兩種，NSRunLoop和CFRunnLoop。CFRunLoopRef 是在 CoreFoundation 框架內的，它提供了純 C 函數的 API，所有這些 API 都是線程安全的。
NSRunLoop 是基於 CFRunLoopRef 的封裝，提供了面向對象的 API，但是這些 API 不是線程安全的。

二、RunLoop內部實現

2.1 總體結構

在 CoreFoundation 裏面關於 RunLoop 有5個類:

CFRunLoopRef，代表RunLoop
CFRunLoopModeRef，內部使用，沒有對外暴露；一個RunLoop可以有多個Mode，但是當前只有一個Mode起作用
CFRunLoopSourceRef，Mode內部的一種對象
Source有兩個版本：Source0 和 Source1。
Source0 只包含了一個回調（函數指針），它並不能主動觸發事件。使用時，你需要先調用 CFRunLoopSourceSignal(source)，將這個 Source 標記爲待處理，然後手動調用 CFRunLoopWakeUp(runloop) 來喚醒 RunLoop，讓其處理這個事件。
Source1 包含了一個 mach_port 和一個回調（函數指針），被用於通過內核和其他線程相互發送消息。這種 Source 能主動喚醒 RunLoop 的線程，其原理在下面會講到。
CFRunLoopTimerRef，Mode內部的一種對象
它和 NSTimer 是toll-free bridged 的，可以混用。其包含一個時間長度和一個回調（函數指針）。當其加入到 RunLoop 時，RunLoop會註冊對應的時間點，當時間點到時，RunLoop會被喚醒以執行那個回調。
CFRunLoopObserverRef，Mode內部的一種對象
每個 Observer 都包含了一個回調（函數指針），當 RunLoop 的狀態發生變化時，觀察者就能通過回調接受到這個變化；可以監測的狀態如下：

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 被統稱爲 mode item，一個 item 可以被同時加入多個 mode。但一個 item 被重複加入同一個 mode 時是不會有效果的。如果一個 mode 中一個 item 都沒有，則 RunLoop 會直接退出，不進入循環。
每次調用 RunLoop 的主函數時，只能指定其中一個 Mode，這個Mode被稱作 CurrentMode。如果需要切換 Mode，只能退出 Loop，再重新指定一個 Mode 進入。這樣做主要是爲了分隔開不同組的 Source/Timer/Observer，讓其互不影響。

2.2 Mode

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

        這裏有個概念叫 “CommonModes”：一個 Mode 可以將自己標記爲”Common”屬性（通過將其 ModeName 添加到 RunLoop 的 “commonModes” 中）。每當 RunLoop 的內容發生變化時，RunLoop 都會自動將 _commonModeItems 裏的 Source/Observer/Timer 同步到具有 “Common” 標記的所有Mode裏。
        應用場景舉例：主線程的 RunLoop 裏有兩個預置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。這兩個 Mode 都已經被標記爲”Common”屬性。DefaultMode 是 App 平時所處的狀態，TrackingRunLoopMode 是追蹤 ScrollView 滑動時的狀態。當你創建一個 Timer 並加到 DefaultMode 時，Timer 會得到重複回調，但此時滑動一個TableView時，RunLoop 會將 mode 切換爲 TrackingRunLoopMode，這時 Timer 就不會被回調，並且也不會影響到滑動操作。
        有時你需要一個 Timer，在兩個 Mode 中都能得到回調，一種辦法就是將這個 Timer 分別加入這兩個 Mode。還有一種方式，就是將 Timer 加入到頂層的 RunLoop 的 “commonModeItems” 中。”commonModeItems” 被 RunLoop 自動更新到所有具有”Common”屬性的 Mode 裏去。

// 管理Mode的接口
CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);

// 管理 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 來操作內部的 mode，當傳入新的 mode name 但 RunLoop 內部沒有對應 mode 時，RunLoop會自動幫你創建對應的 CFRunLoopModeRef。對於一個 RunLoop 來說，其內部的 mode 只能增加不能刪除。
蘋果公開提供的 Mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode，可以用這兩個 Mode Name 來操作其對應的 Mode。同時蘋果還提供了一個操作 Common 標記的字符串：kCFRunLoopCommonModes (NSRunLoopCommonModes)，你可以用這個字符串來操作 Common Items，或標記一個 Mode 爲 “Common”。使用時注意區分這個字符串和其他 mode name。

2.3 內部實現

根據蘋果在文檔裏的說明，RunLoop 內部的邏輯基本如下:

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

2.4 默認RunLoop

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),
        }
    }
}

可以看到，系統默認註冊了5個Mode:

kCFRunLoopDefaultMode: App的默認 Mode，通常主線程是在這個 Mode 下運行的。
UITrackingRunLoopMode: 界面跟蹤 Mode，用於 ScrollView 追蹤觸摸滑動，保證界面滑動時不受其他 Mode 影響。
UIInitializationRunLoopMode: 在剛啓動 App 時第進入的第一個 Mode，啓動完成後就不再使用。
4: GSEventReceiveRunLoopMode: 接受系統事件的內部 Mode，通常用不到。
5: kCFRunLoopCommonModes: 這是一個佔位的 Mode，沒有實際作用。

三、RunLoop的應用

3.1 自動釋放池

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

3.2 事件響應

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

3.3 手勢識別

        當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時，其首先會調用 Cancel 將當前的 touchesBegin/Move/End 系列回調打斷。隨後系統將對應的 UIGestureRecognizer 標記爲待處理。
        蘋果註冊了一個 Observer 監測 BeforeWaiting (Loop即將進入休眠) 事件，這個Observer的回調函數是 _UIGestureRecognizerUpdateObserver()，其內部會獲取所有剛被標記爲待處理的 GestureRecognizer，並執行GestureRecognizer的回調。
        當有 UIGestureRecognizer 的變化(創建/銷燬/狀態改變)時，這個回調都會進行相應處理。

3.4 界面更新

        當在操作 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];

3.5 定時器

        NSTimer 其實就是 CFRunLoopTimerRef，他們之間是 toll-free bridged 的。一個 NSTimer 註冊到 RunLoop 後，RunLoop 會爲其重複的時間點註冊好事件。例如 10:00, 10:10, 10:20 這幾個時間點。RunLoop爲了節省資源，並不會在非常準確的時間點回調這個Timer。Timer 有個屬性叫做 Tolerance (寬容度)，標示了當時間點到後，容許有多少最大誤差。
        如果某個時間點被錯過了，例如執行了一個很長的任務，則那個時間點的回調也會跳過去，不會延後執行。就比如等公交，如果 10:10 時我忙着玩手機錯過了那個點的公交，那我只能等 10:20 這一趟了。
        CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現原理更復雜，和 NSTimer 並不一樣，其內部實際是操作了一個 Source）。如果在兩次屏幕刷新之間執行了一個長任務，那其中就會有一幀被跳過去（和 NSTimer 相似），造成界面卡頓的感覺。在快速滑動TableView時，即使一幀的卡頓也會讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是爲了解決界面卡頓的問題，其內部也用到了 RunLoop，這個稍後我會再單獨寫一頁博客來分析。

3.6 PerformSelecter

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

3.7 關於GCD

實際上 RunLoop 底層也會用到 GCD 的東西，~~比如 RunLoop 是用 dispatch_source_t 實現的 Timer~~（評論中有人提醒，NSTimer 是用了 XNU 內核的 mk_timer，我也仔細調試了一下，發現 NSTimer 確實是由 mk_timer 驅動，而非 GCD 驅動的）。但同時 GCD 提供的某些接口也用到了 RunLoop，例如 dispatch_async()。
當調用 dispatch_async(dispatch_get_main_queue(), block) 時，libDispatch 會向主線程的 RunLoop 發送消息，RunLoop會被喚醒，並從消息中取得這個 block，並在回調 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 裏執行這個 block。但這個邏輯僅限於 dispatch 到主線程，dispatch 到其他線程仍然是由 libDispatch 處理的。

3.8 關於網絡請求

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

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

通常使用 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。

NSURLConnectionLoader 中的 RunLoop 通過一些基於 mach port 的 Source 接收來自底層 CFSocket 的通知。當收到通知後，其會在合適的時機向 CFMultiplexerSource 等 Source0 發送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執行實際的回調。

備註：
1、非本人原創，根據自己的理解進行了修改，感謝原作者，以下是引用材料
2、https://blog.ibireme.com/2015/05/18/runloop/
3、https://juejin.cn/post/6844903588712415239

iOS-RunLoop 一、RunLoop基礎二、RunLoop內部實現三、RunLoop的應用

一、RunLoop基礎

二、RunLoop內部實現

2.1 總體結構

2.2 Mode

2.3 內部實現

2.4 默認RunLoop

三、RunLoop的應用

3.1 自動釋放池

3.2 事件響應

3.3 手勢識別

3.4 界面更新

3.5 定時器

3.6 PerformSelecter

3.7 關於GCD

3.8 關於網絡請求

[轉帖]cpupower

今天，昨天，近七天，近30天，近90天，js封裝

LLDB全方位剖析

LLDB詳解一、引言二、LLDB命令三、使用LLDB 四、擴展LLDB 四、參考資料

預處理(宏)——想說愛你不容易一、工作中遇到的怪事二、問題詳解三、最佳實現

詳解KVO 一、基本概念二、基本用法三、高級用法四、關於NSKVONotifying_原類型名（簡稱此類爲中間類）

SwiftUI基礎教程（3）第二章：SwiftUI基礎元素實例

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

iOS-RunLoop 一、RunLoop基礎 二、RunLoop內部實現 三、RunLoop的應用

一、RunLoop基礎

二、RunLoop內部實現

2.1 總體結構

2.2 Mode

2.3 內部實現

2.4 默認RunLoop

三、RunLoop的應用

3.1 自動釋放池

3.2 事件響應

3.3 手勢識別

3.4 界面更新

3.5 定時器

3.6 PerformSelecter

3.7 關於GCD

3.8 關於網絡請求

iOS-RunLoop 一、RunLoop基礎二、RunLoop內部實現三、RunLoop的應用