runloop的使用場景

這裏大部分是從各個技術博客中參考而來，部分場景添加了一些實踐代碼。html

執行block任務

使用CFRunLoopPerformBlock函數, 能夠指定在runloopMode下執行block任務。不過通常不這樣使用。前端

autoreleasePool

autoreleasepool是以棧爲節點, 雙向鏈表構建的一個數據結構。autoreleasePool與runloop的關係是一個常常被討論的點，但runloop源碼中沒有一丁點autoreleasepool的內容。iOS在主線程的runloop中, 註冊了兩個observer，分別監聽runloop的Entry和BeforeWaiting兩個狀態，對應執行autoreleasePool的push和pop操做。ios

@autoreleasepool {} 等同於 void *ctx = objc_autoreleasePoolPush();
{}中的代碼會在最後部分添加一個 objc_autoreleasePoolPop(ctx);

Entry狀態的回調事件爲 _obj_autoreleasePoolPush() 函數, 建立新的autoreleasepool。即push操做。git

BeforeWaiting狀態的回調事件中會調用 _objc_autoreleasePoolPop() 函數來釋放舊的autoreleasepool, 而後調用 _obj_autoreleasePoolPush() 函數再建立一個新的autoreleasepool。即先作pop，而後再作push操做。github

打印主線程的runloop對象，能夠看到下邊兩個Observer，callout函數都是_wrapRunLoopWithAutoreleasePoolHandler。web

observers = (
    "<CFRunLoopObserver 0x600000b00320 [0x7fff80617cb0]>{valid = Yes, activities = 0x1, repeats = Yes, order = -2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler (0x7fff4808bf54), context = <CFArray 0x60000345df80 [0x7fff80617cb0]>{type = mutable-small, count = 0, values = ()}}",
    "<CFRunLoopObserver 0x600000b003c0 [0x7fff80617cb0]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 2147483647, callout = _wrapRunLoopWithAutoreleasePoolHandler (0x7fff4808bf54), context = <CFArray 0x60000345df80 [0x7fff80617cb0]>{type = mutable-small, count = 0, values = ()}}"
),
複製代碼

第一個Observer監聽Entry狀態，會調用 _obj_autoreleasePoolPush() 函數, 建立新的autoreleasepool。order = -2147483647說明其優先級最高，確保其回調發生在全部其餘回調操做以前。數據庫

第二個Observer監聽BeforeWaiting狀態和Exit狀態。調用 _objc_autoreleasePoolPop() 函數來釋放舊的autoreleasepool，其中的autorelease對象會所有釋放, 而後調用 _obj_autoreleasePoolPush() 函數再建立一個新的autoreleasepool。若是是Exit狀態則直接調用pop操做。該Observer的order = 2147483647說明優先級最低，確保發生在全部回調操做以後。swift

注意，autoreleasepool是能夠嵌套使用的，所以其push和pop操做對應會使用到一些標記，即哨兵對象。緩存

添加到autoreleasepool中的對象，在其retainCount爲1時，不會繼續減1，而是標記爲需釋放。而釋放時機則是經過監聽runloop的狀態來實現的。而未添加到autoreleasepool中的對象，其釋放則與runloop無關，僅僅是遵循ARC便可。bash

事件響應

iOS註冊了一個Source1（基於mach port）來接收系統事件，回調是__IOHIDEventSystemClientQueueCallback()。事件產生時，IOKit框架生成一個IOHIDEvent事件，由SpringBoard（專門用於處理事件響應的進程）接收，隨後使用mach msg轉發給對應的App，隨後註冊的Source1就會觸發回調，調用_UIApplicationHandleEventQueue()來進行App內部的事件傳遞流程。

以前有講過一個很關鍵的點：

Source1在處理任務的時候，一般會跟Source0一塊兒配合，即分發一些任務給Source0去執行。如UITouch事件，最初是由Source1處理點擊屏幕到事件捕獲的任務，以後Source1將事件包裝分發給Source0去處理。這一點很是關鍵。

這裏，_UIApplicationHandleEventQueue()函數將IOHIDEvent包裝成UIEvent，分發給到Source0進行處理，所以咱們一般看到的UITouch事件，包括UIButton點擊，touch事件，手勢等，經過函數調用棧看到的每每只有Source0的callout函數。而實際上，事件響應是Source1和Source0共同完成的。

以前有講到一個iOS系統內部使用的runloopMode：GSEventReceiveRunLoopMode。GSEvent將系統的事件所有封裝好，而後傳遞給App，如音量鍵、屏幕點擊等。UIEvent只是對於GSEvent的封裝。

UIGesture

主線程會註冊一個observer，監聽BeforeWaiting事件，回調是 _UIGestureRecognizerUpdateObserver* 。

"<CFRunLoopObserver 0x600000b08000 [0x7fff80617cb0]>{valid = Yes, activities = 0x20, repeats = Yes, order = 0, callout = _UIGestureRecognizerUpdateObserver (0x7fff47c2f06a), context = <CFRunLoopObserver context 0x600001110700>}",
複製代碼

當_UIApplicationHandleEventQueue()識別到一個手勢後，會將以前的touch事件的一系列回調方法(如touchesMove)終止，隨後將該UIGestureRecognizer標記爲待處理。_UIGestureRecognizerUpdateObserver()函數的內部獲取全部剛被標記爲待處理的UIGestureRecognizer，執行其對應的回調方法。當UIGestureRecognizer的狀態有變化時，該回調也會執行。

