APM - iOS 卡顿原理及监控方案

应用的流畅度是衡量应用用户体验和性能的一个重要指标，一个流畅的应用能够给用户带来良好的使用感受，提高用户的满意度和忠诚度。对于开发者来说应该重视并不断优化应用的流畅度，提升用户的使用体验。本篇文章主要介绍一下如何监控卡顿，以及一些常用的优化手段。

屏幕成像原理

屏幕成像最底层的原理要从 CRT 显示器（Cathode Ray Tube 阴极射线管）的原理来说，CRT 的电子枪发出电子束来激发屏幕内表面的荧光粉来显示图像的，由于荧光粉被点亮后会很快熄灭，所以电子枪必须循环地不断激发这些点。如上图所示，电子枪会从上到下一行一行的扫描，扫描完最后一行后显示器就呈现了一帧画面，随后电子枪会回到开始的位置继续下一帧的扫描。

同步信号

为了将显示器和系统的视频控制器进行同步，会通过硬件时钟产生一系列的定时信号，分别是：

• 水平同步信号（horizontal synchronization）

  当电子枪换到新的一行时，在扫描之前会发出一个水平同步信号，简称 HSync。

• 垂直同步信号（vertical syncchronization）

  当电子枪回到最初位置时，在扫描下一帧之前会发出一个垂直同步信号，简称 VSync。显示器通常是以固定的频率刷新的，这个刷新频率就是 VSync 信号产生的频率。

渲染流水线

如上图，计算机系统中 CPU、GPU、显示器按照上面这种方式协同工作的。

• CPU

  CPU 一般负责视图创建、销毁，布局计算、文本绘制、图片的解码等，最终将计算好的将要显示的内容提交给 GPU。

• GPU

  GPU将 CPU 计算好的内容进行合成、渲染，然后将渲染结果放再帧缓冲区（FrameBuffer）中。

• 视频控制器

  随后视频控制器会随着 VSync 信号的到来，逐行读取帧缓冲区的数据，经过数模转换后给显示器显示。

双缓冲机制

最初，帧缓冲区只有一个，此时帧缓冲去的读取和刷新都会有较大的效率问题。为了提升效率，在显示系统引入两个缓冲区，即双缓冲机制。

此时，GPU 会提前渲染好一帧放入一个缓冲区内，让视频控制器来读该缓冲区的数据。当下一帧渲染好后，GPU 会等待显示器的 VSync 信号的发出后，才会改变视频控制器的指针指向新的缓冲区。

卡顿的原因

CPU 与 GPU 的协同

正常情况下，iOS 系统默认刷新频率是 60Hz，即每秒会渲染 60 帧，每帧之间间隔 16.67 ms，这也是两个 VSync 信号的间隔。

当VSync 信号到来后，系统图形服务会通知当前应用，应用的主线程开始在CPU 中执行相关计算操作，然后 GPU 进行合成、渲染等一系列操作，最终 GPU 将渲染结果提交到帧缓冲区中，等待 VSync 信号到来时显示到屏幕上。

• 正常显示

  当 Vsync 信号到来时， CPU 与 GPU 在规定时间内将渲染结果提交到了帧缓冲区。

• 掉帧（卡顿）

  当 Vsync 信号到来时，CPU 或者 GPU 没有完成内容提交，则这一帧就会被丢弃了，等待下一次 VSync 再显示，而此时显示器上仍然保留着之前的内容不变，这就界面卡顿的原因。

因此，在做性能优化时，只要使 CPU 的计算和 GPU 的渲染能规定时间内完成，就能避免掉帧，从而解决卡顿问题。

具体原因

• CPU

  CPU 提交计算结果是在主线程执行的，会影响 CPU 性能的因素大概有：

  • 主线程大量 I/O操作：（未考虑性能，方便coding，直接在主线程写入大量数据）
  • 主线程大量耗时操作：如图片编解码、复杂布局等
  • 过多线程抢占 CPU 资源
  • 高温导致 CPU 降频

