iOS面試題:猜想 runloop 內(nèi)部是如何實(shí)現(xiàn)的?

一般來講崔涂,一個(gè)線程一次只能執(zhí)行一個(gè)任務(wù)阳掐,執(zhí)行完成后線程就會(huì)退出。如果我們需要一個(gè)機(jī)制冷蚂,讓線程能隨時(shí)處理事件但并不退出缭保,通常的代碼邏輯 是這樣的:

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

其內(nèi)容運(yùn)行的邏輯大致如圖所示:

可以看到,實(shí)際上 RunLoop 就是這樣一個(gè)函數(shù)蝙茶,其內(nèi)部是一個(gè) do-while 循環(huán)艺骂。當(dāng)你調(diào)用 CFRunLoopRun() 時(shí),線程就會(huì)一直停留在這個(gè)循環(huán)里隆夯;直到超時(shí)或被手動(dòng)停止钳恕,該函數(shù)才會(huì)返回。

首先我們可以看一下 App 啟動(dòng)后 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)默認(rèn)注冊(cè)了 5 個(gè) Mode:

  • 1忧额、kCFRunLoopDefaultMode: App的默認(rèn) Mode,通常主線程是在這個(gè) Mode 下運(yùn)行的愧口。
  • 2睦番、UITrackingRunLoopMode: 界面跟蹤 Mode,用于 ScrollView 追蹤觸摸滑動(dòng),保證界面滑動(dòng)時(shí)不受其他 Mode 影響托嚣。
  • 3巩检、UIInitializationRunLoopMode: 在剛啟動(dòng) App 時(shí)第進(jìn)入的第一個(gè) Mode,啟動(dòng)完成后就不再使用示启。
  • 4兢哭、GSEventReceiveRunLoopMode: 接受系統(tǒng)事件的內(nèi)部 Mode,通常用不到丑搔。
  • 5厦瓢、kCFRunLoopCommonModes: 這是一個(gè)占位的 Mode,沒有實(shí)際作用啤月。

當(dāng) RunLoop 進(jìn)行回調(diào)時(shí)煮仇,一般都是通過一個(gè)很長的函數(shù)調(diào)用出去 (call out), 當(dāng)你在你的代碼中下斷點(diǎn)調(diào)試時(shí),通常能在調(diào)用棧上看到這些函數(shù)谎仲。下面是這幾個(gè)函數(shù)的整理版本浙垫,如果你在調(diào)用棧中看到這些長函數(shù)名,在這里查找一下就能定位到具體的調(diào)用地點(diǎn)了:

    {
        /// 1. 通知Observers郑诺,即將進(jìn)入RunLoop
        /// 此處有Observer會(huì)創(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辙售,即將進(jìn)入休眠
            /// 此處有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的) 的事件喚醒了,處理這個(gè)事件
            __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);
    }

幾個(gè)相關(guān)特性的實(shí)現(xiàn):

幾個(gè)相關(guān)特性的實(shí)現(xiàn):
AutoreleasePool

App啟動(dòng)后士八,蘋果在主線程 RunLoop 里注冊(cè)了兩個(gè) Observer,其回調(diào)都是 _wrapRunLoopWithAutoreleasePoolHandler()梁呈。

第一個(gè) Observer 監(jiān)視的事件是 Entry(即將進(jìn)入 Loop)婚度,其回調(diào)內(nèi)會(huì)調(diào)用 _objc_autoreleasePoolPush()創(chuàng)建自動(dòng)釋放池。其 order 是-2147483647官卡,優(yōu)先級(jí)最高蝗茁,保證創(chuàng)建釋放池發(fā)生在其他所有回調(diào)之前。

第二個(gè) Observer 監(jiān)視了兩個(gè)事件: BeforeWaiting(準(zhǔn)備進(jìn)入休眠) 時(shí)調(diào)用_objc_autoreleasePoolPop()_objc_autoreleasePoolPush()釋放舊的池并創(chuàng)建新池寻咒;Exit(即將退出 Loop) 時(shí)調(diào)用 _objc_autoreleasePoolPop()來釋放自動(dòng)釋放池评甜。這個(gè) Observer 的 order 是 2147483647,優(yōu)先級(jí)最低仔涩,保證其釋放池子發(fā)生在其他所有回調(diào)之后忍坷。

在主線程執(zhí)行的代碼,通常是寫在諸如事件回調(diào)、Timer 回調(diào)內(nèi)的佩研。這些回調(diào)會(huì)被 RunLoop 創(chuàng)建好的 AutoreleasePool 環(huán)繞著柑肴,所以不會(huì)出現(xiàn)內(nèi)存泄漏,開發(fā)者也不必顯示創(chuàng)建 Pool 了旬薯。

