蘋果用 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 了阵漏。

• 事件響應

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

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

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

• 手勢識別

當上面的 _UIApplicationHandleEventQueue() 識別了一個手勢時厢钧，其首先會調(diào)用 Cancel 將當前的 touchesBegin/Move/End 系列回調(diào)打斷。隨后系統(tǒ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)都會進行相應處理拾给。

• 界面更新

當在操作 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í)行了一個很長的任務渠抹，則那個時間點的回調(diào)也會跳過去，不會延后執(zhí)行闪萄。就比如等公交梧却，如果 10:10 時我忙著玩手機錯過了那個點的公交，那我只能等 10:20 這一趟了桃煎。

CADisplayLink 是一個和屏幕刷新率一致的定時器（但實際實現(xiàn)原理更復雜篮幢，和 NSTimer 并不一樣，其內(nèi)部實際是操作了一個 Source）为迈。如果在兩次屏幕刷新之間執(zhí)行了一個長任務三椿，那其中就會有一幀被跳過去（和 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 加到對應的線程去握巢，同樣的，如果對應線程沒有 RunLoop 該方法也會失效松却。

• 關于GCD

實際上 RunLoop 底層也會用到 GCD 的東西暴浦，比如 RunLoop 是用 dispatch_source_t 實現(xiàn)的 Timer（評論中有人提醒，NSTimer 是用了 XNU 內(nèi)核的 mk_timer晓锻，我也仔細調(diào)試了一下歌焦，發(fā)現(xiàn) NSTimer 確實是由 mk_timer 驅動，而非 GCD 驅動的）砚哆。但同時 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 處理的匣吊。

• 關于網(wǎng)絡請求

OS 中，關于網(wǎng)絡請求的接口自下至上有如下幾層:

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 工作于這一層狐血。

下面主要介紹下 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)絡傳輸時，我們可以看到 NSURLConnection 創(chuàng)建了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private劲件。其中 CFSocket 線程是處理底層 socket 連接的掸哑。NSURLConnectionLoader 這個線程內(nèi)部會使用 RunLoop 來接收底層 socket 的事件，并通過之前添加的 Source0 通知到上層的 Delegate零远。

image.png

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