固然，手勢確定也是Source1和Source0共同完成的。

GCD

runloop的超時時間就是經過GCD timer來控制的。GCD啓動子線程，內部其實用到了runloop。GCD從子線程返回到主線程，會觸發runloop的Source1事件。

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    /// GCD往子線程丟一個延時操做，可以執行，說明GCD內部其實用到了runloop。
    NSLog(@"global after %@", [NSThread currentThread]);
});
複製代碼

dispatch_async(main_queue, block)時，libdispatch會向主線程的runloop發送消息喚醒runloop，runloop被喚醒後會從消息中獲取block，在callout函數 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE 中執行該block任務。僅限主線程，子線程的dispatch block操做所有由libdispatch完成的。

runloopMode

dispatch_async(dispatch_get_main_queue(), ...)會將block放到commonModes中執行，而CFRunLoopPerformBlock容許指定runloopMode來執行block。

可否喚醒runloop

dispatch_async(dispatch_get_main_queue(), ...)會喚醒主線程的runloop，而CFRunLoopPerformBlock不會主動喚醒runloop。如runloop休眠，則CFRunLoopPerformBlock的block不能執行。可使用CFRunLoopWakeUp來喚醒runloop。

GCD的main queue是一個串形隊列

GCD的main queue是一個串形隊列，這樣的結果就是dispatch_async(dispatch_get_main_queue(), ...)傳入的block會做爲一個總體，在runloop的下一次循環時執行。

請看以下代碼，***輸出 1，3，2***是咱們再也熟悉不過的代碼了，然後半部分爲何會 ***輸出 4，5，6***呢？且等待的1s間隔時機也不同，分別爲1...32和45...6。這裏的...表示間隔。

- (void)testGCDMainQueue {
    dispatch_async(dispatch_get_main_queue(), ^{
        NSLog(@"main queue task 1");
        dispatch_async(dispatch_get_main_queue(), ^{
            NSLog(@"main queue task 2");
        });
        [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
        NSLog(@"main queue task 3");
    });
    /// 輸出 1，3，2
    
    CFRunLoopPerformBlock(CFRunLoopGetCurrent(), kCFRunLoopCommonModes, ^{
        NSLog(@"main queue task 4");
        CFRunLoopPerformBlock(CFRunLoopGetCurrent(), kCFRunLoopCommonModes, ^{
            NSLog(@"main queue task 5");
        });
        [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
        NSLog(@"main queue task 6");
    });
    /// 輸出 4，5，6
}
複製代碼

dispatch_async實驗的代碼段中 [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]]; 使得該週期的runloop又持續運行了1s。可是由於main queue是串形隊列，因此打印一、runloop再運行1s、打印3，這三句代碼是一個任務；而打印2顯然是另一個任務了，因此纔會輸出1，3，2。

CFRunLoopPerformBlock實驗的代碼段中，將block丟到了runloop中執行，若該runloop在運行則該block確定會被調度執行。而 [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]]; 使得該週期的runloop又持續運行了1s，與該runloop中的block執行自己無關，因此5會正常打印出來。固然，若是沒有 ***[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];***，打印4，6，5則是理所固然且與GCD一致的。

CFRunLoopPerformBlock(CFRunLoopGetCurrent(), kCFRunLoopCommonModes, ^{
    NSLog(@"main queue task 4");
    CFRunLoopPerformBlock(CFRunLoopGetCurrent(), kCFRunLoopCommonModes, ^{
        NSLog(@"main queue task 5");
    });
    NSLog(@"main queue task 6");
});
/// 輸出 4，6，5
複製代碼

CFRunLoopPerformBlock與performSelector:inModes:效果相似

若是須要指定block僅在DefaultMode才能執行，一般使用performSelector:inModes:便可。其實也可使用CFRunLoopPerformBlock函數。

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
    CFRunLoopPerformBlock(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, ^{
      /// 只有在DefaultMode纔會執行。
      /// 若是gcd after將block丟到了main queue中，則scrolling時不會打印log；中止時，切換到了DefaultMode纔會打印。
      NSLog(@"CFRunLoopPerformBlock kCFRunLoopDefaultMode scrolling stopped");
    });
});
複製代碼

NSTimer

NSTimer是基於runloop的，與CFRunLoopTimerRef能夠免費橋轉換。timer註冊到runloop後，runloop爲其下一次執行的時間點註冊好回調事件，即__CFArmNextTimerInMode操做。若是timer的時間到了，可是runloop正在執行一個長的call out函數等，timer會超時。此時若是有設置參數Tolerance（容忍度），則在容忍時間以內，timer仍是能夠執行的，超出就直接使得timer超時了。

NSTimer的精確度會受runloop運行狀態的影響較大，且NSTimer在子線程中使用須要保證該子線程常駐，即runloop一直存在。關於NSTimer有一個常見的循環引用問題：runloop會對timer持有，timer會對target持有，所以使用不當可能致使target不能正確釋放。

若是有一些需求場景對timer的精確度有嚴格要求，或者子線程沒有runloop，則一般可使用GCD Timer。而GCD的定時器，是依賴於系統內核，不依賴於RunLoop，所以一般更加準時。而且，GCD Timer能夠在後臺線程運行，根本緣由在於GCD本身內部有對runloop進行使用。

