原文链接

不管是应用秒变幻灯片，还是启动过久被杀，基本都是开发者必经的体验。就像没人希望堵车一样，卡顿永远是不受用户欢迎的，所以如何发现卡顿是开发者需要直面的难题。虽然导致卡顿的原因有很多，但卡顿的表现总是大同小异。如果把卡顿当做病症看待，两者分别对应所谓的本与标。要检测卡顿，无论是标或本都可以下手，但都需要深入的学习

instruments与性能

在开发阶段，使用内置的性能工具instruments来检测性能问题是最佳的选择。与应用运行性能关联最紧密的两个硬件CPU和GPU，前者用于执行程序指令，针对代码的处理逻辑；后者用于大量计算，针对图像信息的渲染。正常情况下，CPU会周期性的提交要渲染的图像信息给GPU处理，保证视图的更新。一旦其中之一响应不过来，就会表现为卡顿。因此多数情况下用到的工具是检测GPU负载的Core Animation，以及检测CPU处理效率的Time Profiler

由于CPU提交图像信息是在主线程执行的，会影响到CPU性能的诱因包括以下：

1. 发生在主线程的I/O任务
2. 过多的线程抢占CPU资源
3. 温度过高导致的CPU降频

而影响GPU的因素较为客观，难以针对做代码上的优化，包括：

1. 显存频率
2. 渲染算法
3. 大计算量

本文旨在介绍如何去检测卡顿，而非如何解决卡顿，因此如果对上面列出的诱因有兴趣的读者可以自行阅读相关文章书籍

卡顿检测

检测的方案根据线程是否相关分为两大类：

• 执行耗时任务会导致CPU短时间无法响应其他任务，检测任务耗时来判断是否可能导致卡顿
• 由于卡顿直接表现为操作无响应，界面动画迟缓，检测主线程是否能响应任务来判断是否卡顿

与主线程相关的检测方案包括：

1. fps
2. ping
3. runloop

与主线程不相关的检测包括：

1. stack backtrace
2. msgSend observe

衡量指标

不同方案的检测原理和实现机制都不同，为了更好的选择所需的方案，需要建立一套衡量指标来对方案进行对比，个人总结的衡量指标包括四项：

• 卡顿反馈

  卡顿发生时，检测方案是否能及时、直观的反馈出本次卡顿

• 采集精度

  卡顿发生时，检测方案能否采集到充足的信息来做定位追溯

• 性能损耗

  维持检测所需的CPU占用、内存使用是否会引入额外的问题

• 实现成本

  检测方案是否易于实现，代码的维护成本与稳定性等

fps

通常情况下，屏幕会保持60hz/s的刷新速度，每次刷新时会发出一个屏幕刷新信号，CADisplayLink允许我们注册一个与刷新信号同步的回调处理。可以通过屏幕刷新机制来展示fps值：

- (void)startFpsMonitoring {
    WeakProxy *proxy = [WeakProxy proxyWithClient: self];
    self.fpsDisplay = [CADisplayLink displayLinkWithTarget: proxy selector: @selector(displayFps:)];
    [self.fpsDisplay addToRunLoop: [NSRunLoop mainRunLoop] forMode: NSRunLoopCommonModes];
}

- (void)displayFps: (CADisplayLink *)fpsDisplay {
    _count++;
    CFAbsoluteTime threshold = CFAbsoluteTimeGetCurrent() - _lastUpadateTime;
    if (threshold >= 1.0) {
        [FPSDisplayer updateFps: (_count / threshold)];
        _lastUpadateTime = CFAbsoluteTimeGetCurrent();
    }
}

ping

ping是一种常用的网络测试工具，用来测试数据包是否能到达ip地址。在卡顿发生的时候，主线程会出现短时间内无响应这一表现，基于ping的思路从子线程尝试通信主线程来获取主线程的卡顿延时：

@interface PingThread : NSThread
......
@end

@implementation PingThread

- (void)main {
    [self pingMainThread];
}

- (void)pingMainThread {
    while (!self.cancelled) {
        @autoreleasepool {
            dispatch_async(dispatch_get_main_queue(), ^{
                [_lock unlock];
            });
            
            CFAbsoluteTime pingTime = CFAbsoluteTimeGetCurrent();
            NSArray *callSymbols = [StackBacktrace backtraceMainThread];
            [_lock lock];
            if (CFAbsoluteTimeGetCurrent() - pingTime >= _threshold) {
                ......
            }
            [NSThread sleepForTimeInterval: _interval];
        }
    }
}

@end

runloop

作为和主线程相关的最后一个方案，基于runloop的检测和fps的方案非常相似，都需要依赖于主线程的runloop。由于runloop会调起同步屏幕刷新的callback，如果loop的间隔大于16.67ms，fps自然达不到60hz。而在一个loop当中存在多个阶段，可以监控每一个阶段停留了多长时间：

- (void)startRunLoopMonitoring {
    CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
        if (CFAbsoluteTimeGetCurrent() - _lastActivityTime >= _threshold) {
            ......
            _lastActivityTime = CFAbsoluteTimeGetCurrent();
        }
    });
    CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
}

stack backtrace

代码质量不够好的方法可能会在一段时间内持续占用CPU的资源，换句话说在一段时间内，调用栈总是停留在执行某个地址指令的状态。由于函数调用会发生入栈行为，如果比对两次调用栈的符号信息，前者是后者的符号子集时，可以认为出现了卡顿恶鬼：

@interface StackBacktrace : NSThread
......
@end

@implementation StackBacktrace

- (void)main {
    [self backtraceStack];
}

- (void)backtraceStack {
    while (!self.cancelled) {
        @autoreleasepool {
            NSSet *curSymbols = [NSSet setWithArray: [StackBacktrace backtraceMainThread]];
            if ([_saveSymbols isSubsetOfSet: curSymbols]) {
                ......
            }
            _saveSymbols = curSymbols;
            [NSThread sleepForTimeInterval: _interval];
        }
    }
}

@end

msgSend observe

OC方法的调用最终转换成msgSend的调用执行，通过在函数前后插入自定义的函数调用，维护一个函数栈结构可以获取每一个OC方法的调用耗时，以此进行性能分析与优化：

#define save() \
__asm volatile ( \
    "stp x8, x9, [sp, #-16]!\n" \
    "stp x6, x7, [sp, #-16]!\n" \
    "stp x4, x5, [sp, #-16]!\n" \
    "stp x2, x3, [sp, #-16]!\n" \
    "stp x0, x1, [sp, #-16]!\n");

#define resume() \
__asm volatile ( \
    "ldp x0, x1, [sp], #16\n" \
    "ldp x2, x3, [sp], #16\n" \
    "ldp x4, x5, [sp], #16\n" \
    "ldp x6, x7, [sp], #16\n" \
    "ldp x8, x9, [sp], #16\n" );
    
#define call(b, value) \
    __asm volatile ("stp x8, x9, [sp, #-16]!\n"); \
    __asm volatile ("mov x12, %0\n" :: "r"(value)); \
    __asm volatile ("ldp x8, x9, [sp], #16\n"); \
    __asm volatile (#b " x12\n");


__attribute__((__naked__)) static void hook_Objc_msgSend() {

    save()
    __asm volatile ("mov x2, lr\n");
    __asm volatile ("mov x3, x4\n");
    
    call(blr, &push_msgSend)
    resume()
    call(blr, orig_objc_msgSend)
    
    save()
    call(blr, &pop_msgSend)
    
    __asm volatile ("mov lr, x0\n");
    resume()
    __asm volatile ("ret\n");
}

总结