理解 OC 中 RunLoop

什么是RunLoop？

可以簡單理解為，讓程式保持運行的一個while回圈，這個回圈內監聽各種事件（如觸摸事件、performSelector、定時器NSTimer等），沒有事件的時候睡眠，從而有效的利用CPU（只有在有事件的時候才用CPU，沒事件的時候睡眠）

不管RunLoop有多復雜，其本質就是上面所說的：一個回圈，有事件的時候處理事件，無事件的時候休眠（這里的睡眠是指用戶態切換到內核態，這樣的休眠執行緒是被掛起的，不會再占用cpu資源），

RumLoop與執行緒有如下關系：

• 一個執行緒只有一個RunLoop物件
• 主執行緒的RunLoop默認已經創建好了，而子執行緒的需要手動創建，
• RunLoop在第一次獲取時創建，在執行緒結束時銷毀，

我們驗證一下，在main函式回傳之前，列印一下：

int main(int argc, char *argv[])
{
    NSString *appDelegateClassName;
    @autoreleasepool {
        // Setup code that might create autoreleased objects goes here.
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
    }
    int ret = UIApplicationMain(argc, argv, nil, appDelegateClassName);
    NSLog(@"after ret");
    return ret;
}

結果沒有列印，這說明主行程已經進入了一個RunLoop主了，主行程不結束，就跳不出RunLoop，也就執行不了之后的列印，

我們列印一下主執行緒的RunLoop試試：

- (void)viewDidLoad {
    [super viewDidLoad];
    NSLog(@"%@", [NSRunLoop currentRunLoop]);
}

// 列印結果（只取關鍵資訊）：
// CFRunLoop 0x600001704700
// current mode = kCFRunLoopDefaultMode,

這說明主執行緒在一個RunLoop中，并且當前的運行模式是kCFRunLoopDefaultMode

這樣感覺RunLoop很簡單，但它又很復雜，因為要考慮的因素有很多，比如各種事件的處理順序，定時器、多執行緒等等

對于一個復雜問題，解決方法之一就是抽象，蘋果為解決上面的問題，抽象出了RunLoop物件，RunLoop中包含多個Mode類，每個mode類中包含若干個 Source，Observer和Timer類，關系如下：

Mode是RunLoop的運行模式，有五類：

kCFRunLoopDefaultMode //App的默認Mode，通常主執行緒是在這個Mode下運行
UITrackingRunLoopMode //界面跟蹤 Mode，用于 ScrollView 追蹤觸摸滑動，保證界面滑動時不受其他 Mode 影響
UIInitializationRunLoopMode // 在剛啟動 App 時第進入的第一個 Mode，啟動完成后就不再使用
GSEventReceiveRunLoopMode // 接受系統事件的內部 Mode，通常用不到
kCFRunLoopCommonModes // 這是一個占位用的Mode，不是一種真正的Mode，可以簡單理解為kCFRunLoopDefaultMode和UITrackingRunLoopMode的結合

這里的Source是事件源，比如觸摸事件，

Observer是觀察者，監聽事件源的事件，可以簡單理解為執行緒，比如主執行緒RunLoop的的Observer是主執行緒，

還有一些規定：

• RunLoop雖然有多個Mode，但RunLoop函式執行的時候，只能指定一個Mode
• 如果要切換Mode，需要等到一個Loop回圈結束，再讓新的Mode進入

上面說一個RunLoop只有一個Mode在執行，下面做個試驗看看：

@interface ViewController ()

@property (weak, nonatomic) IBOutlet UITextView *textView;

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerTest) userInfo:nil repeats:YES];
    [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
}

- (void)timerTest {
    NSLog(@"%s", __func__);
}

@end

這里我們在ViewControlller里面創建了一個timer，把他加到NSDefaultRunLoopMode中，這個ViewControlller有個可以滾動的UITextView（繼承UIScrollView，UIScrollView默認的Mode是UITrackingRunLoopMode）