而若是在有runloop存活的線程中使用，則GCD timer和NSTimer的準確性差異不大，都是經過mach msg和mach port來喚醒runloop，以觸發timer回調。若當前runloop阻塞了，都會存在延遲問題。參考iOS RunLoop詳解。

關於Timer的更詳細的內容，包括循環引用的解決方案，請參考博客：比較一下iOS中的三種定時器。其實關於CFRunLoopTimerRef的使用，應該算是第四種timer了。

CADisplayLink

CADisplayLink的回調函數觸發頻率和屏幕刷新頻率一致，精度比NSTimer更高，但也須要加入到runloop才能執行。其原理是基於CFRunloopTimerRef來實現的，底層使用mk_timer。若是遇到runloop正在執行比較重的任務，CADisplayLink的精度也會受影響。其使用場景沒有NSTimer廣泛。

後臺常駐線程

開發者自行建立的子線程，默認不會開啓runloop。有一個比較常見的需求就是子線程保活，這就須要用到runloop的技巧，即須要保持runloop一直運行。子線程中開啓runloop須要使用autoreleasepool。

If you spawn a secondary thread. You must create your own autorelease pool block as soon as the thread begins executing; otherwise, your application will leak objects. (See [Autorelease Pool Blocks and Threads]).

線程的runloop一直運行的前提條件就是：必須有一個Mode Item，即Source、Timer、Observer之一。

/// 使用NSTimer
- (void)addBackgroundRunLoop1 {
    self.thread1 = [[NSThread alloc] initWithBlock:^{
        NSTimer *timer = [NSTimer timerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
            NSLog(@"%@", self.thread1.name);

            /// 若是在子線程中週期性地ping一下主線程，若指定時間內，該對應的block未執行，則可認爲主線程卡頓。
            dispatch_async(dispatch_get_main_queue(), ^{
                /// 若是一段時間未打印，則能夠判斷主線程卡頓了。
                NSLog(@"main is ok.");
            });
        }];

        // 線程存活，須要添加一個source1。通常是Timer或一個空的port便可。
        [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
        [[NSRunLoop currentRunLoop] run]; /// 會一直卡在這裏不會繼續往下走。
//        [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.1f]];
        
        // 後續的代碼永遠不會執行。
        NSLog(@"thread runloop");
    }];
    self.thread1.name = @"addBackgroundRunLoop1";
    [self.thread1 start];
}

/// 使用NSPort
- (void)addBackgroundRunLoop2 {
    self.thread2 = [[NSThread alloc] initWithBlock:^{
        // 線程存活，須要添加一個source1。若是沒有特殊需求，通常能夠是Timer或一個空的port。
        // addPort而後run，該線程才能一直存活。而addPort對應經過removePort來移除
        [[NSRunLoop currentRunLoop] addPort:[NSPort port] forMode:NSDefaultRunLoopMode];
        [[NSRunLoop currentRunLoop] run];
    }];
    self.thread2.name = @"addBackgroundRunLoop2";
    [self.thread2 start];
    
    NSTimer *timer = [NSTimer timerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
        [self performSelector:@selector(onTimerInBackgroundRunLoop2) onThread:self.thread2 withObject:nil waitUntilDone:NO];
    }];
    [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
}
- (void)onTimerInBackgroundRunLoop2 {
    NSLog(@"%@", self.thread2.name);
}
複製代碼

AFNetworking 2.x的常駐線程

在AFNetworking 2.x中，就使用到了這種方式，使得子線程一直存活。AFNetworking 2.x但願在後臺線程接收delegate的回調函數，所以須要後臺線程持續存在，使用到了NSRunLoop的run方法，在run方法調用以前，必須先建立一個runloopMode item（source或timer）加到runloop中去，這裏是使用了NSMachPort。且僅是爲了讓該後臺線程常駐，而沒有實際的mach msg消息傳遞，因此空的NSMachPort便可。

/*
 AFN 2.x中使用了常駐子線程，在AFURLConnectionOperation.m文件中。
 AFURLConnectionOperation的start方法中，將operationDidStart方法丟在子線程networkRequestThread中執行。
 [self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
 在operationDidStart方法中：
 self.connection = [[NSURLConnection alloc] initWithRequest:self.request delegate:self startImmediately:NO];
 [self.connection scheduleInRunLoop:runLoop forMode:runLoopMode];
 [self.connection start];
 這樣，即作到了在子線程中發起網絡請求和數據解析。而子線程一直常駐，不會中止。
 NSURLConnection發起的網絡請求，須要在AFURLConnectionOperation中，自行進行請求處理和數據解析。
 
 AFN 3.x中移除了該常駐線程，使用的時候run，結束的時候stop便可。由於NSURLSession本身維護了一個線程池，作request線程的調度和管理。不在須要在當前線程中進行請求和數據解析，能夠指定回調的delegateQueue了。
 */
+ (NSThread *)networkRequestThread {
  static NSThread *_networkRequestThread = nil;
  static dispatch_once_t onceToken;
  dispatch_once(&onceToken, ^{
    // 爲啥不用__block，由於block對 ***靜態局部變量是以指針形式*** 進行截獲。
    _networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(onNetworkRequstThread) object:nil];
    [_networkRequestThread start];
  });
}