• GPU

  • 视图层级过多、离屏渲染
  • 大量计算以及渲染算法等等

卡顿监控

1.Xcode Instruments

在开发阶段，可直接使用内置工具 Instruments 来检测性能问题。一般使用使用 TimeProfiler 查看 CPU 相关的耗时操作，使用 Core Animation (FPS / Commits) 查看 GPU 的渲染以及提交情况。

2.主线程卡顿监控

了解了卡顿的原理，为了更好的解决卡顿问题，首先要定位到是哪些代码导致的卡顿，所以对于卡顿的监控是十分必要的。

FPS

一般情况，将 App 的 FPS 保持在 50~60 之间，用户就感觉不到卡顿。屏幕每次刷新时都会发出一个信号，通过向主线程添加 CADisplayLink 来注册一个与刷新频率相同的回调，从而统计出每秒屏幕刷新的次数。实现比较简单，可直接参考 YYFPSLabel 。

@implementation YYFPSLabel 

- (instancetype)initWithFrame:(CGRect)frame {
    // 省略...		
    // 创建CADisplayLink并添加到主线程的RunLoop中
    _link = [CADisplayLink displayLinkWithTarget:[YYWeakProxy proxyWithTarget:self] selector:@selector(tick:)];
    [_link addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
    return self;
}

//刷新回调时去计算fps
- (void)tick:(CADisplayLink *)link {
    if (_lastTime == 0) {
        _lastTime = link.timestamp;
        return;
    }
    
    _count++;
    NSTimeInterval delta = link.timestamp - _lastTime;
    if (delta < 1) return;
  	//每秒统计一次
    _lastTime = link.timestamp;
    float fps = _count / delta;
    _count = 0;
     
    self.text = [NSString stringWithFormat:@"%d FPS",(int)round(fps)];
}

@end

• 优点：

  直观，卡顿发生时，FPS 会明显下降，反馈及时, 适用于开发阶段及时发现问题。

• 缺点：

  需要 CPU 空闲时才能处理， 无法采集调用堆栈

RunLoop

首先通过下图，看一下 RunLoop 运行过程中的状态变化过程。

从上图我们发现，RunLoop 基本是在 BeforceSources 和 AfterWaiting 两个状态后执行任务，因此可以在子线程中定时检测主线程中的 RunLoop 是否处于 BeforceSources 或 AfterWaiting 状态，如果一定时间后仍处于这两个状态，则可认为主线程发生了卡顿。

源码：

//在主线程注册RunLoop观察者
- (void)registerMainRunLoopObserver {
    CFRunLoopObserverContext context = {0, (__bridge void*)self, NULL, NULL};
    self.runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                                   kCFRunLoopAllActivities,
                                                   YES,
                                                   0,
                                                   &runLoopObserverCallBack,
                                                   &context);
    CFRunLoopAddObserver(CFRunLoopGetMain(), self.runLoopObserver, kCFRunLoopCommonModes);
}

//RunLoop 回调方法
static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info)
{
    self.runLoopActivity = activity;
    //在主线程触发信号，使子线程不在阻塞
    if (self.semaphore != nil) {
        dispatch_semaphore_signal(self.semaphore);
    }
}