事件響應(yīng)

蘋果注冊(cè)了一個(gè) Source1 (基于 mach port 的) 用來接收系統(tǒng)事件晰骑,其回調(diào)函數(shù)為 __IOHIDEventSystemClientQueueCallback()

當(dāng)一個(gè)硬件事件(觸摸/鎖屏/搖晃等)發(fā)生后绊序,首先由 IOKit.framework 生成一個(gè) IOHIDEvent 事件并由 SpringBoard 接收硕舆。這個(gè)過程的詳細(xì)情況可以參考這里。SpringBoard 只接收按鍵(鎖屏/靜音等)骤公,觸摸抚官,加速,接近傳感器等幾種 Event阶捆,隨后用 mach port 轉(zhuǎn)發(fā)給需要的App進(jìn)程凌节。隨后蘋果注冊(cè)的那個(gè) Source1 就會(huì)觸發(fā)回調(diào),并調(diào)用 _UIApplicationHandleEventQueue() 進(jìn)行應(yīng)用內(nèi)部的分發(fā)洒试。

_UIApplicationHandleEventQueue() 會(huì)把 IOHIDEvent 處理并包裝成 UIEvent 進(jìn)行處理或分發(fā)倍奢,其中包括識(shí)別 UIGesture/處理屏幕旋轉(zhuǎn)/發(fā)送給 UIWindow 等。通常事件比如 UIButton 點(diǎn)擊垒棋、touchesBegin/Move/End/Cancel 事件都是在這個(gè)回調(diào)中完成的卒煞。

手勢(shì)識(shí)別

當(dāng)上面的 _UIApplicationHandleEventQueue() 識(shí)別了一個(gè)手勢(shì)時(shí),其首先會(huì)調(diào)用 Cancel 將當(dāng)前的 touchesBegin/Move/End 系列回調(diào)打斷叼架。隨后系統(tǒng)將對(duì)應(yīng)的 UIGestureRecognizer 標(biāo)記為待處理畔裕。

蘋果注冊(cè)了一個(gè) Observer 監(jiān)測(cè) BeforeWaiting (Loop 即將進(jìn)入休眠) 事件,這個(gè) Observer 的回調(diào)函數(shù)是 _UIGestureRecognizerUpdateObserver()碉碉,其內(nèi)部會(huì)獲取所有剛被標(biāo)記為待處理的 GestureRecognizer,并執(zhí)行 GestureRecognizer 的回調(diào)淮韭。

當(dāng)有 UIGestureRecognizer 的變化(創(chuàng)建/銷毀/狀態(tài)改變)時(shí)垢粮,這個(gè)回調(diào)都會(huì)進(jìn)行相應(yīng)處理。

界面更新

當(dāng)在操作 UI 時(shí)靠粪,比如改變了 Frame蜡吧、更新了 UIView/CALayer 的層次時(shí),或者手動(dòng)調(diào)用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后占键,這個(gè) UIView/CALayer 就被標(biāo)記為待處理昔善,并被提交到一個(gè)全局的容器去。

蘋果注冊(cè)了一個(gè) Observer 監(jiān)聽 BeforeWaiting(即將進(jìn)入休眠) 和 Exit (即將退出 Loop) 事件畔乙,回調(diào)去執(zhí)行一個(gè)很長的函數(shù): _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()君仆。這個(gè)函數(shù)里會(huì)遍歷所有待處理的 UIView/CAlayer 以執(zhí)行實(shí)際的繪制和調(diào)整,并更新 UI 界面。

這個(gè)函數(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];

定時(shí)器

NSTimer 其實(shí)就是 CFRunLoopTimerRef返咱,他們之間是 toll-free bridged 的钥庇。NSTimer 是用了 XNU 內(nèi)核的 mk_timer 驅(qū)動(dòng),而非 GCD 驅(qū)動(dòng)的咖摹。

一個(gè) NSTimer 注冊(cè)到 RunLoop 后评姨,RunLoop 會(huì)為其重復(fù)的時(shí)間點(diǎn)注冊(cè)好事件。例如 10:00, 10:10, 10:20 這幾個(gè)時(shí)間點(diǎn)萤晴。RunLoop 為了節(jié)省資源吐句,并不會(huì)在非常準(zhǔn)確的時(shí)間點(diǎn)回調(diào)這個(gè) Timer。Timer 有個(gè)屬性叫做 Tolerance (寬容度)店读,標(biāo)示了當(dāng)時(shí)間點(diǎn)到后嗦枢,容許有多少最大誤差。

