原文鏈接：如何利用 RunLoop 原理去監(jiān)控卡頓？

前言

一個(gè)App想要提升用戶體驗(yàn)最重要的就是 降低程序崩潰 和 提升程序流暢度。前者在上一篇 崩潰監(jiān)控 中稍有介紹，而今天要看的就是如何監(jiān)控程序的卡頓，從而有目的性的優(yōu)化程序流暢度，提升用戶體驗(yàn)倍试。

雖然達(dá)到程序60FPS穩(wěn)定運(yùn)行是我們的終極目標(biāo)，但是原文中戴銘老師直接否定了通過 監(jiān)控FPS 來判斷程序是否卡頓的方案菠剩，進(jìn)而提出使用 監(jiān)控主線程RunLoop的狀態(tài) 來判斷是否卡頓的方法易猫。

RunLoop監(jiān)控卡頓原理

1 卡頓情況

• 復(fù)雜 UI、圖文混排的繪制量過大
• 在主線程上做網(wǎng)絡(luò)同步請(qǐng)求
• 在主線程做大量 IO 操作
• 運(yùn)算量過大具壮，CPU持續(xù)高占用
• 死鎖或主子線程間搶鎖

2 RunLoop基礎(chǔ)概念

簡單來說准颓，RunLoop 的工作模式就是，當(dāng)有事件要處理時(shí)保持線程忙棺妓，當(dāng)沒有事件要處理時(shí)讓線程進(jìn)入休眠攘已。

2.1 相關(guān)的類：

CFRunLoopRef    
CFRunLoopModeRef 
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef

2.2 Mode:

一個(gè)RunLoop包含若干個(gè)Mode，每個(gè)Mode又包含若干個(gè)Source/Timer/Observer怜跑。

系統(tǒng)默認(rèn)注冊(cè)了5個(gè)Mode样勃。每次調(diào)用RunLoop的主函數(shù)時(shí)吠勘，只能指定其中一個(gè)Mode，也就是說RunLoop中的Mode在不斷切換峡眶。

kCFRunLoopDefaultMode //App的默認(rèn)Mode剧防，通常主線程是在這個(gè)Mode下運(yùn)行
UITrackingRunLoopMode //界面跟蹤 Mode，用于 ScrollView 追蹤觸摸滑動(dòng)辫樱，保證界面滑動(dòng)時(shí)不受其他 Mode 影響
UIInitializationRunLoopMode // 在剛啟動(dòng) App 時(shí)第進(jìn)入的第一個(gè) Mode峭拘，啟動(dòng)完成后就不再使用
GSEventReceiveRunLoopMode // 接受系統(tǒng)事件的內(nèi)部 Mode，通常用不到
kCFRunLoopCommonModes //這是一個(gè)占位用的Mode狮暑，不是一種真正的Mode

2.3 工作過程：

工作過程大致總結(jié)為上圖的10個(gè)步驟：
1 通知Observers鸡挠，RunLoop要開始進(jìn)入loop了
2-3 進(jìn)入loop，開啟一個(gè) do while 卑崮校活線程拣展。通知Observers，將要處理Timer回調(diào)和Source0回調(diào)缔逛，接著執(zhí)行block

// 通知 Observers RunLoop 會(huì)觸發(fā) Timer 回調(diào)
if (currentMode->_observerMask & kCFRunLoopBeforeTimers)
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
// 通知 Observers RunLoop 會(huì)觸發(fā) Source0 回調(diào)
if (currentMode->_observerMask & kCFRunLoopBeforeSources)
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
// 執(zhí)行 block
__CFRunLoopDoBlocks(runloop, currentMode);

4-5 處理Source0回調(diào)备埃，如果這里有Source1是ready狀態(tài)，就會(huì)跳轉(zhuǎn)handle_msg去處理消息

if (MACH_PORT_NULL != dispatchPort ) {
    Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
    if (hasMsg) goto handle_msg;
}

