iOS性能优化-RunLoop卡顿检测-技术圈

👇👇关注后回复 “进群” ，拉你进程序员交流群👇👇

作者丨Jerod

来源：

https://segmentfault.com/a/1190000040415354

卡顿主要表现为主线程卡死，不响应用户动作或者响应很慢，这种体验很差，会让用户对产品的认可度急速下滑，如果不及时优化，最终会导致用户流失。

那么，哪些情况会导致主线程卡顿呢？大体有如下几个方面：

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

检测方案

为了优化卡顿，我们需要准确的知道哪里发生了卡顿，然后才能有针对性的进行优化，所以在开始优化之前我们需要去监控卡顿发生的地方。那么问题来了，怎么监控卡顿？

检测 FPS 变化幅度是一种方案，但是并不推荐，原因我引用[戴铭]()大佬在[如何利用 RunLoop 原理去监控卡顿？]()一文中的描述：”FPS 是一秒显示的帧数，也就是一秒内画面变化数量。如果按照动画片来说，动画片的 FPS 就是 24，是达不到 60 满帧的。也就是说，对于动画片来说，24 帧时虽然没有 60 帧时流畅，但也已经是连贯的了，所以并不能说 24 帧时就算是卡住了。“

另一种推荐的方案就是 RunLoop。为什么Runloop可以做到卡顿监控？我们知道程序中的任务都是在线程中执行，而线程依赖于 RunLoop，并且RunLoop总是在相应的状态下执行任务，执行完成以后会切换到下一个状态，如果在一个状态下执行时间过长导致无法进入下一个状态就可以认为发生了卡顿，所以可以根据主线程 RunLoop 的状态变化检测任务执行时间是否太长。至于多长时间算作卡顿可以依据自己的需要来设置，一般情况下可以设置1秒钟作为阀值。

RunLoop 的状态如下：

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry = (1UL << 0), // 进入Runloop
    kCFRunLoopBeforeTimers = (1UL << 1), // 处理Timer事件
    kCFRunLoopBeforeSources = (1UL << 2), // 处理Source事件
    kCFRunLoopBeforeWaiting = (1UL << 5), // 进入休眠
    kCFRunLoopAfterWaiting = (1UL << 6), // 唤醒
    kCFRunLoopExit = (1UL << 7), // 退出Runloop
    kCFRunLoopAllActivities = 0x0FFFFFFFU // 所有状态
};

RunLoop 的执行流程：

在一次循环中，Timer事件、Source事件、唤醒后事件如果处理时间过长都可以认为卡顿了；当然还有一种休眠前的事件，但是监控这个事件时需要特别小心，因为不能把休眠的时间算作是卡顿的。

具体实现

大体的思路有了，那怎么来实现呢？要监控 RunLoop 事件，首先需要一个观察者：

CFRunLoopObserverContext context = {
    0, // 直接传0就好
    (__bridge void*)self, // 对应回调中地方 void *info 参数
    &CFRetain, // 内存管理方案
    &CFRelease, // 内存管理方案
    NULL
};

observer = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &runloopObserverCallback, &context);

观察主线程：

CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);

在回调函数中，需要记录下当前的模式以便于后面检测任务的处理：

static void runloopObserverCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
    [LagMonitor shared]->currentActivity = activity;
    
    dispatch_semaphore_t sema = [LagMonitor shared]->semaphore;
    dispatch_semaphore_signal(sema);
}

然后，不能在主线程中进行观察任务，因为我们观测的是主线程本身的任务，把观察后的处理任务也加到主线程会使得主线程任务不纯粹，影响检测结果的准确性。所以，我们在子线程中处理检测任务，相应的代码和释义如下：

