这是我参与8月更文挑战的第21天，活动详情查看： 8月更文挑战

所谓卡顿，就是App在主线程上无法响应用户交互的现象。如果一个App出现了长时间的卡顿，那么极有可能流失大量用户；所以卡顿对App的负面影响巨大，是我们必须要面对并解决的问题；

卡顿发生的原因

卡顿的发生通常有以下几个原因：

UI过于复杂，图文混排的绘制量过大；
在主线程上进行同步的网络请求；
在主线程上进行大量的IO操作；
函数运算量过大，持续占用较高的CPU；
死锁和主子线程抢锁；

那么，我们应该如何监控卡顿现象的发生呢？可能有人第一反应就是去监控FPS；

FPS是一秒钟显示的帧数，也就是一秒内画面变化的数量。如果按照我们经常看的动画片来说，那么动画片的FPS就是24，是达不到满帧的60的。也就是对于动画片来说，24帧虽然不足60帧，也没有60帧来的流畅，但是对于我们来说已经是连贯的了，所以并不是24帧就会卡顿，少于60帧更不能算是卡顿；

所以，单纯的通过监控FPS是很难确定卡顿是否发生的，所以通过监控FPS来监控卡顿的方案并不可取；

那么，我们应该使用什么样的方案来监控卡顿呢？

监控卡顿的最佳方案

对于我们iOS开发来说，监控卡顿就是要去确定在主线程上都做了什么事情？我们知道，线程的消息事件都是依赖与NSRunLoop的，所以从NSRunLoop入手，我们就能够知道在主线程上都调用了哪些方法。我们通过监听NSRunLoop的状态，就能够发现调用方法是否执行时间过长，从而判断出是否会出现卡顿。

我们监控卡顿现象，首推的方案就是：通过监控NSRunLoop的状态来判断是否发生了卡顿；

什么是RunLoop

RunLoop是iOS开发中的一个基本概念，为了理解并运用它，我们应该对其有所了解，了解它可以做哪些事情？以及它为什么可以做到这些事？

RunLoop这个对象在iOS开发中是由CFRunLoop来实现的。简单来说就是RunLoop是用来监听输入源，并进行调度处理的。这里的输入源可以是输入设备、网络、周期性或者延迟时间、异步回调等。

RunLoop会接收两种类型的输入源:

来自另一个线程或者来自不同应用的异步消息；
来自预订时间或者重复间隔的同步事件；

RunLoop的目的是：当有事件要去处理时保持线程忙，当没有事件要去处理时让线程进入休眠；所以了解了RunLoop原理不仅能够运用到监控卡顿上，还可以提高用户的交互体验。通过将那些繁重而不紧急并且会大量占用CPU的任务(如图片加载)，放到空闲的RunLoop模式里执行，就可以避开在UITrackingRunLoopMode这个RunLoop模式时执行。UITrackingRunLoopMode是用户进行滚动操作时会切换到的RunLoop模式，避免在这个RunLoop模式执行繁重的CPU任务，就能避免影响用户交互操作上的体验；

接下来，我们可以通过RunLoop源码来分析一下RunLoop的原理；

RunLoop原理

第一步

通知observers：RunLoop要开始进入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);

接下来触发Source0回调，如果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的六个状态

通过对RunLoop原理的分析，我们可以看到在整个过程中，loop的状态有6个：

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状态定义的值分别是：kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting，也就是要触发source0回调和接收mach_port消息这两个状态。

接下来，我们分析一下，如何针对loop的这两个状态进行监听，以及监控的时间值如何设置才算是合理；

如何检查卡顿

要想监听RunLoop，首先我们需要创建一个CFRunLoopObserverContext的观察者，代码如下：

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

将创建好的观察者runLoopObserver添加到主线程RunLoop的common模式下进行观察。然后创建一个持续的子线程专门用来监控主线程的RunLoop状态。一旦发现进入睡眠前的kCFRunLoopBeforeSources，或者唤醒后的状态kCFRunLoopAfterWaiting，在设置的时间阈值内一直没有发生变化，即可判定为卡顿。之后我们就可以通过dump出的堆栈信息，进一步分析出具体是哪一个方法的执行时间过长。

开启一个子线程监控的代码如下：

//创建子线程监控
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    //子线程开启一个持续的 loop 用来进行监控
    while (YES) {
        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
});

代码中的NSEC_PER_SEC，代表的是触发卡顿的时间阈值，单位是秒。可以看到，我们把这个阈值设置成了3秒。那么，这个3秒的阈值是从何而来呢？这样设置合理吗？

其实，触发卡顿的时间阈值，我们可以根据WatchDog机制来设置。WatchDog在不同状态下设置为不同时间，如下所示：