當我們滑動UITextView的時候，timer停止觸發事件了，說明RunLoop的Mode從Default切換到了UITrackingRunLoopMode

解決方法就是把timer放入kCFRunLoopCommonModes中，這個Mode相當于同時是kCFRunLoopDefaultMode和UITrackingRunLoopMode：

[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

上面是一個經典的例子，可以解決在UIScrollView（包括其子類）中有NSTimer定時的場景，

受此啟發，我們可以用RunLoop解決卡頓問題，有一種卡頓問題就是UITableView中有很多高清大圖需要載入，在滑動螢屏的時候卡頓，

我們先分析一下卡頓的原因：最根本的原因是RunLoop轉一圈的時間太長了，因為一次RunLoop回圈需要決議很多張高清大圖，系統渲染每一張高清大圖都需要一定的時間，這樣需要等到渲染的RunLoop結束之后，才能切換滑動螢屏RunLoop的Mode（UITrackingRunLoopMode），解決方法就是：

• 創建一個定時器：每間隔一定時間（可以是0.01s）執行一個空方法來喚醒RunLoop
• 將加載圖片的方法裝入block，將block加入一個有數量限制的陣列，當block超過最大數量限制，移除最早添加的block
• 監聽RunLoop的蘇醒，蘇醒回掉就執行一次就從陣列中取出一個block事件執行，執行完的事件從陣列中洗掉

這樣設計讓RunLoop的每次回圈只執行一個加載圖片的block（減少RunLoop單次回圈的時間），給陣列設定一個最大數量限制，可以防止同一時間需要渲染的圖片過多（減少RunLoop渲染圖片的總時間），

下面我們可以看看RunLoop里面長什么樣了：

RunLoop內部邏輯

這里引入了新概念：source0是觸摸事件和所有執行performSelector方法，source1是基于port的執行緒間的通信，

這里我們可以大概看出RunLoop中處理事件的順序，可以簡要的總結為：

1. 先通知Timer，Sources要處理事件了
2. 處理source0
3. 看看有沒有source1，沒有就休眠，有就不休眠
4. 休眠狀態下sources，timer，dispatch，手動都可以喚醒
5. 3結束或者4喚醒后，就開始處理各種其他事件（timer，source1，dispatch）
6. 如果第五步處理了至少一個事件，則開始新一輪的RunLoop，否則退出RunLoop

以上邏輯可以推出，在RunLoop中，只要有任何一個事件，RunLoop就不會退出，除非是RunLoop在休眠超時被喚醒或者外部強制停止，才會退出，

下面用一個例子感受一下RunLoop里的邏輯：

- (void)viewDidLoad {
    [super viewDidLoad];

    [self createObserver];
    
    [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timerFired) userInfo:nil repeats:YES];
}

- (void)timerFired
{
    NSLog(@"---- timer fired ----");
}

- (void)createObserver
{
    //創建監聽者
    /*
    第一個引數 CFAllocatorRef allocator：分配存盤空間 CFAllocatorGetDefault()默認分配
    第二個引數 CFOptionFlags activities：要監聽的狀態 kCFRunLoopAllActivities 監聽所有狀態
    第三個引數 Boolean repeats：YES:持續監聽 NO:不持續
    第四個引數 CFIndex order：優先級，一般填0即可
    第五個引數 ：回呼 兩個引數observer:監聽者 activity:監聽的事件
    */

    CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
        switch (activity) {
            case kCFRunLoopEntry:
                NSLog(@"RunLoop進入");
                break;
            case kCFRunLoopBeforeTimers:
                NSLog(@"RunLoop要處理Timers了");
                break;
            case kCFRunLoopBeforeSources:
                NSLog(@"RunLoop要處理Sources了");
                break;
            case kCFRunLoopBeforeWaiting:
                NSLog(@"RunLoop要休息了");
                break;
            case kCFRunLoopAfterWaiting:
                NSLog(@"RunLoop醒來了");
                break;
            case kCFRunLoopExit:
                NSLog(@"RunLoop退出了");
                break;

            default:
                break;
        }
    });

    CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);  // 添加監聽者，關鍵！
    CFRelease(observer); // 釋放
}

