runloop概念

Run loops are part of the fundamental infrastructure associated with threads. A run loop is an event processing loop that you use to schedule work and coordinate the receipt of incoming events. The purpose of a run loop is to keep your thread busy when there is work to do and put your thread to sleep when there is none.

Run loops 是線程中一個基礎的工具，一個run loop 就是一個監聽事件和執行回調的死循環。它主要的作用：1.保持線程存活。2.有事就處理，沒事就睡眠（掛起）

Run loop 默認情況下是停止的，在你創建線程時候要手動去配置監聽事件和啟動runloop，這樣你的線程才能監聽到事件并且產生回調。Cocoa和Core Foundation 框架都提供了配置和管理線程runloop的API（Cocoa中提供的是面向對象的，Core Foundation中提供的是C的API）。你應用的主線程是不需要手動去配置和啟動runloop的，因為framewoks自動幫你完成了。對于二級子線程，則需要你手動去配置和啟動。見NSRunLoop Class Reference 和 CFRunLoop Reference.

解析runloop

函數調用走了一遍就結束了</p>
<pre>
<code>int someFunc() {</code>
<code>// do something</code>
<code> return 0;</code>
<code>}</code>
</pre>

而在 RunLoop 中，要保持線程總是活著，能不斷的處于“接受消息 –> 等待 –> 處理消息”的循環中，則大致邏輯如下
<pre>
<code>int runloop() {</code>
<code>do {</code>
<code> receive_message();</code>
<code>wait();</code>
<code>process_message();</code>
<code> } while (!quit);</code>
<code>return 0;</code>
}
</pre>
在 Xcode 的項目中，main 函數中調用的 UIApplicationMain 函數內部就啟動了一個 RunLoop，保持程序的持續運行，而且這個默認啟動的 RunLoop 的與主線程相關聯的：
<pre>
<code>int main(int argc, char * argv[]) {</code>
<code>@autoreleasepool {</code>
<code> return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));</code>
}
}
<code>//添加一些代碼</code>
<code>int main(int argc, char * argv[]) {</code>
<code> @autoreleasepool {</code>
<code>int result = UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));</code>
<code> // 只要程序在運行，不會運行到下面這句</code>
<code> NSLog(@"after UIApplicationMain");</code>
<code> return result;</code>
}
}
</pre>

類家族

在 CoreFoundation 中關于 RunLoop 有 5 個類：
1.CFRunLoopRef
2.CFRunLoopModeRef
3.CFRunLoopSourceRef
4.CFRunLoopTimerRef
5.CFRunLoopObserverRef
<pre>
<code>// CFRunLoop.h</code>
<code>typedef struct CF_BRIDGED_MUTABLE_TYPE(id) __CFRunLoop * </code>CFRunLoopRef;</code>
<code>typedef struct CF_BRIDGED_MUTABLE_TYPE(id) __CFRunLoopSource * CFRunLoopSourceRef;</code>
<code>typedef struct CF_BRIDGED_MUTABLE_TYPE(id) __CFRunLoopObserver * CFRunLoopObserverRef;</code>
<code>typedef struct CF_BRIDGED_MUTABLE_TYPE(NSTimer) __CFRunLoopTimer * CFRunLoopTimerRef;</code>
<code>// CFRunLoop.c</code>
<code>struct __CFRunLoop {</code>
<code> pthread_t _pthread;</code>
<code> CFMutableSetRef _commonModes;</code>
<code> CFRunLoopModeRef _currentMode;</code>
...
};
<code>struct __CFRunLoopMode {</code>
<code>CFMutableSetRef _sources0;</code>
<code>CFMutableSetRef _sources1;</code>
<code> CFMutableArrayRef _observers;</code>
<code>CFMutableArrayRef _timers;</code>
...
};
</pre>
所以一個 RunLoop 對應一條線程，可以包含若干個 mode，但一個時刻只能在一個 mode 上運行（即 currentMode），要切換 mode 只能退出 loop 再指定一個 mode 后重新進入。每個 mode 可以包含若干個 source/timer/observer，不同組之間的互不影響。這 5 個類的關系大致如下：

類關系

CFRunLoopModeRef

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

一個 run loop mode 是若干個 source、timer 和 observer 的集合，它能幫我們過濾掉一些不想要的事件。即一個 RunLoop 在某個 mode 下運行時，不會接收和處理其他 mode 的事件 。要保持一個 mode 活著，就必須往里面添加至少一個 source、timer 或 observer 。
蘋果公開的 mode 有兩個：kCFRunLoopDefaultMode (NSDefaultRunLoopMode) 和 UITrackingRunLoopMode。前者是默認的模式，程序運行的大多時候都處于該 mode 下，后者是滑動 tableView 等時為了界面流暢而用的 mode。還有個 UIInitializationRunLoopMode 是程序啟動時進入的 mode，一般用不上。
CFRunLoop 還定義了一個偽 mode 叫 kCFRunLoopCommonModes，它不是一個真正的 mode，而是若干個 mode 的集合，加到 CommonMode 的 source/timer/observer 相當于添加到了它里面所有的 mode 中。我們可以通過 NSLog(@"%@", [NSRunLoop currentRunLoop]) 從打印結果看到 CommonMode 包含了上面的 DefaultMode 和 TrackingRunLoopMode：

