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

• 一個(gè)線程對(duì)應(yīng)一個(gè)Runloop躬存。
• 主線程默認(rèn)開啟了Runloop。
• 子線程的Runloop以懶加載的形式創(chuàng)建。
• Runloop存儲(chǔ)在一個(gè)全局的可變字典里堂淡，線程是key，Runloop是value扒腕。

2.Runloop的運(yùn)行模式绢淀？

Runloop的運(yùn)行模式共有5中，Runloop只會(huì)運(yùn)行在一個(gè)模式下袜匿，要切換模式更啄，就要暫停當(dāng)前模式，重新啟動(dòng)一個(gè)運(yùn)行模式

1.kCFRunLoopDefaultMode居灯，App的默認(rèn)運(yùn)行模式祭务，通常主線程是在這個(gè)運(yùn)行模式下運(yùn)行
2.UITrackingRunLoopMode内狗，跟蹤用戶交互時(shí)間（用于ScrollView追蹤觸摸滑動(dòng)，保證界面滑動(dòng)時(shí)不受其他Mode影響）
3.kCFRunLoopCommonModes义锥，偽模式柳沙，不是一種真正的運(yùn)行模式
4.UIInitializationRunLoopMode，在剛啟動(dòng)App時(shí)進(jìn)入的第一個(gè)Mode拌倍，啟動(dòng)完成后就不再使用
5.GSEventReceiveRunLoopMode赂鲤，接受系統(tǒng)內(nèi)部事件，通常用不到

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

• 實(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ì)返回寺谤。

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

4.autoreleasePool在何時(shí)被釋放誊役？

• App啟動(dòng)后获列，蘋果在主線程Runloop里注冊了兩個(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了朋譬。

5.GCD在Runloop中的使用？

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

6.AFNetworking中如何運(yùn)用Runloop探越？

AFURLConnectionOperation這個(gè)類是基于NSURLConnection構(gòu)建的狡赐，其希望能在后臺(tái)線程接收Delegate回調(diào)。為此AFNetworking單獨(dú)創(chuàng)建了一個(gè)線程钦幔，并在這個(gè)線程中啟動(dòng)了一個(gè)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啟動(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ā)送消息铜异。

- (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)需要這個(gè)后臺(tái)線程執(zhí)行任務(wù)時(shí)哥倔，AFNetworking通過調(diào)用[NSObject performSelector:onThread:withObject:waitUntilDone:modes:]將這個(gè)任務(wù)扔到了后臺(tái)線程的Runloop中。

7.PerformSelector的實(shí)現(xiàn)原理揍庄？

• 當(dāng)調(diào)用NSObject的performSelecter:afterDelay:后咆蒿，實(shí)際上其內(nèi)部創(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ì)失效。

8.PerformSelector:afterDelay:這個(gè)方法在子線程中是否起作用别渔？

• 不起作用附迷，子線程默認(rèn)沒有Runloop，也就沒有Timer哎媚±可以使用GCD的dispatch_after來實(shí)現(xiàn)

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

• 蘋果注冊了一個(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)程。隨后蘋果注冊的那個(gè)Source1就會(huì)觸發(fā)回調(diào)荚斯，并調(diào)用_UIApplicationHandleEventQueue()進(jìn)行應(yīng)用內(nèi)部的分發(fā)埠居。
• _UIApplicationHandleEventQueue()胡巴IOHIDEvent處理并包裝成UIEvent進(jìn)行處理或分發(fā)，其中包括識(shí)別UIFesture/處理屏幕旋轉(zhuǎn)/發(fā)送給UIWindow等事期。通常事件比如UIButton點(diǎn)擊滥壕、touchesegin/Move/End/Cancel事件都是在這個(gè)回調(diào)中完成的。

10.手勢識(shí)別的過程兽泣？

• 當(dāng)_UIApplicationJandleEventQueue()識(shí)別了一個(gè)手勢時(shí)绎橘，其首先會(huì)調(diào)用Cancel將當(dāng)前的touchesBegin/Move/End系列回調(diào)打斷。隨后系統(tǒng)將對(duì)應(yīng)的UIGestureRecognizer標(biāo)記為待處理唠倦。
• 蘋果注冊了一個(gè)Observer檢測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)處理候齿。

11.CADispalyTimer和Timer哪個(gè)更精確熙暴？

CADisplayLink更精確

• iOS設(shè)備的屏幕刷新頻率是固定的，CADisplayLink在正常情況下載每次刷新結(jié)束都被調(diào)用慌盯，精確度相當(dāng)奧周霉。
• NSTimer的精確度就顯得低了點(diǎn)，比如NSTimer的觸發(fā)事件到的時(shí)候亚皂，Runloop如果在阻塞狀態(tài)俱箱，觸發(fā)事件就會(huì)推出到下一個(gè)Runloop周期。并且NSTimer新增了tolerance屬性孕讳，讓用戶可以設(shè)置可以容忍的觸發(fā)的時(shí)間的延遲范圍匠楚。
• CADisplayLink使用場合相對(duì)專一，適合做UI的不停重繪厂财，比如自定義動(dòng)畫引擎或者視頻播放的渲染。NSTimer的使用返回要廣泛的多峡懈，各種需要單次或者循環(huán)定時(shí)處理的任務(wù)都可以使用璃饱。在UI相關(guān)的動(dòng)畫或者顯示內(nèi)容使用CADisplayLink比起用NSTimer的好處就是我們不需要再格外關(guān)心屏幕的刷新頻率了，因?yàn)樗旧砭褪歉聊凰⑿峦降摹?/li>