6 回調(diào)觸發(fā)后译株，通知Observers瓜喇，該線程即將進(jìn)入休眠
7-8 進(jìn)入休眠后挺益，如果出現(xiàn)下面四個(gè)事件時(shí)RunLoop會(huì)通知Observers歉糜，線程被喚醒了

• 基于 port 的 Source 事件
• Timer 時(shí)間到
• RunLoop 超時(shí)
• 被調(diào)用者喚醒

9 RunLoop 被喚醒后就重新開始處理消息，重復(fù)2-3的過程
10 當(dāng)被外部強(qiáng)制停止或loop超時(shí)望众，就不繼續(xù)下一個(gè)loop了匪补，此時(shí)通知Observers，即將退出loop

if (sourceHandledThisLoop && stopAfterHandle) {
     // 事件已處理完
    retVal = kCFRunLoopRunHandledSource;
} else if (timeout) {
    // 超時(shí)
    retVal = kCFRunLoopRunTimedOut;
} else if (__CFRunLoopIsStopped(runloop)) {
    // 外部調(diào)用者強(qiáng)制停止
    retVal = kCFRunLoopRunStopped;
} else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
    // mode 為空烂翰，RunLoop 結(jié)束
    retVal = kCFRunLoopRunFinished;
}

2.4 Observer夯缺，loop的六個(gè)狀態(tài)

觀察者，可以監(jiān)聽RunLoop的狀態(tài)改變

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) { 
  kCFRunLoopEntry = (1UL << 0), // 進(jìn)入 loop
  kCFRunLoopBeforeTimers = (1UL << 1), //即將處理  Timer 
  kCFRunLoopBeforeSources = (1UL << 2), //即將處理 Sources0
  kCFRunLoopBeforeWaiting = (1UL << 5), //即將進(jìn)入休眠 
  kCFRunLoopAfterWaiting = (1UL << 6), //剛從休眠中喚醒 
  kCFRunLoopExit = (1UL << 7), // 退出 loop 
  kCFRunLoopAllActivities = 0x0FFFFFFFU //所有狀態(tài)改變
};

3 RunLoop甘耿，通過Observer監(jiān)控卡頓

我們通過RunLoop的工作流程可以知道踊兜，如果在 loop進(jìn)入睡眠前執(zhí)行方法時(shí)間過長（過程2-5） 或者 線程喚醒時(shí)接收消息時(shí)間過長（過程8）而無法處理下一個(gè)事件，我們就可以認(rèn)為線程受阻而出現(xiàn)了卡頓佳恬。

上面兩種情況捏境，我們可以通過監(jiān)聽RunLoop的 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 這兩個(gè)狀態(tài)所停留的時(shí)長來判斷。

如何檢查卡頓

這里我們從老師分享的源碼 截取關(guān)鍵部分 進(jìn)行分析和學(xué)習(xí)毁葱。

#import "SMLagMonitor.h"
#import "SMCallStack.h"
#import "SMCPUMonitor.h"

@interface SMLagMonitor() {
    int timeoutCount;
    CFRunLoopObserverRef runLoopObserver;
    @public
    dispatch_semaphore_t dispatchSemaphore;
    CFRunLoopActivity runLoopActivity;
}
@end

@implementation SMLagMonitor

#pragma mark - Interface
+ (instancetype)shareInstance {
    static id instance = nil;
    static dispatch_once_t dispatchOnce;
    dispatch_once(&dispatchOnce, ^{
        instance = [[self alloc] init];
    });
    return instance;
}

