关于ios:iOS性能优化RunLoop卡顿检测

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

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

• 很简单的 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