使用RunLoop檢測卡頓

卡頓的緣由：

• 複雜UI、圖文混排的繪製量過大；
• 在主線程作網絡同步請求；
• 在主線程作大量的IO操做；
• 運算量過大，CPU持續高佔用；
• 死鎖和主子線程搶鎖；

RunLoop：

對於iOS開發來講，監控卡頓就是要去找到主線程上都作了那些事。咱們都知道，線程的消息事件是依賴於NSRunLoop的，因此從NSRunLoop入手，就能夠知道主線程上都調用了哪些方法，咱們經過監聽NSRunLoop的狀態，就能發現調用方法是否執行時間過長，從而判斷出是否會出現卡頓。

因此這裏推薦的監控卡頓的方案是：經過監控RunLoop的狀態來判斷是否會出現卡頓。

RunLoop這個對象，在iOS裏是由CFRunLoop實現。簡單來講，RunLoop是用來監聽輸入源，進行調度處理的。這裏的輸入源能夠是輸入設備、網絡、週期性或者延遲時間、異步回調。RunLoop會接受兩種類型的輸入源：一種是來自另外一個線程或者來自不一樣應用的異步消息；另外一種是來自預約時間或者重複間隔的同步事件。

RunLoop的目的是，當有事件要去處理時保持線程忙，當沒有事件要處理時讓線程進入休眠。因此，瞭解RunLoop原理不光可以運用到監控卡頓上，還能夠提升用戶的交互體驗。經過將那些繁重而不緊急會大量佔用CPU的任務(好比圖片加載)，放到空閒的RunLoop模式裏執行，就能夠避開在UITrackingRunLoopMode這個RunLoop模式時執行。UIUITrackingRunLoopMode是用戶進行滾動操做時會切換的RunLoop模式。避免在這個RunLoop模式執行繁重的CPU任務，就能避免影響用戶交互操做上的體驗。

RunLoop的原理：

第一步

通知observers:Runloop要開始進入loop了。緊接着就進入loop。代碼以下：

//通知 observers
if (currentMode->_observerMask & kCFRunLoopEntry ) 
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);
//進入 loop
result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);複製代碼

第二步

開啓一個do while來保活線程。通知Observers:RunLoop會觸發Timer回調、Source0回調，接着執行加入block。代碼以下：

// 通知 Observers RunLoop 會觸發 Timer 回調
if (currentMode->_observerMask & kCFRunLoopBeforeTimers)
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
// 通知 Observers RunLoop 會觸發 Source0 回調
if (currentMode->_observerMask & kCFRunLoopBeforeSources)
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
// 執行 block
__CFRunLoopDoBlocks(runloop, currentMode);複製代碼

接下來，觸發Sourece0回調，若是有Source1是ready狀態的話，就會跳轉到handle_msg去處理消息。代碼以下：

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

第三步

回調觸發後，通知到Observers:RunLoop的線程將進入休眠(sleep)狀態，代碼以下：

Boolean poll = sourceHandledThisLoop || (0ULL == timeout_context->termTSR);
if (!poll && (currentMode->_observerMask & kCFRunLoopBeforeWaiting)) {
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
}複製代碼

第四步

進入休眠後，會等待mach_port的消息，以再次喚醒。只有在下面四個事件出現纔會被再次喚醒：

• 基於port的Source事件；
• Timer時間到；
• RunLoop超時；
• 被調用者喚醒。

等待喚醒的代碼以下：

do {
    __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort) {
        // 基於 port 的 Source 事件、調用者喚醒
        if (modeQueuePort != MACH_PORT_NULL && livePort == modeQueuePort) {
            break;
        }
        // Timer 時間到、RunLoop 超時
        if (currentMode->_timerFired) {
            break;
        }
} while (1);複製代碼

第五步

喚醒時通知Observer:RunLoop的線程剛剛被喚醒了。代碼以下：

if (!poll && (currentMode->_observerMask & kCFRunLoopAfterWaiting))
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);複製代碼

第六步

RunLoop被喚醒後就要進行處理消息了：

• 若是是Timer時間到的話，就觸發Timer的回調；
• 若是是dispatch的話，就執行block；
• 若是是Source1事件的話，就處理這個事件。