- (void)beginMonitor {
    //監(jiān)測(cè)卡頓
    if (runLoopObserver) {
        return;
    }
    dispatchSemaphore = dispatch_semaphore_create(0); //Dispatch Semaphore保證同步
    //創(chuàng)建一個(gè)觀察者
    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                              kCFRunLoopAllActivities,
                                              YES,
                                              0,
                                              &runLoopObserverCallBack,
                                              &context);
    //將觀察者添加到主線程runloop的common模式下的觀察中
    CFRunLoopAddObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);
    
    //創(chuàng)建子線程監(jiān)控
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        //子線程開啟一個(gè)持續(xù)的loop用來進(jìn)行監(jiān)控
        while (YES) {
            long semaphoreWait = dispatch_semaphore_wait(dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 3*NSEC_PER_MSEC));
            if (semaphoreWait != 0) {
                if (!runLoopObserver) {
                    timeoutCount = 0;
                    dispatchSemaphore = 0;
                    runLoopActivity = 0;
                    return;
                }
                //兩個(gè)runloop的狀態(tài)垫言，BeforeSources和AfterWaiting這兩個(gè)狀態(tài)區(qū)間時(shí)間能夠檢測(cè)到是否卡頓
                if (runLoopActivity == kCFRunLoopBeforeSources || runLoopActivity == kCFRunLoopAfterWaiting) {
                    // 出現(xiàn)異常情況
                    NSLog(@"monitor trigger");
                    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
                        // 異步提交/上傳錯(cuò)誤的堆棧信息
                    });
                } //end activity
            }// end semaphore wait
            timeoutCount = 0;
        }// end while
    });
    
}

- (void)endMonitor {
    if (!runLoopObserver) {
        return;
    }
    CFRunLoopRemoveObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);
    CFRelease(runLoopObserver);
    runLoopObserver = NULL;
}

#pragma mark - Private
static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info){
    SMLagMonitor *lagMonitor = (__bridge SMLagMonitor*)info;
    lagMonitor->runLoopActivity = activity;
    
    dispatch_semaphore_t semaphore = lagMonitor->dispatchSemaphore;
    dispatch_semaphore_signal(semaphore);
}
@end

思路總結(jié)

通過 RunLoop 的 Observer 監(jiān)控 主線程 中各個(gè)狀態(tài)的變化。如果 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 這兩個(gè)狀態(tài)所停留的時(shí)間過長倾剿，我們便認(rèn)定為發(fā)生了一次主線程卡頓筷频。

具體做法

1 我們需要?jiǎng)?chuàng)建一個(gè) CFRunLoopObserverContext 觀察者，且創(chuàng)建一個(gè) Observer，并監(jiān)控主線程狀態(tài)的變化

CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,kCFRunLoopAllActivities,YES,0,&runLoopObserverCallBack,&context);
//將觀察者添加到主線程runloop的common模式下的觀察中
CFRunLoopAddObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);

這個(gè)Observer會(huì)監(jiān)聽 kCFRunLoopAllActivities（所有狀態(tài)改變）凛捏，并在狀態(tài)改變時(shí)執(zhí)行 runLoopObserverCallBack 中的代碼担忧。

static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info){
    SMLagMonitor *lagMonitor = (__bridge SMLagMonitor*)info;
    lagMonitor->runLoopActivity = activity;
    
    dispatch_semaphore_t semaphore = lagMonitor->dispatchSemaphore;
    dispatch_semaphore_signal(semaphore);
}

這個(gè)閉包中執(zhí)行了4行代碼：
1.1 通過 info 屬性，拿到當(dāng)前類
1.2 記錄當(dāng)前 Observers 的狀態(tài)坯癣，并賦值給成員變量 runLoopActivity
1.3 使用信號(hào)量 dispatch_semaphore_t 監(jiān)控 Observers 狀態(tài)間停留的時(shí)長涵妥。這里獲取當(dāng)前類聲明的 dispatch_semaphore_t 信號(hào)量屬性
1.4 激活信號(hào)量，通過 dispatch_semaphore_signal() 方法使正在等待的信號(hào)量繼續(xù)執(zhí)行

對(duì)應(yīng)之前創(chuàng)建 dispatch_semaphore_t 對(duì)象的的代碼是：

dispatchSemaphore = dispatch_semaphore_create(0); //Dispatch Semaphore保證同步

2 創(chuàng)建一個(gè)子線程坡锡，使用while循環(huán)迸钔活，并通過信號(hào)量阻塞該線程

