使用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…

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章