+ (void)onNetworkRequstThread {
  @autoreleasepool {
    [[NSThread currentThread] setName:@"AFNetworking"];
    NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
    [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
    [runLoop run];
  }
}
複製代碼

peformSelector

這類方法的本質其實就是使用NSTimer。peformSelector:afterDelay: 和 performSelector:onThread: 調用時，內部均會建立一個NSTimer，添加到指定線程的runloop中。若後臺線程沒有runloop，則會失效。因此對於子線程，只能使用dispatch_after來作到延時操做，由於GCD啓動子線程，內部其實用到了runloop。

能夠利用runloopMode，如僅在Default Mode下設置UIImageView的圖片，以避免UIScrollView的滾動受到影響。 好比微博，滑動中止時候，圖片一個個展現出來。。。

performSelector:withObject:afterDelay:inModes:方法能夠指定在runloopMode中執行任務，如僅在DefaultMode下給UIImageView設置圖片。則UIScrollView滾動時，設置圖片的任務不會執行，以保證滾動的流暢性。一旦中止處理DefaultMode再進行圖片設置。

可使用cancelPreviousPerformRequestsWithTarget:和cancelPreviousPerformRequestsWithTarget:selector:object:來將正在排隊的任務取消。

UI界面更新

當操做UI、更新CALayer層級、layoutIfNeeded方法等，對應的UIView、CALayer被標記爲dirty，即爲待處理，被提交到一個全局的容器中。iOS註冊一個Observer監聽主線程的BeforeWaiting狀態，該狀態到來時對全部待處理（dirty）的視圖對象發送drawRect:消息。因此，iOS的界面渲染其實只是被修改須要重繪製的視圖纔會更新。

看兩個Observer：

"<CFRunLoopObserver 0x600000b001e0 [0x7fff80617cb0]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 1999000, callout = _beforeCACommitHandler (0x7fff480bc2eb), context = <CFRunLoopObserver context 0x7fe8da300720>}",
"<CFRunLoopObserver 0x600000b00280 [0x7fff80617cb0]>{valid = Yes, activities = 0xa0, repeats = Yes, order = 2001000, callout = _afterCACommitHandler (0x7fff480bc354), context = <CFRunLoopObserver context 0x7fe8da300720>}",
複製代碼

即CoreAnimation會監聽runloop的狀態，對應有兩個callout函數：_beforeCACommitHandler和_afterCACommitHandler。

好比下邊的代碼：

UIButton *btn = [[UIButton alloc] initWithFrame:CGRectMake(100, 100, 200, 200)];
btn.backgroundColor = [UIColor redColor];
[self.view addSubview:btn];

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
    CGRect frame = btn.frame;
    // 先向下移動
    frame.origin.y += 200;
    [UIView animateWithDuration:1 animations:^{
        btn.frame = frame;
        [btn setNeedsDisplay];
    }];
    
    // 再向右移動
    frame.origin.x += 200;
    [UIView animateWithDuration:1 animations:^{
        btn.frame = frame;
        [btn setNeedsDisplay];
    }];
});
複製代碼

這樣作，是無法實現預期的。正由於UI更新是先收集待處理的UI視圖，再統一繪製。因此結果便是隻有一個移動到右下角的動畫效果

卡頓監控

添加Observer監控runloop的狀態。

卡頓緣由

緣由主要有：

複雜UI、圖文混排等繪製量過大。在屏幕的一個V-Sync信號的週期（1/60秒）內，CPU任務或者GPU任務超時都會致使卡頓。
主線程作網絡請求、數據庫操做、IO操做等。
死鎖等

若是runloop的線程，進入睡眠前方法的執行時間過長而致使沒法進入睡眠，或者線程喚醒後接收消息時間過長而沒法進入下一次runloop循環，則線程受阻。若是是主線程則是卡頓。

因此，問題在於到底監控哪一個狀態？BeforeSources和AfterWaiting兩個狀態以後，就是runloop實際執行任務的時機。也就是觸發source0回調和接收mach_port消息兩個狀態。

添加observer到主線程runloop的commonModes，觀測到這兩種狀態就修改時間值。建立一個常駐子線程監控該時間值，若定時器時間到了，則認定主線程超時了。。監控的狀態到了，就改變時間閾值，若未變化，則卡頓，dump出堆棧信息上傳便可。dump堆棧可使用PLCrashReporter。

ping主線程的方案

實現原理比較簡單，子線程定時向主線程丟入一個任務來執行，以完成ping的操做。主要代碼以下：

var timeoutOfANR: TimeInterval = 0.5
private lazy var anrObserver: CFRunLoopObserver = { makeANRObserver() }()
private lazy var pingMainQueue: DispatchQueue = { return makePingMainQueue() }()
private lazy var pingMainLock: DispatchSemaphore = { return makePingMainLock() }()

func start() {
  if isMonitoring { return }
  isMonitoring = true
  
  CFRunLoopAddObserver(CFRunLoopGetMain(), anrObserver, CFRunLoopMode.commonModes)
  
  pingMainQueue.async {
      while self.isMonitoring {
          var timeout = true
          DispatchQueue.main.async {
              timeout = false
              self.pingMainLock.signal()
          }
          Thread.sleep(forTimeInterval: self.timeoutOfANR)
          if timeout {
              print("ANR")
          }
          self.pingMainLock.wait()
      }
  }
}

func stop() {
  guard isMonitoring else { return }
  isMonitoring = false
  
  CFRunLoopRemoveObserver(CFRunLoopGetMain(), anrObserver, CFRunLoopMode.commonModes)
}