// 在子线程中监控卡顿
semaphore = dispatch_semaphore_create(0);
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    // 开启持续的loop来监控
    while ([LagMonitor shared]->isMonitoring) {
        if ([LagMonitor shared]->currentActivity == kCFRunLoopBeforeWaiting)
        {
          // 处理休眠前事件观测
            __block BOOL timeOut = YES;
            dispatch_async(dispatch_get_main_queue(), ^{
                timeOut = NO; // timeOut任务
            });
            [NSThread sleepForTimeInterval:WAIT_TIME];
            // WAIT_TIME 时间后,如果 timeOut任务 任未执行, 则认为主线程前面的任务执行时间过长导致卡顿
            if (timeOut) {
                [LXDBacktraceLogger lxd_logMain]; // 输出堆栈信息
            }
        }
        else
        {
            // 处理 Timer,Source,唤醒后事件
            // 同步等待时间内,接收到信号result=0, 超时则继续往下执行并且result!=0
            long result = dispatch_semaphore_wait([LagMonitor shared]->semaphore, dispatch_time(DISPATCH_TIME_NOW, OUT_TIME));
            if (result != 0) { // 超时
                if (![LagMonitor shared]->observer) {
                    [[LagMonitor shared] endMonitor];
                    continue;
                }
                if ([LagMonitor shared]->currentActivity == kCFRunLoopBeforeSources ||
                    [LagMonitor shared]->currentActivity == kCFRunLoopAfterWaiting  ||
                    [LagMonitor shared]->currentActivity == kCFRunLoopBeforeTimers) {

                    [LXDBacktraceLogger lxd_logMain]; // 输出堆栈信息
                }
            }
        }
    }
});

项目的全部代码都在这里，其中 [LXDBacktraceLogger lxd_logMain] 使用了 LXDAppFluecyMonitor 中的开源代码输出堆栈信息。

检测效果

我们运行看一下效果，首先调用

[[LagMonitor shared] beginMonitor];

查看日志输出：

runloop卡顿监控[45103:2594859] touchesBegan

runloop卡顿监控[45103:2595184] 主线程卡顿 Backtrace of Thread 771:
======================================================================================
libsystem_kernel.dylib         0x7fff5e703756 __semwait_signal + 10
Foundation                     0x7fff2085188c +[NSThread sleepForTimeInterval:] + 170
runloopÂç°È°øÁõëÊéß            0x107bbde06 -[ViewController touchesBegan:withEvent:] + 118
UIKitCore                      0x7fff246a8b63 forwardTouchMethod + 321
UIKitCore                      0x7fff246a8a11 -[UIResponder touchesBegan:withEvent:] + 49
UIKitCore                      0x7fff246b7ad1 -[UIWindow _sendTouchesForEvent:] + 622
UIKitCore                      0x7fff246b9be3 -[UIWindow sendEvent:] + 4774
UIKitCore                      0x7fff246938f6 -[UIApplication sendEvent:] + 633
UIKitCore                      0x7fff2472439c __processEventQueue + 13895
UIKitCore                      0x7fff2471ad0f __eventFetcherSourceCallback + 104
CoreFoundation                 0x7fff2038c37a __CFRUNLOOP_IS_CALLING_OUT_TO_A_SO

日志显示，在 -[ViewController touchesBegan:withEvent:] 中有+[NSThread sleepForTimeInterval:] 发生了卡顿，回到项目中检查代码：

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    NSLog(@"touchesBegan");   
    [NSThread sleepForTimeInterval:2];
}

与日志符合，这里确实发生了卡顿，就可以有针对性的进行优化。

项目地址：runloop卡顿监控

参考资料：

深入理解RunLoop，ibireme

如何利用 RunLoop 原理去监控卡顿？，戴铭

LXDAppFluecyMonitor

-End-

最近有一些小伙伴，让我帮忙找一些面试题资料，于是我翻遍了收藏的 5T 资料后，汇总整理出来，可以说是程序员面试必备！所有资料都整理到网盘了，欢迎下载！

点击👆卡片，关注后回复【面试题】即可获取

在看点这里好文分享给更多人↓↓