如果某個(gè)時(shí)間點(diǎn)被錯(cuò)過了两入,例如執(zhí)行了一個(gè)很長的任務(wù)净宵,則那個(gè)時(shí)間點(diǎn)的回調(diào)也會(huì)跳過去,不會(huì)延后執(zhí)行裹纳。就比如等公交择葡,如果 10:10 時(shí)我忙著玩手機(jī)錯(cuò)過了那個(gè)點(diǎn)的公交,那我只能等 10:20 這一趟了剃氧。

CADisplayLink 是一個(gè)和屏幕刷新率一致的定時(shí)器(但實(shí)際實(shí)現(xiàn)原理更復(fù)雜敏储,和 NSTimer 并不一樣,其內(nèi)部實(shí)際是操作了一個(gè) Source)朋鞍。如果在兩次屏幕刷新之間執(zhí)行了一個(gè)長任務(wù)已添,那其中就會(huì)有一幀被跳過去(和 NSTimer 相似),造成界面卡頓的感覺滥酥。在快速滑動(dòng) TableView時(shí)更舞,即使一幀的卡頓也會(huì)讓用戶有所察覺。Facebook 開源的 AsyncDisplayLink 就是為了解決界面卡頓的問題坎吻,其內(nèi)部也用到了 RunLoop缆蝉。

PerformSelector

當(dāng)調(diào)用 NSObject 的 performSelector:afterDelay: 后,實(shí)際上其內(nèi)部會(huì)創(chuàng)建一個(gè) Timer 并添加到當(dāng)前線程的 RunLoop 中瘦真。所以如果當(dāng)前線程沒有 RunLoop刊头,則這個(gè)方法會(huì)失效。

當(dāng)調(diào)用 performSelector:onThread: 時(shí)诸尽,實(shí)際上其會(huì)創(chuàng)建一個(gè) Timer 加到對(duì)應(yīng)的線程去原杂,同樣的,如果對(duì)應(yīng)線程沒有 RunLoop 該方法也會(huì)失效您机。

關(guān)于 GCD

實(shí)際上 RunLoop 底層也會(huì)用到 GCD 的東西穿肄。但同時(shí) GCD 提供的某些接口也用到了 RunLoop年局,例如 dispatch_async()

當(dāng)調(diào)用 dispatch_async(dispatch_get_main_queue(), block) 時(shí)被碗,libDispatch 會(huì)向主線程的 RunLoop 發(fā)送消息某宪,RunLoop 會(huì)被喚醒,并從消息中取得這個(gè) block锐朴,并在回調(diào) __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 里執(zhí)行這個(gè) block兴喂。但這個(gè)邏輯僅限于 dispatch 到主線程,dispatch 到其他線程仍然是由 libDispatch 處理的焚志。

關(guān)于網(wǎng)絡(luò)請(qǐng)求

iOS 中衣迷,關(guān)于網(wǎng)絡(luò)請(qǐng)求的接口自下至上有如下幾層:

  • CFSocket,是最底層的接口酱酬,只負(fù)責(zé) socket 通信壶谒。
  • CFNetwork,是基于 CFSocket 等接口的上層封裝膳沽,ASIHttpRequest 工作于這一層汗菜。
  • NSURLConnection,是基于 CFNetwork 的更高層的封裝挑社,提供面向?qū)ο蟮慕涌谠山纾珹FNetworking 工作于這一層。
  • NSURLSession痛阻,是 iOS7 中新增的接口菌瘪,表面上是和 NSURLConnection 并列的,但底層仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 線程)阱当,AFNetworking2 和 Alamofire 工作于這一層俏扩。

NSURLConnection 的工作過程:

通常使用 NSURLConnection 時(shí),你會(huì)傳入一個(gè) Delegate弊添,當(dāng)調(diào)用了 [connection start] 后录淡,這個(gè) Delegate 就會(huì)不停收到事件回調(diào)。實(shí)際上油坝,start 這個(gè)函數(shù)的內(nèi)部會(huì)會(huì)獲取 CurrentRunLoop嫉戚,然后在其中的 DefaultMode 添加了 4 個(gè) Source0 (即需要手動(dòng)觸發(fā)的Source)。CFMultiplexerSource 是負(fù)責(zé)各種 Delegate 回調(diào)的免钻,CFHTTPCookieStorage 是處理各種 Cookie 的彼水。