private func makeANRObserver() -> CFRunLoopObserver {
  let observer = CFRunLoopObserverCreateWithHandler(kCFAllocatorDefault,
                                                    CFRunLoopActivity.allActivities.rawValue,
                                                    true,
                                                    0)
  { (observer, activity) in
      self.currentActivityMainRunloop = activity
      self.recordActivityLock.signal()
      
      self.debugRunloopActivity(activity)
  }
  return observer!
}

private func makePingMainQueue() -> DispatchQueue {
  let queue = DispatchQueue(label: "com.icetime.AppMonitor.pingMainQueue",
                            qos: DispatchQoS(qosClass: .default, relativePriority: 0),
                            attributes: .concurrent,
                            autoreleaseFrequency: .inherit,
                            target: nil)
  return queue
}

private func makePingMainLock() -> DispatchSemaphore {
  return DispatchSemaphore(value: 0)
}
複製代碼

獲取調用堆棧

獲取調用堆棧，可使用開源框架PLCrashReporter或KSCrash。

網絡請求

CFSocket: 最底層，只負責socket通訊
CFNetwork -> 基於CFSocket封裝，ASIHttpRequest基於這一層
NSURLConnection -> NSURLConnection是基於CFNetwork的OC封裝。AFNetworking 2.x
NSURLSession -> NSURLSession部分功能依然在底層使用到了NSURLConnection（如com.apple.NSURLConnectionLoader線程）。 AFNetworking 3.x, Alamofire
複製代碼

runloo會經過一些基於mach port的Source接收來自底層CFSocket的通知。

在前面的網絡開發的文章中已經介紹過NSURLConnection的使用，一旦啓動NSURLConnection之後就會不斷調用delegate方法接收數據，這樣一個連續的的動做正是基於RunLoop來運行。
一旦NSURLConnection設置了delegate會當即建立一個線程com.apple.NSURLConnectionLoader，同時內部啓動RunLoop並在NSDefaultMode模式下添加4個Source0。其中CFHTTPCookieStorage用於處理cookie ;CFMultiplexerSource負責各類delegate回調並在回調中喚醒delegate內部的RunLoop（一般是主線程）來執行實際操做。
早期版本的AFNetworking庫也是基於NSURLConnection實現，爲了可以在後臺接收delegate回調AFNetworking內部建立了一個空的線程並啓動了RunLoop，當須要使用這個後臺線程執行任務時AFNetworking經過performSelector: onThread: 將這個任務放到後臺線程的RunLoop中。
複製代碼

一般使用 NSURLConnection 時，你會傳入一個 Delegate，當調用了 [connection start] 後，這個 Delegate 就會不停收到事件回調。實際上，start 這個函數的內部會會獲取 CurrentRunLoop，而後在其中的 DefaultMode 添加了4個 Source0 (即須要手動觸發的Source)。CFMultiplexerSource 是負責各類 Delegate 回調的，CFHTTPCookieStorage 是處理各類 Cookie 的。

當開始網絡傳輸時，咱們能夠看到 NSURLConnection 建立了兩個新線程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 線程是處理底層 socket 鏈接的。NSURLConnectionLoader 這個線程內部會使用 RunLoop 來接收底層 socket 的事件，並經過以前添加的 Source0 通知到上層的 Delegate。
複製代碼

NSURLConnectionLoader 中的 RunLoop 經過一些基於 mach port 的 Source 接收來自底層 CFSocket 的通知。當收到通知後，其會在合適的時機向 CFMultiplexerSource 等 Source0 發送通知，同時喚醒 Delegate 線程的 RunLoop 來讓其處理這些通知。CFMultiplexerSource 會在 Delegate 線程的 RunLoop 對 Delegate 執行實際的回調
複製代碼

瞭解到，能夠利用runloop來作到合併網絡請求？猜想應該是利用CFSocket，直接接收系統底層的網絡請求相關信息，進行網絡請求的拼接；收到網絡返回結果後，將返回數據進行拆解，再分發到各自的網絡請求的業務方。只是猜想而已。

在UIScrollView中止滾動時設置圖片

利用不一樣runloopMode之間相互隔離的特性，能夠作到僅在DefaultMode下對imageView進行圖片設置。而當UIScrollView滑動時，處於UITrackingMode，則不會設置圖片。

[self.imageView performSelector:@selector(setImage:) withObject:image afterDelay:0 inModes:@[NSDefaultRunLoopMode]];
複製代碼

setImage操做必須在主線程執行，會包括 圖片解碼和渲染 兩個階段。頻繁調用或者圖片解碼耗時，則很容易影響用戶體驗。經過以上方式能夠很好地優化體驗。另外，對圖片進行異步解碼也是一個很好的優化思路，甚至能夠將解碼操做提早放到runloop空閒的時候去作。

UI任務分解

如很是多的UITableViewCell的繪製, 一次runloop週期會嘗試加載一個屏幕上全部的圖片，快速滑動時很容易致使卡頓。能夠基於runloop的原理進行任務拆分，監聽runloop的BeforeWaiting事件，每一次runloop循環加載一張圖片。這樣須要使用block來包裝一個loadImageTask。

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"UITableViewCell"];
    cell.selectionStyle = UITableViewCellSelectionStyleNone;
    
    for (NSInteger i=1; i<=5; i++) {
        [[cell.contentView viewWithTag:i] removeFromSuperview];
    }
    
    /// before：一次runloop週期加載一個屏幕上全部的圖片，致使卡頓
