關(guān)于Runloop一些面試題的整理

1.Runloop和線程的關(guān)系？

  • 一個線程對應(yīng)一個Runloop。
  • 主線程默認開啟了Runloop。
  • 子線程的Runloop以懶加載的形式創(chuàng)建。
  • Runloop存儲在一個全局的可變字典里，線程是key，Runloop是value。

2.Runloop的運行模式？

Runloop的運行模式共有5中，Runloop只會運行在一個模式下，要切換模式，就要暫停當(dāng)前模式，重新啟動一個運行模式

1.kCFRunLoopDefaultMode，App的默認運行模式，通常主線程是在這個運行模式下運行
2.UITrackingRunLoopMode，跟蹤用戶交互時間（用于ScrollView追蹤觸摸滑動，保證界面滑動時不受其他Mode影響）
3.kCFRunLoopCommonModes，偽模式，不是一種真正的運行模式
4.UIInitializationRunLoopMode，在剛啟動App時進入的第一個Mode，啟動完成后就不再使用
5.GSEventReceiveRunLoopMode，接受系統(tǒng)內(nèi)部事件，通常用不到

3.Runloop的內(nèi)部邏輯？

  • 實際上Runloop就是這樣一個函數(shù)，其內(nèi)部是一個do-while循環(huán)。當(dāng)你調(diào)用CFRunLoopRun()時，線程就會一直停留在這個循環(huán)里；直到超時或被手動停止，該函數(shù)才會返回。


    image.png
  • 內(nèi)部邏輯
    ° 通知Observer已經(jīng)進入了Runloop
    ° 通知Observer即將處理Timer
    ° 通知Observer即將處理非基于端口的輸入源（即將處理Source0）
    ° 處理那些準(zhǔn)備好的非基于端口的輸入源（處理Source0）
    ° 如果基于端口的輸入源準(zhǔn)備就緒并等待處理，請立刻處理該事件。轉(zhuǎn)到第9步（處理Source1）
    ° 通知Observer線程即將休眠
    ° 將線程置于休眠狀態(tài)，直到發(fā)生以下事件之一
    ■ 事件到達基于端口的輸入源（port-based input sources）（也就是Source0）
    ■ Timer到時間執(zhí)行
    ■ 外部手動喚醒
    ■ 為Runloop設(shè)定的時間超時
    ° 通知Observer線程剛被喚醒（還沒處理事件）
    ° 處理待處理事件
    ■ 如果是Timer事件，處理Timer并重新啟動循環(huán)，跳到第2步
    ■ 如果輸入源被觸發(fā)，處理該事件（文檔上是deliver the event）
    ■ 如果Runloop被手動喚醒但尚未超時，重新啟動循環(huán)，跳到第2步

4.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（準(zhǔn)備進入休眠）時調(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了。

5.GCD在Runloop中的使用？

  • GCD由子線程返回到主線程，只有在這種情況下才會觸發(fā)Runloop。會觸發(fā)Runloop的Source1事件。

6.AFNetworking中如何運用Runloop？

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

+ (void)networkRequestThreadEntryPoint:(id)__unused objct {
    @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];
}
  • 當(dāng)需要這個后臺線程執(zhí)行任務(wù)時，AFNetworking通過調(diào)用[NSObject performSelector:onThread:withObject:waitUntilDone:modes:]將這個任務(wù)扔到了后臺線程的Runloop中。

7.PerformSelector的實現(xiàn)原理？

  • 當(dāng)調(diào)用NSObject的performSelecter:afterDelay:后，實際上其內(nèi)部創(chuàng)建一個Timer并添加到當(dāng)前線程的Runloop中。所以如果當(dāng)前線程沒有Runloop，則這個方法會失效。
  • 當(dāng)調(diào)用performSelector:onThread:時，實際上其會創(chuàng)建一個Timer加到對應(yīng)的線程去，同樣的，如果對應(yīng)線程沒有Runloop該方法也會失效。

8.PerformSelector:afterDelay:這個方法在子線程中是否起作用？

  • 不起作用，子線程默認沒有Runloop，也就沒有Timer?？梢允褂肎CD的dispatch_after來實現(xiàn)

9.事件響應(yīng)的過程？

  • 蘋果注冊了一個Source1（基于mach port的）用來接收系統(tǒng)事件，其回調(diào)函數(shù)為__IOHIDEventSystemClientQueueCallback()。
  • 當(dāng)一個硬件事件（觸摸/鎖屏/搖晃等）發(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ā)，其中包括識別UIFesture/處理屏幕旋轉(zhuǎn)/發(fā)送給UIWindow等。通常事件比如UIButton點擊、touchesegin/Move/End/Cancel事件都是在這個回調(diào)中完成的。

10.手勢識別的過程？

  • 當(dāng)_UIApplicationJandleEventQueue()識別了一個手勢時，其首先會調(diào)用Cancel將當(dāng)前的touchesBegin/Move/End系列回調(diào)打斷。隨后系統(tǒng)將對應(yīng)的UIGestureRecognizer標(biāo)記為待處理。
  • 蘋果注冊了一個Observer檢測BeforeWaiting（Loop即將進入休眠）事件，這個Observer的回調(diào)函數(shù)是_UIGestureRecognizerUpdateObserver()，其內(nèi)部會獲取所有剛被標(biāo)記為待處理的GestureRecognizer，并執(zhí)行GestureRecognizer的回調(diào)。
  • 當(dāng)有UIGestureRecognizer的變化（創(chuàng)建/銷毀/狀態(tài)改變）時，這個回調(diào)都會進行相應(yīng)處理。

11.CADispalyTimer和Timer哪個更精確？

CADisplayLink更精確

  • iOS設(shè)備的屏幕刷新頻率是固定的，CADisplayLink在正常情況下載每次刷新結(jié)束都被調(diào)用，精確度相當(dāng)奧。
  • NSTimer的精確度就顯得低了點，比如NSTimer的觸發(fā)事件到的時候，Runloop如果在阻塞狀態(tài)，觸發(fā)事件就會推出到下一個Runloop周期。并且NSTimer新增了tolerance屬性，讓用戶可以設(shè)置可以容忍的觸發(fā)的時間的延遲范圍。
  • CADisplayLink使用場合相對專一，適合做UI的不停重繪，比如自定義動畫引擎或者視頻播放的渲染。NSTimer的使用返回要廣泛的多，各種需要單次或者循環(huán)定時處理的任務(wù)都可以使用。在UI相關(guān)的動畫或者顯示內(nèi)容使用CADisplayLink比起用NSTimer的好處就是我們不需要再格外關(guān)心屏幕的刷新頻率了，因為它本身就是跟屏幕刷新同步的。
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容