當(dāng)開始網(wǎng)絡(luò)傳輸時(shí)崔拥,我們可以看到 NSURLConnection 創(chuàng)建了兩個(gè)新線程:com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 連接的链瓦。NSURLConnectionLoader 這個(gè)線程內(nèi)部會(huì)使用 RunLoop 來接收底層 socket 的事件拆魏,并通過之前添加的 Source0 通知到上層的 Delegate盯桦。

NSURLConnectionLoader 中的 RunLoop 通過一些基于 mach port 的 Source 接收來自底層 CFSocket 的通知。當(dāng)收到通知后渤刃,其會(huì)在合適的時(shí)機(jī)向 CFMultiplexerSource 等 Source0 發(fā)送通知拥峦,同時(shí)喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會(huì)在 Delegate 線程的 RunLoop 對(duì) Delegate 執(zhí)行實(shí)際的回調(diào)卖子。

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

1)AFNetworking

AFNetworking 中的 AFURLConnectionOperation這個(gè)類是基于 NSURLConnection 構(gòu)建的略号,其希望能在后臺(tái)線程接收 Delegate 回調(diào)。為此 AFNetworking 單獨(dú)創(chuàng)建了一個(gè)線程洋闽,并在這個(gè)線程中啟動(dòng)了一個(gè) 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 啟動(dòng)前內(nèi)部必須要有至少一個(gè) Timer/Observer/Source玄柠,所以 AFNetworking 在 [runLoop run] 之前先創(chuàng)建了一個(gè)新的 NSMachPort 添加進(jìn)去了。通常情況下诫舅,調(diào)用者需要持有這個(gè) NSMachPort (mach_port) 并在外部線程通過這個(gè) port 發(fā)送消息到 loop 內(nèi)羽利;但此處添加 port 只是為了讓 RunLoop 不至于退出,并沒有用于實(shí)際的發(fā)送消息刊懈。

當(dāng)需要這個(gè)后臺(tái)線程執(zhí)行任務(wù)時(shí)这弧,AFNetworking 通過調(diào)用 [NSObject performSelector:onThread:..] 將這個(gè)任務(wù)扔到了后臺(tái)線程的 RunLoop 中。

2)AsyncDisplayKit

AsyncDisplayKit 是 Facebook 推出的用于保持界面流暢性的框架虚汛,其原理大致如下:

UI 線程中一旦出現(xiàn)繁重的任務(wù)就會(huì)導(dǎo)致界面卡頓匾浪,這類任務(wù)通常分為3類:排版,繪制泽疆,UI對(duì)象操作户矢。

排版通常包括計(jì)算視圖大小、計(jì)算文本高度殉疼、重新計(jì)算子式圖的排版等操作梯浪。 繪制一般有文本繪制 (例如 CoreText)、圖片繪制 (例如預(yù)先解壓)瓢娜、元素繪制 (Quartz)等操作挂洛。 UI對(duì)象操作通常包括 UIView/CALayer 等 UI 對(duì)象的創(chuàng)建、設(shè)置屬性和銷毀眠砾。

其中前兩類操作可以通過各種方法扔到后臺(tái)線程執(zhí)行虏劲,而最后一類操作只能在主線程完成,并且有時(shí)后面的操作需要依賴前面操作的結(jié)果 (例如TextView創(chuàng)建時(shí)可能需要提前計(jì)算出文本的大邪薄)柒巫。ASDK 所做的,就是盡量將能放入后臺(tái)的任務(wù)放入后臺(tái)谷丸,不能的則盡量推遲 (例如視圖的創(chuàng)建堡掏、屬性的調(diào)整)。

為此刨疼,ASDK 創(chuàng)建了一個(gè)名為 ASDisplayNode 的對(duì)象泉唁,并在內(nèi)部封裝了 UIView/CALayer鹅龄,它具有和 UIView/CALayer 相似的屬性,例如 frame亭畜、backgroundColor等扮休。所有這些屬性都可以在后臺(tái)線程更改,開發(fā)者可以只通過 Node 來操作其內(nèi)部的 UIView/CALayer拴鸵,這樣就可以將排版和繪制放入了后臺(tái)線程玷坠。但是無論怎么操作,這些屬性總需要在某個(gè)時(shí)刻同步到主線程的 UIView/CALayer 去劲藐。