//    [self addImage1ForCell:cell];
//    [self addImage2ForCell:cell];
//    [self addImage3ForCell:cell];
    
    /// after：優化
    /// 基於runloop原理進行較重的UI任務拆分：監聽runloop循環，循環一次加載一張圖片。
    /// 使用block來包裝一個loadImageTask。
    __weak typeof(self) weakSelf = self;
    [self addLoadImageTask:^{
        [weakSelf addImage1ForCell:cell];
    }];
    [self addLoadImageTask:^{
        [weakSelf addImage2ForCell:cell];
    }];
    [self addLoadImageTask:^{
        [weakSelf addImage3ForCell:cell];
    }];
    
    return cell;
}
複製代碼

添加runloop的observer的方式以下：

typedef void(^BlockTask)(void);

/// 用於存儲self對象自己
static void *ViewControllerSelf;

@property (nonatomic, strong) NSMutableArray<BlockTask> *loadImageTasks;

- (void)addRunloopObserver {
    /// runloop即將進入休眠時候，則會觸發該callback；而每一個runloop週期都有即將進入休眠的時機，因此用戶滾動時callback會一直調用。
    /// 若是沒有任何用戶操做，則靜止時runloop進入休眠，不會觸發callback了。
    CFRunLoopObserverContext context = {
        0,
        (__bridge void *)self,
        &CFRetain,
        &CFRelease,
        NULL
    };
    CFRunLoopObserverRef observer = CFRunLoopObserverCreate(NULL, kCFRunLoopBeforeWaiting, YES, 0, &RunloopObserverCallBack, &context);
    
    CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopCommonModes);
    
    
    /// 而若是添加了這個timer，則用戶中止滾動時，回調也會一直被調用。由於timer會喚醒runloop。
    NSTimer *timer = [NSTimer timerWithTimeInterval:0.0001 repeats:YES block:^(NSTimer * _Nonnull timer) {
        /// nothing
    }];
    [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
}

/// 如何將loadImageTask的任務（須要該ViewController的實例對象）提供給該回調函數。
void RunloopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
    NSLog(@"RunloopObserverCallBack");
    /// 每次觸發該回調，都從tasks中出列一個任務執行，即每次回調加載一張圖片。
    
    /// 方法1，使用static變量存儲self對象。
    ViewController *self = (__bridge ViewController *)ViewControllerSelf;
    
    /// 方法2，使用CFRunLoopObserverContext來傳遞self對象。
    if (self.loadImageTasks.count == 0) {
        return;
    }
    
    BlockTask task = self.loadImageTasks.firstObject;
    task();
    [self.loadImageTasks removeObjectAtIndex:0];
}
複製代碼

佈局計算

UITableView+FDTemplateLayoutCell的原理就是使用Observer監聽runloop的BeforeWaiting狀態，即runloop空閒狀態時執行佈局計算任務；當用戶進行滑動時（UITrackingMode）則暫停計算任務。佈局計算主要是計算UITableViewCell的高度並進行預緩存。

由於runloopMode的相互隔離特性，以及UITrackingMode的引入，使得在界面滑動時，其餘mode（DefaultMode）下的任務所有會被暫停，以此來保證滑動的流暢性。這樣就能夠作到不跟UITableView的代碼強耦合，也能很好地優化佈局計算任務，下降CPU負擔。

CFRunLoopRef runLoop = CFRunLoopGetCurrent();
CFStringRef runLoopMode = kCFRunLoopDefaultMode;
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(kCFAllocatorDefault, kCFRunLoopBeforeWaiting, true, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity _) {
    // TODO here
});
CFRunLoopAddObserver(runLoop, observer, runLoopMode);
複製代碼

UITableView+FDTemplateLayoutCell中，還用到了利用runloop來分解任務的技巧。如將界面不展現，須要緩存的其餘cell的高度計算任務，分解到各個runloop的循環中執行便可。

NSMutableArray *mutableIndexPathsToBePrecached = self.fd_allIndexPathsToBePrecached.mutableCopy;
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(kCFAllocatorDefault, kCFRunLoopBeforeWaiting, true, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity _) {
    if (mutableIndexPathsToBePrecached.count == 0) {
        CFRunLoopRemoveObserver(runLoop, observer, runLoopMode);
        CFRelease(observer); // 注意釋放，不然會形成內存泄露
        return;
    }
    NSIndexPath *indexPath = mutableIndexPathsToBePrecached.firstObject;
    [mutableIndexPathsToBePrecached removeObject:indexPath];
    [self performSelector:@selector(fd_precacheIndexPathIfNeeded:)
                 onThread:[NSThread mainThread]
               withObject:indexPath
            waitUntilDone:NO
                    modes:@[NSDefaultRunLoopMode]];
});
複製代碼

這樣，不至於一個runloop週期內要計算所有的緩存高度，且高度計算僅在DefaultMode下執行。滑動時會暫停計算任務。參考：優化UITableViewCell高度計算的那些事。

這種思路能夠用於分解任務，如空閒狀態執行計算、統計內存等等。如圖片異步解碼。只是一個異步操做而已，跟runloop無關。

自定義Source0