启动（Launch）：20秒；
恢复（Resume）：10秒；
挂起（Suspend）：10秒；
退出（Quit）：6秒；
后台（Background）：3分钟（在iOS7之前，每次申请10分钟，之后改为每次申请3分钟，可以连续申请，最多申请到10分钟）；

通过WatchDog设置的时间，我们可以把启动的阈值设置为10秒，其他状态则都默认为3秒。总的原则就是要小于WatchDog的限制时间。不过，这个阈值也不用小的太多，原则就是我们要优先解决用户感知最明显的体验问题；

系统函数获取卡顿方法的堆栈信息

子线程监控卡顿之后，还需要记录当前出现卡顿的方法堆栈信息，并适时的推送到服务端公开发着分析，从而解决卡顿问题；那么在这个过程中，我们应该如何获取发生卡顿的方法的堆栈信息呢？

**获取堆栈信息的一种方法是直接调用系统函数。**这种方法的优点很明显，性能消耗少；但是它只能够获取简单的信息，是没有办法配合dSYM来获取具体是哪行代码出了问题的，而且能够获取的信息类型也有限。这种方法，因为性能比较好，所以适用于观察大盘统计卡顿情况，但是想要找到卡顿原因的场景就不太适用。

直接调用系统函数方案的主要思路就是：用signal进行错误信息的提取：

static int s_fatal_signals[] = {
    SIGABRT,
    SIGBUS,
    SIGFPE,
    SIGILL,
    SIGSEGV,
    SIGTRAP,
    SIGTERM,
    SIGKILL,
};

static int s_fatal_signal_num = sizeof(s_fatal_signals) / sizeof(s_fatal_signals[0]);

void UncaughtExceptionHandler(NSException *exception) {
    NSArray *exceptionArray = [exception callStackSymbols]; //得到当前调用栈信息
    NSString *exceptionReason = [exception reason];       //非常重要，就是崩溃的原因
    NSString *exceptionName = [exception name];           //异常类型
}

void SignalHandler(int code)
{
    NSLog(@"signal handler = %d",code);
}

void InitCrashReport()
{
    //系统错误信号捕获
    for (int i = 0; i < s_fatal_signal_num; ++i) {
        signal(s_fatal_signals[i], SignalHandler);
    }
    
    //oc未捕获异常的捕获
    NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);
}

int main(int argc, char * argv[]) {
    @autoreleasepool {
        InitCrashReport();
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

第三方库获取卡顿方法的堆栈信息

另一种方法就是直接使用第三方库来获取堆栈信息，比如PLCrashReporter；这个方法能够定位到出现问题代码的具体位置，而且性能的消耗也不大。所以推荐采用此种方法来获取对战信息；

使用PLCrashReporter来获取堆栈信息，代码实现如下：

// 获取数据
NSData *lagData = [[[PLCrashReporter alloc]
                                          initWithConfiguration:[[PLCrashReporterConfig alloc] initWithSignalHandlerType:PLCrashReporterSignalHandlerTypeBSD symbolicationStrategy:PLCrashReporterSymbolicationStrategyAll]] generateLiveReport];
// 转换成 PLCrashReport 对象
PLCrashReport *lagReport = [[PLCrashReport alloc] initWithData:lagData error:NULL];
// 进行字符串格式化处理
NSString *lagReportString = [PLCrashReportTextFormatter stringValueForCrashReport:lagReport withTextFormat:PLCrashReportTextFormatiOS];
//将字符串上传服务器
NSLog(@"lag happen, detail below: \n %@",lagReportString);

收集到卡顿方法的堆栈信息之后，剩下的就是开发者来根据堆栈信息，分析解决卡顿问题了；

总结

我们的卡顿监控应该放在线上部署，这样可以大范围的收集问题，如果仅仅通过线下收集卡顿的话，那么场景无法被全面覆盖。因为总有一些卡顿问题是少数用户才会发生的；用户反馈的卡顿问题往往只能说在哪个界面卡住了，但是具体是执行到哪个方法是发生了卡顿我们无从得知。"这个界面我们怎么不会卡，测试人员也没出现，就你卡，你到底会不会用App！！！" 通过日志我们也很难定位问题，这个时候线上监控卡顿的重要性就凸显出来了；

偶尔一个问题看似对App的影响不大，但是如果这个问题在某一个版本中大范围的爆发出来，那么聚会称为致命的问题，会变得难以收场；所以针对这种问题，我们要进行预见性的监控，早发现，早解决；另一方面，在遇到问题是能够快速的定位问题，不至于过于被动。面对问题的响应速度往往是评判基础建设优劣的一个重要标准；

iOS开发技巧之使用Runloop监控App卡顿