這里給RunLoop創建了一個觀察者，觀察者的回呼列印RunLoop里的邏輯，另外有一個Timer每隔1.0秒觸發一下，結果如下：

// 23:26:30 RunLoop醒來了
// 23:26:30 ---- timer fired ----
// 23:26:30 RunLoop要處理Timers了
// 23:26:30 RunLoop要處理Sources了
// 23:26:30 RunLoop要休息了
// 23:26:31 RunLoop醒來了
// 23:26:31 ---- timer fired ----
// 23:26:31 RunLoop要處理Timers了
// 23:26:31 RunLoop要處理Sources了
// 23:26:31 RunLoop要休息了

可以看到，Timer要觸發的時候，喚醒了RunLoop，RunLoop醒來后去處理Timer，執行了Timer的方法（列印---- timer fired ----），然后RunLoop回到回圈的開頭，通知觀察者要處理Timers和Sources了，結果發現沒有要處理的，然后就去休息了，如此回圈，，，基本和上面的邏輯一致，

這里介紹一個RunLoop的應用：

創建一個常駐執行緒

首先我們創建一個繼承自NSThread的類BZThread，用來列印銷毀時候的資訊，然后在viewDidLoad中創建一個執行緒：

@interface BZThread : NSThread
@end
  
@implementation BZThread
- (void)dealloc {
    NSLog(@"BZThread is dealloced");
}
@end

@interface ViewController ()

@property NSThread *thread;

@end

@implementation ViewController


- (void)viewDidLoad {
    [super viewDidLoad];
    NSThread *thread = [[BZThread alloc] initWithTarget:self selector:@selector(threadTest) object:nil];
    self.thread = thread;
    [self.thread start];
}

- (void)threadTest {
    NSLog(@"thread is created");
}

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    [self performSelector:@selector(doSomethingInThread) onThread:self.thread withObject:nil waitUntilDone:NO];
}

- (void)doSomethingInThread {
    NSLog(@"doSomethingInThread is fired");
  
}

@end

// BZThread is created

我們發現，執行緒是被創建了，也被ViewControlelr持有了（沒有馬上被銷毀），但是我們在這個執行緒里執行方法沒有反應，這說明這個執行緒的RunLoop沒有運行起來，

解決方法是在這個執行緒方法里，給這個執行緒的RunLoop創建一個Mode：

- (void)threadTest {
    [[NSRunLoop currentRunLoop] addPort:[NSPort port] forMode:NSDefaultRunLoopMode];
    [[NSRunLoop currentRunLoop] run];
    NSLog(@"thread is created");
}

點擊螢屏，我們就執行了執行緒的方法了：

// doSomethingInThread is fired

這是因為，雖然一個執行緒對應一個RunLoop，但一個RunLoop至少需要一個Mode，才能跑起來，主執行緒默認就有Mode了，而新的執行緒需要我們手動去創建新的Mode，

最后介紹一個RunLoop的應用：

檢測卡頓：

如果 RunLoop 的執行緒，進入睡眠前方法的執行時間過長而導致無法進入睡眠，或者執行緒喚醒后接收訊息時間過長而無法進入下一步的話，就可以認為是執行緒受阻了，如果這個執行緒是主執行緒的話，表現出來的就是出現了卡頓，

如何檢查卡頓呢？需要創建一個持續的子執行緒專門用來監控主執行緒的 RunLoop 狀態，一旦發現進入睡眠前的 狀態，或者喚醒后的狀態，在設定的時間閾值內一直沒有變化，即可判定為卡頓，接下來，我們就可以 dump 出堆疊的資訊，從而進一步分析出具體是哪個方法的執行時間過長，