做爲開發者要使用 source0 也很簡單，先建立一個 CFRunLoopSourceContext，context 裏須要傳入被執行任務的函數指針做爲參數，再將該 context 做爲構造參數傳入 CFRunLoopSourceCreate 建立一個 source，以後經過 CFRunLoopAddSource 將該 source 綁定的某個 runloopMode 便可。

則，__CFRunLoopDoSources0函數調用時，自定義source0的事件會執行。

CFRunLoopAddSource
CFRunLoopRemoveSource
複製代碼

而這個在實際項目中有啥用？？？暫不清楚

NSNotificationQueue

NSNotificationQueue
NSNotificationQueue在NSNotificationCenter起到了一個緩衝的做用。儘管NSNotificationCenter已經分發通知，但放入隊列的通知可能會延遲，直到當前的runloop結束或runloop處於空閒狀態才發送。具體策略是由後面的參數決定。

若是有多個相同的通知，能夠在NSNotificationQueue進行合併，這樣只會發送一個通知。NSNotificationQueue會經過先進先出的方式來維護NSNotification的實例，當通知實例位於隊列首部，通知隊列會將它發送到通知中心，而後依次的像註冊的全部觀察者派發通知。

每一個線程有一個默認和 default notification center相關聯的的通知隊列。

經過調用initWithNotificationCenter和外部的NSNotificationCenter關聯起來，最終也是經過NSNotificationCenter來管理通知的發送、註冊。除此以外這裏有兩個枚舉值須要特別注意一下。

NSPostingStyle：用於配置通知何時發送
NSPostASAP：在當前通知調用或者計時器結束髮出通知
NSPostWhenIdle：當runloop處於空閒時發出通知
NSPostNow：在合併通知完成以後當即發出通知。
NSNotificationCoalescing（注意這是一個NS_OPTIONS）：用於配置如何合併通知
NSNotificationNoCoalescing：不合並通知
NSNotificationNoCoalescing：按照通知名字合併通知
NSNotificationCoalescingOnSender：按照傳入的object合併通知
複製代碼

UI渲染

UI渲染的流程

CPU：對象建立/銷燬（alloc/dealloc），佈局計算（layout），排版（如計算視圖大小、文本高度等），繪製內容（drawRect/drawLayer），準備解碼數據等（decompress image），提交渲染所需數據（圖層及動畫數據）至渲染服務，渲染服務中反序列化這些數據轉換成渲染數（render tree），計算中間值及生成紋理等。
GPU：紋理渲染，視圖混合，渲染可視的紋理至屏幕。
CPU有很強的通用性，各類數據類型、邏輯判斷、分支調整、中斷處理等，內部結構異常複雜。計算能力只是CPU的一部分做用，除此以外還擅長各類邏輯控制和通用數據類型的運算。CPU的多核只有不多的一部分，包含寄存器和多級Cache等。
而GPU擅長處理大規模的並行計算任務（相互沒有邏輯依賴），數據類型高度統一，GPU的核心很是多，但都是重複計算所需。GPU沒有Cache。

異步繪製：可在異步線程進行CGBitmapxxx的操做，生成bitmap，讀取image，最後在主線程將其賦值給layer.contents便可。避免主線程執行UIImageView的setImage:操做，同時執行圖像數據解碼和渲染致使的主線程卡頓。

CALayer先判斷本身的delegate有沒有實現異步繪製的代理方法displayLayer，若沒有則系統繪製流程。如有則進入進行，可作到異步繪製。

iOS系統註冊一個observer，監聽BeforeWaiting事件

註冊一個observer，監聽BeforeWaiting事件，回調方法中將全部打上髒標記的view/layer進行繪製和渲染。即回調中執行CALayer的display方法，進入真正的繪製工做。

若是打印App啓動以後的主線程RunLoop能夠發現另一個callout爲**_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv**的Observer，這個監聽專門負責UI變化後的更新，好比修改了frame、調整了UI層級（UIView/CALayer）或者手動設置了setNeedsDisplay/setNeedsLayout以後就會將這些操做提交到全局容器。而這個Observer監聽了主線程RunLoop的即將進入休眠和退出狀態，一旦進入這兩種狀態則會遍歷全部的UI更新並提交進行實際繪製更新。
_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];
一般狀況下這種方式是完美的，由於除了系統的更新，還能夠利用setNeedsDisplay等方法手動觸發下一次RunLoop運行的更新。可是若是當前正在執行大量的邏輯運算可能UI的更新就會比較卡，所以facebook推出了AsyncDisplayKit來解決這個問題。AsyncDisplayKit實際上是將UI排版和繪製運算儘量放到後臺，將UI的最終更新操做放到主線程（這一步也必須在主線程完成），同時提供一套類UIView或CALayer的相關屬性，儘量保證開發者的開發習慣。這個過程當中AsyncDisplayKit在主線程RunLoop中增長了一個Observer監聽即將進入休眠和退出RunLoop兩種狀態,收到回調時遍歷隊列中的待處理任務一一執行。
複製代碼

AsyncDisplayKit

以上已經介紹了UI渲染的流程。對於這些任務，除了必須在主線程執行的，如UI對象操做、佈局，其餘都要儘可能放到後臺線程執行。尤爲是將耗時操做，如CPU的對象建立銷燬，文本計算，佈局計算，圖片編解碼等，儘可能放到後臺線程執行。僅在主線程作必需的一些操做。