CFRunLoopSourceRef

source 只有兩個版本：source0 和 source1，它們的區別在于它們是怎么被標記 (signal) 的。source0 是 app 內部的消息機制，使用時需要調用 CFRunLoopSourceSignal()來把這個 source 標記為待處理，然后掉用 CFRunLoopWakeUp() 來喚醒 RunLoop，讓其處理這個事件。

source by apple

<pre><code>void CFRunLoopSourceSignal(CFRunLoopSourceRef rls) {</code>
<code>if (__CFIsValid(rls)) {</code>
<code> __CFRunLoopSourceSetSignaled(rls);</code>
}
}
<code>void CFRunLoopWakeUp(CFRunLoopRef rl) {</code>
<code> if (__CFRunLoopIsIgnoringWakeUps(rl)) {</code>
return;
}
<code>SetEvent(rl->_wakeUpPort);</code>
}</pre>
自己在 touchesBegan... 方法中打斷點，點擊屏幕可以看到調用棧是這樣的：

調用棧

<code>static void CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION();</code>
<code>static void CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK();</code>
<code>static void CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE();</code>
<code>static void CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION();</code>
<code>static void CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION();</code>
</pre>
source1 是基于 mach_ports 的，用于通過內核和其他線程互相發送消息。iOS / OSX 都是基于 Mach 內核，Mach 的對象間的通信是通過消息在兩個端口(port)之間傳遞來完成。很多時候我們的 app 都是處于什么事都不干的狀態，在空閑前指定用于喚醒的 mach port 端口，然后在空閑時被 mach_msg() 函數阻塞著并監聽喚醒端口， mach_msg() 又會調用 mach_msg_trap() 函數從用戶態切換到內核態，這樣系統內核就將這個線程掛起，一直停留在 mac_msg_trap 狀態。直到另一個線程向內核發送這個端口的 msg 后， trap 狀態被喚醒， RunLoop 繼續開始干活
當程序在運行但又空閑的時候，我們可以暫停它，可以看到此時的調用棧是這樣的：

soure1調用棧

runloop內部邏輯

內部邏輯

void CFRunLoopRun(void) {
    CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}</code>
 
/// 用指定的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 的底層實現

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

RunLoop_3

RunLoop_4

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

蘋果用 RunLoop 實現的功能

首先我們可以看一下 App 啟動后 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:1. kCFRunLoopDefaultMode: App的默認 Mode，通常主線程是在這個 Mode 下運行的。2. UITrackingRunLoopMode: 界面跟蹤 Mode，用于 ScrollView 追蹤觸摸滑動，保證界面滑動時不受其他 Mode 影響。3. UIInitializationRunLoopMode: 在剛啟動 App 時第進入的第一個 Mode，啟動完成后就不再使用。4: GSEventReceiveRunLoopMode: 接受系統事件的內部 Mode，通常用不到。5: kCFRunLoopCommonModes: 這是一個占位的 Mode，沒有實際作用。
你可以在這里看到更多的蘋果內部的 Mode，但那些 Mode 在開發中就很難遇到了。
當 RunLoop 進行回調時，一般都是通過一個很長的函數調用出去 (call out), 當你在你的代碼中下斷點調試時，通常能在調用棧上看到這些函數。下面是這幾個函數的整理版本，如果你在調用棧中看到這些長函數名，在這里查找一下就能定位到具體的調用地點了：

{
    /// 1. 通知Observers，即將進入RunLoop
    /// 此處有Observer會創建AutoreleasePool: _objc_autoreleasePoolPush();
    __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);
    do {
 
        /// 2. 通知 Observers: 即將觸發 Timer 回調。
        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);
        /// 3. 通知 Observers: 即將觸發 Source (非基于port的,Source0) 回調。
        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);
 
        /// 4. 觸發 Source0 (非基于port的) 回調。
        __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喚醒的，回調Timer
        __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);
 
        /// 9. 如果是被dispatch喚醒的，執行所有調用 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，其回調都是 _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 了。

事件響應

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

手勢識別

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

響應鏈

界面更新

當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動調用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，這個 UIView/CALayer 就被標記為待處理，并被提交到一個全局的容器去。
蘋果注冊了一個 Observer 監聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調去執行一個很長的函數：_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數里會遍歷所有待處理的 UIView/CAlayer 以執行實際的繪制和調整，并更新 UI 界面。

下期預告：
alibaba-Beehive開源框架源碼分析，其中涉及到編譯連接階段的黑魔法技術和模塊話解耦合。

參考：
CFRunLoop.c
官方文檔
深入理解RunLoop
視頻: iOS線下分享《RunLoop》by 孫源@sunnyxx
Run, RunLoop, Run!
Understanding NSRunLoop