long semaphoreWait = dispatch_semaphore_wait(dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 3*NSEC_PER_MSEC));
if (semaphoreWait != 0) {
  // Returns zero on success, or non-zero if the timeout occurred.
}

dispatch_semaphore_wait 這個(gè)方法會(huì)阻塞當(dāng)前線程一段時(shí)間鹉勒，如果 在阻塞時(shí)間內(nèi)收到激活信號(hào) 或者 阻塞時(shí)間超時(shí)帆锋，代碼會(huì)繼續(xù)執(zhí)行，如果超時(shí)禽额，該方法的返回值為 非0

對(duì)應(yīng)前面的閉包中的代碼锯厢，如果各狀態(tài)切換沒有發(fā)生阻塞，那么會(huì)及時(shí)發(fā)出信號(hào)量的激活信號(hào)脯倒，此時(shí) dispatch_semaphore_wait 方法的返回值為0实辑，不視為卡頓。反之各狀態(tài)耗時(shí)過長藻丢，沒有及時(shí)發(fā)出信號(hào)剪撬，dispatch_semaphore_wait 方法的返回值為非0，就視為發(fā)生卡頓悠反。

3 觸發(fā)卡頓的時(shí)間閾值
我們根據(jù) WatchDog 機(jī)制來設(shè)置残黑。

• 啟動(dòng) 20s
• 恢復(fù) 10s
• 掛起 10s
• 退出 6s
• 后臺(tái) 3min（iOS7之前每次申請(qǐng)10min，之后改為3min斋否，可以連續(xù)申請(qǐng)梨水，最多申請(qǐng)到10min）

總的原則就是，要小于 WatchDog 的限制時(shí)間茵臭，3s僅做參考值疫诽。

4 獲取卡頓的方法堆棧信息
監(jiān)控到卡頓發(fā)生后，自然要解決問題旦委，那么如何獲取卡頓的堆棧信息呢奇徒？

原文中推薦的是直接用 plcrashreporter 能夠定位到問題代碼的具體位置，而且性能消耗也不大社证。
具體使用的代碼：

// 獲取數(shù)據(jù)
NSData *lagData = [[[PLCrashReporter alloc] initWithConfiguration:[[PLCrashReporterConfig alloc] initWithSignalHandlerType:PLCrashReporterSignalHandlerTypeBSD symbolicationStrategy:PLCrashReporterSymbolicationStrategyAll]] generateLiveReport];
// 轉(zhuǎn)換成 PLCrashReport 對(duì)象
PLCrashReport *lagReport = [[PLCrashReport alloc] initWithData:lagData error:NULL];
// 進(jìn)行字符串格式化處理
NSString *lagReportString = [PLCrashReportTextFormatter stringValueForCrashReport:lagReport withTextFormat:PLCrashReportTextFormatiOS];
// 將字符串上傳服務(wù)器
NSLog(@"lag happen, detail below: \n %@",lagReportString);

最后

現(xiàn)在逼龟，我們可以監(jiān)控卡頓，并且獲取發(fā)生卡頓的方法信息了追葡。
這里涉及的知識(shí)主要包括了 RunLoop 和 信號(hào)量（線程鎖知識(shí)）腺律。當(dāng)然也只是皮毛奕短，更多是需要我們自己去實(shí)戰(zhàn)和應(yīng)用。
比起事后排查和改進(jìn)匀钧，我們更應(yīng)該養(yǎng)成良好且正確的代碼習(xí)慣翎碑，通常情況下，設(shè)備的性能都足以支撐正確程序的流暢運(yùn)行之斯。
說回提升用戶體驗(yàn)的話題日杈，我覺得更重要的是從產(chǎn)品角度和產(chǎn)品交互出發(fā)，卡頓監(jiān)控只是一項(xiàng)必做的基本功課佑刷。好的產(chǎn)品交互才是提升用戶體驗(yàn)的重頭戲莉擒。