ASDK 所作的，就是儘可能將能放入後臺的任務放入後臺，不能的則儘可能推遲 (例如視圖的建立、屬性的調整)。爲此，ASDK 建立了一個名爲 ASDisplayNode 的對象，並在內部封裝了 UIView/CALayer，它具備和 UIView/CALayer 類似的屬性，例如 frame、backgroundColor等。全部這些屬性均可以在後臺線程更改，開發者能夠只經過 Node 來操做其內部的 UIView/CALayer，這樣就能夠將排版和繪製放入了後臺線程。可是不管怎麼操做，這些屬性總須要在某個時刻同步到主線程的 UIView/CALayer 去。

ASDK 仿照 QuartzCore/UIKit 框架的模式，實現了一套相似的界面更新的機制：即在主線程的 RunLoop 中添加一個 Observer，監聽了 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 事件，在收到回調時，遍歷全部以前放入隊列的待處理的任務，而後一一執行。

其實，這一套思路應用很是廣泛，前端框架如Vue中的Virtual DOM Tree也是相似用於暫時保存待修改的UI狀態，以後統一進行處理更新界面信息。

讓Crash的App復活

App的崩潰有兩種：

有信號的SIGABRT，通常是過分release對象，或者unrecognized selector
EXC_BAD_ACCESS訪問已經釋放的內存致使，即野指針錯誤。

SIGABRT是經過系統發送信號Signal給到App的，App收到這個信號Signal後，會把主線程的runloop殺掉，即crash產生。爲了讓App迴光返照，咱們須要來捕獲 libsystem_sim_c.dylib 調用 abort() 函數發出的程序終止信號，而後讓其執行咱們定義的處理signal的方法。在方法中，咱們須要開啓一個RunLoop,保持主線程不退出。

待實踐後補充！！！

一些QA

A run loop is an abstraction that (among other things) provides a mechanism to handle system input sources (sockets, ports, files, keyboard, mouse, timers, etc).

Each NSThread has its own run loop, which can be accessed via the currentRunLoop method.

In general, you do not need to access the run loop directly, though there are some (networking) components that may allow you to specify which run loop they will use for I/O processing.

A run loop for a given thread will wait until one or more of its input sources has some data or event, then fire the appropriate input handler(s) to process each input source that is "ready.".

After doing so, it will then return to its loop, processing input from various sources, and "sleeping" if there is no work to do.

That's a pretty high level description (trying to avoid too many details).

EDIT

An attempt to address the comment. I broke it into pieces.

it means that i can only access/run to run loop inside the thread right?
Indeed. NSRunLoop is not thread safe, and should only be accessed from the context of the thread that is running the loop.

is there any simple example how to add event to run loop?
If you want to monitor a port, you would just add that port to the run loop, and then the run loop would watch that port for activity.

- (void)addPort:(NSPort *)aPort forMode:(NSString *)mode
You can also add a timer explicitly with

- (void)addTimer:(NSTimer *)aTimer forMode:(NSString *)mode
what means it will then return to its loop?
The run loop will process all ready events each iteration (according to its mode). You will need to look at the documentation to discover about run modes, as that's a bit beyond the scope of a general answer.

is run loop inactive when i start the thread?
In most applications, the main run loop will run automatically. However, you are responsible for starting the run loop and responding to incoming events for threads you spin.

is it possible to add some events to Thread run loop outside the thread?
I am not sure what you mean here. You don't add events to the run loop. You add input sources and timer sources (from the thread that owns the run loop). The run loop then watches them for activity. You can, of course, provide data input from other threads and processes, but input will be processed by the run loop that is monitoring those sources on the thread that is running the run loop.

does it mean that sometimes i can use run loop to block thread for a time
Indeed. In fact, a run loop will "stay" in an event handler until that event handler has returned. You can see this in any app simply enough. Install a handler for any IO action (e.g., button press) that sleeps. You will block the main run loop (and the whole UI) until that method completes.

The same applies to any run loop.
複製代碼

Look at the "Run Loops" chapter of Apple's Threading Programming Guide. In brief:

There is one run loop associated with each thread.
The run loop has to be run to do anything. Apple's application main function takes care of this for you on the main thread.
A run loop is run in a specific mode. The "common mode" is actually a set of modes, and there is an API for adding modes to that set.
A run loop's main purpose is to monitor timers and run loop sources. Each source is registered with a specific run loop for a specific mode, and will only be checked at the appropriate time when the runloop is running in that mode.
The run loop goes through several stages in each go around its loop, such as checking timers and checking other event sources. If it finds that any source is ready to fire, it triggers the appropriate callback.
Aside from using ready-made run loop tools, you can create your own run loop sources as well as registering a run loop observer to track the progress of the run loop.
One major pitfall is forgetting to run the run loop while waiting for a callback from a runloop source. This is sometimes a problem when you decide to busy-wait for something to happen on the main thread, but you're most likely to run into it when you create your own thread and register a runloop source with that runloop. You are responsible for establishing an autorelease pool and running the runloop if needed on non-main threads, since the application main function will not be there to do it for you.

You would do better to read Apple's Concurrency Programming Guide instead, which suggests alternatives to the runloop mechanism such as operation queues and dispatch sources. The "Replacing Run-Loop Code" section of the "Migrating Away from Threads" chapter suggests using dispatch sources instead of runloop sources to handle events.
複製代碼

對iOS中runloop使用場景的一次總結