//创建一个子线程去监听主线程RunLoop状态
- (void)createRunLoopStatusMonitor {
    self.semaphore = dispatch_semaphore_create(0);
    if (self.semaphore == nil) {
        return;
    }
    
    //创建一个子线程，监测Runloop状态时长
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        while (YES){
            //如果观察者已经移除，则停止进行状态监测
            if (self.runLoopObserver == nil) {
                self.runLoopActivity = 0;
                self.semaphore = nil;
                return;
            }
            
            //信号量等待。状态不等于0，说明状态等待超时
        //方案一：设置单次超时时间为500毫秒
            long status = dispatch_semaphore_wait(self.semaphore, dispatch_time(DISPATCH_TIME_NOW, 500 * NSEC_PER_MSEC));
            if (status != 0) {
                if (self.runLoopActivity == kCFRunLoopBeforeSources || self.runLoopActivity == kCFRunLoopAfterWaiting) {
                    //发生超过500毫秒的卡顿，此时去记录调用栈信息
                }
            }
        /*
       //方案二：连续5次卡顿50ms上报
        long status = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC));
        if (status != 0)
        {
            if (!observer)
            {
                timeoutCount = 0;
                semaphore = 0;
                activity = 0;
                return;
            }
            
            if (activity==kCFRunLoopBeforeSources || activity==kCFRunLoopAfterWaiting)
            {
                if (++timeoutCount < 5)
                    continue;
                //保存调用栈信息
            }
        }
        timeoutCount = 0;
        */
        }
    });
}
 

• 优点：

  性能损耗较低，不会唤醒 RunLoop，优于 FPS；

  可及时捕获卡顿堆栈，可用于线上监控。

• 缺点：

  无法确定卡顿的时长，定义卡顿的阈值不好控制（根据业务人为设置）。

子线程 Ping 主线程

Ping 主线程核心思想是：在子线程内，与主线程通信使某个状态在主线程改变，判断改状态发生改变后的耗时，以此判断主线程是否发生了卡顿。

@implementation PingThread

- (void)main {
    self.semaphore = dispatch_semaphore_create(0);
    [self pingMainThread];
}

- (void)pingMainThread {
    while (!self.cancelled) {
        @autoreleasepool {
            dispatch_async(dispatch_get_main_queue(), ^{
                dispatch_semaphore_signal(self.semaphore);
            });
            
            CFAbsoluteTime pingTime = CFAbsoluteTimeGetCurrent();
            dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER);
            if (CFAbsoluteTimeGetCurrent() - pingTime >= _threshold) {
                ......
            }
            [NSThread sleepForTimeInterval: _interval];
        }
    }
}

@end

• 优点：

  可及时捕获卡顿堆栈；

  可以记录卡顿的时长；

• 缺点：

  一直 ping 主线程比较消耗硬件资源，费电；

3.全局监控

堆栈回溯

由于函数的调用会发生入栈行为，如果调用栈总是停留在某个地址指令的状态，说明该地址的函数比较耗时。可通过对比两次调用栈的符号信息，如果后一次仍然包含前一次的地址符号，可认为发生了卡顿。

@implementation StackBacktrace

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

- (void)backtraceStack {
    while (!self.cancelled) {
        @autoreleasepool {
            NSSet *curSymbols = //获取堆栈的符号集;
            if ([_saveSymbols isSubsetOfSet: curSymbols]) {
                //包含前一次的符号集，发生卡顿
            }
            _saveSymbols = curSymbols;
            [NSThread sleepForTimeInterval: _interval];
        }
    }
}

@end

• 优点：

  由于符号的唯一性，直接通过调用栈的符号信息对比，准确性较高。

• 缺点：

  需要频繁获取调用栈，对性能损耗高；

  实现难度相对较大，成本较高；

hook msgSend

主要是根据 OC 的消息机制，方法的调用最终转换成 msgSend 的调用，因此可通过 hook msgSend 方法，在函数的前后插入自定义的耗时监控函数，从而可统计每个函数的耗时。

• 优点：

  采集精度高，覆盖面广，能准确记录每一个方法的耗时；

• 缺点：

  整体性能损耗较高，统计了每个OC 函数；

  只适用 OC，不适用Swift 代码；

总结

本篇简要介绍了屏幕成像的原理，和发生卡顿的根本原因，并总结了 iOS 业界常见的一些卡顿监控的原理，具体选择哪种方法可根据自己项目选择最适合的即可。

参考

iOS 保持界面流畅的技巧
iOS界面卡顿原理及优化
Matrix 卡顿监控
RunLoop实战：实时卡顿监控
深入理解 RunLoop