ASDK 仿照 QuartzCore/UIKit 框架的模式侨糟,實(shí)現(xiàn)了一套類似的界面更新的機(jī)制:即在主線程的 RunLoop 中添加一個(gè) Observer,監(jiān)聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件瘩燥,在收到回調(diào)時(shí)秕重,遍歷所有之前放入隊(duì)列的待處理的任務(wù),然后一一執(zhí)行厉膀。


更多:iOS面試題合集

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末溶耘,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子服鹅,更是在濱河造成了極大的恐慌凳兵,老刑警劉巖,帶你破解...
    沈念sama閱讀 218,640評(píng)論 6 507
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件企软,死亡現(xiàn)場(chǎng)離奇詭異庐扫,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī)仗哨,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,254評(píng)論 3 395
  • 文/潘曉璐 我一進(jìn)店門形庭,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人厌漂,你說我怎么就攤上這事萨醒。” “怎么了苇倡?”我有些...
    開封第一講書人閱讀 165,011評(píng)論 0 355
  • 文/不壞的土叔 我叫張陵富纸,是天一觀的道長。 經(jīng)常有香客問我旨椒,道長晓褪,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,755評(píng)論 1 294
  • 正文 為了忘掉前任综慎,我火速辦了婚禮涣仿,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘寥粹。我一直安慰自己变过,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,774評(píng)論 6 392
  • 文/花漫 我一把揭開白布涝涤。 她就那樣靜靜地躺著媚狰,像睡著了一般。 火紅的嫁衣襯著肌膚如雪阔拳。 梳的紋絲不亂的頭發(fā)上崭孤,一...
    開封第一講書人閱讀 51,610評(píng)論 1 305
  • 那天,我揣著相機(jī)與錄音糊肠,去河邊找鬼辨宠。 笑死,一個(gè)胖子當(dāng)著我的面吹牛货裹,可吹牛的內(nèi)容都是我干的嗤形。 我是一名探鬼主播,決...
    沈念sama閱讀 40,352評(píng)論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼弧圆,長吁一口氣:“原來是場(chǎng)噩夢(mèng)啊……” “哼赋兵!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起搔预,我...
    開封第一講書人閱讀 39,257評(píng)論 0 276
  • 序言:老撾萬榮一對(duì)情侶失蹤霹期,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后拯田,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體历造,經(jīng)...
    沈念sama閱讀 45,717評(píng)論 1 315
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,894評(píng)論 3 336
  • 正文 我和宋清朗相戀三年船庇,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了吭产。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 40,021評(píng)論 1 350
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡鸭轮,死狀恐怖垮刹,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情张弛,我是刑警寧澤荒典,帶...
    沈念sama閱讀 35,735評(píng)論 5 346
  • 正文 年R本政府宣布,位于F島的核電站吞鸭,受9級(jí)特大地震影響寺董,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜刻剥,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,354評(píng)論 3 330
  • 文/蒙蒙 一遮咖、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧造虏,春花似錦御吞、人聲如沸麦箍。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,936評(píng)論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽挟裂。三九已至,卻和暖如春揍诽,著一層夾襖步出監(jiān)牢的瞬間诀蓉,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,054評(píng)論 1 270
  • 我被黑心中介騙來泰國打工暑脆, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留渠啤,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 48,224評(píng)論 3 371
  • 正文 我出身青樓添吗,卻偏偏與公主長得像沥曹,于是被迫代替她去往敵國和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子碟联,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,974評(píng)論 2 355

推薦閱讀更多精彩內(nèi)容

  • 前言 RunLoop是iOS和OSX開發(fā)中非臣茏ǎ基礎(chǔ)的一個(gè)概念,這篇文章將從CFRunLoop的源碼入手玄帕,介紹Run...
    暮年古稀ZC閱讀 2,243評(píng)論 1 19
  • 轉(zhuǎn)載:http://www.cocoachina.com/ios/20150601/11970.html RunL...
    Gatling閱讀 1,438評(píng)論 0 13
  • 轉(zhuǎn)自bireme部脚,原地址:https://blog.ibireme.com/2015/05/18/runloop/...
    乜_啊_閱讀 1,374評(píng)論 0 5
  • 轉(zhuǎn)自http://blog.ibireme.com/2015/05/18/runloop 深入理解RunLoop ...
    飄金閱讀 983評(píng)論 0 4
  • 最近,腦海里經(jīng)常浮現(xiàn)自己退休后裤纹,穿著旗袍在鄉(xiāng)村間優(yōu)雅地活著委刘。或散步鹰椒,或買菜锡移,或拉家常,或打麻將等等漆际。然后想找事情做...
    果彭閱讀 42評(píng)論 0 0