消息執行完後，就執行加到loop裏的block。代碼以下：

handle_msg:
// 若是 Timer 時間到，就觸發 Timer 回調
if (msg-is-timer) {
    __CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
} 
// 若是 dispatch 就執行 block
else if (msg_is_dispatch) {
    __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
} 

// Source1 事件的話，就處理這個事件
else {
    CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
    sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
    if (sourceHandledThisLoop) {
        mach_msg(reply, MACH_SEND_MSG, reply);
    }
}複製代碼

第七步

根據當前RunLoop的狀態來判斷是否須要走下一個loop。當被外部強制中止或loop超時，就再也不繼續下一個loop了，不然繼續走下一個loop。代碼以下：

if (sourceHandledThisLoop && stopAfterHandle) {
     // 事件已處理完
    retVal = kCFRunLoopRunHandledSource;
} else if (timeout) {
    // 超時
    retVal = kCFRunLoopRunTimedOut;
} else if (__CFRunLoopIsStopped(runloop)) {
    // 外部調用者強制中止
    retVal = kCFRunLoopRunStopped;
} else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
    // mode 爲空，RunLoop 結束
    retVal = kCFRunLoopRunFinished;
}複製代碼

整個RunLoop的過程，能夠總結爲以下所示的一張圖片。

CFRunLoop完整代碼：opensource.apple.com/source/CF/C…

RunLoop的六個狀態

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry , // 進入 loop
    kCFRunLoopBeforeTimers , // 觸發 Timer 回調
    kCFRunLoopBeforeSources , // 觸發 Source0 回調
    kCFRunLoopBeforeWaiting , // 等待 mach_port 消息
    kCFRunLoopAfterWaiting ), // 接收 mach_port 消息
    kCFRunLoopExit , // 退出 loop
    kCFRunLoopAllActivities  // loop 全部狀態改變
}複製代碼

若是RunLoop的線程，進入睡眠前方法的執行時間過長而致使沒法進入睡眠，或者線程喚醒後接受消息時間過長而沒法進入下一步的話，就能夠認爲是線程受阻了。若是這個線程是主線程的話，表現就是出現卡頓。

因此，若是咱們要利用RunLoop原理來監控卡頓的話，就要關注這兩個階段。RunLoop在進入睡眠以前和喚醒後的兩個loop狀態定義的值，分別是kCFRunLoopBeforeSource和kCFRunLoopAfterWaiting，也就是要觸發Source0回調和接受mac_port消息兩個狀態。

如何檢查卡頓？

首先須要建立一個CFRunLoopObserverContext觀察者，代碼以下:

CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,kCFRunLoopAllActivities,YES,0,&runLoopObserverCallBack,&context);複製代碼

將建立好的觀察者runLoopObserver添加到主線程RunLoop的common模式下觀察，而後，建立一個持續的子線程專門用來監控主線程的RunLoop狀態。

一旦發現進入睡眠前的kCFRunLoopBeforeSources狀態，或者喚醒後的狀態kCFRunLoopAfterWaiting，在設置的時間閾值內一直沒有變化，便可認定爲卡頓。

開啓子線程監控的代碼以下：

//建立子線程監控
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    //子線程開啓一個持續的 loop 用來進行監控
    while (YES) {
        //semaphoreWait 信號等待的時間
        long semaphoreWait = dispatch_semaphore_wait(dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 3 * NSEC_PER_SEC));
        if (semaphoreWait != 0) {
            if (!runLoopObserver) {
                timeoutCount = 0;
                dispatchSemaphore = 0;
                runLoopActivity = 0;
                return;
            }
            //BeforeSources 和 AfterWaiting 這兩個狀態可以檢測到是否卡頓
            if (runLoopActivity == kCFRunLoopBeforeSources || runLoopActivity == kCFRunLoopAfterWaiting) {
                //將堆棧信息上報服務器的代碼放到這裏
            } //end activity
        }// end semaphore wait
        timeoutCount = 0;
    }// end while
});複製代碼

獲取堆棧信息使用PLCrashReporter.

本文內容均來自於 time.geekbang.org/column/arti…

本文demo:github.com/yqy159/LogM…