iOS之卡顿检测

很多iOS 开发，开发过程中都会面临到解决App卡顿问题，从而也衍生出很多的方法去解决卡顿，这篇文章来描述下iOS卡顿产生的原因，以及如何进行iOS卡顿检测分析。

iOS卡顿原理

像素是如何显示到屏幕上？

从最初的电子枪显示器说起，电子枪逐行读取像素点，逐行发射到屏幕上，每当一行扫描完成，显示器会发出水平同步信号HSync;然后继续下一行，直到最后一行完成一帧的绘制，电子枪恢复到起点继续下一帧的绘制，显示器会发出一个垂直同步信号VSync。对于iOS设备，VSync信号的间隔是16.7ms，也就是1秒60帧。

实际绘制过程中:

1.由CPU 计算好显示的内容：如视图的创建，布局的计算，图片的解码，文本的绘制，

2.然后GPU完成渲染，得到最终的像素，像素会输出到帧缓存(Frame Buffer)中

3.Video Controller (视频控制器)发出垂直信号(每16.67ms读取一次)进行读取Frame Buffer

4.最终输出到Monitor(显示器)上面。

假设只有一个Frame Buffer，意味着GPU和CPU必须在VSync发出的瞬间完成前面所有的工作，否则在视频控制器显示的过程中修改Frame Buffer，那么显示器就会在这一帧的前半部分显示上一帧的内容，下半部分显示当前帧的内容，造成画面断层的怪异现象。为了解决这个问题，大多数平台都引入了多缓存机制，比如iOS平台的双缓存, Android平台的三缓存机制；

因为苹果使用双缓冲区，根据上图，当垂直信号过来之后，但是GPU还没有渲染完成，就会出现掉帧(卡顿)显现。

iOS卡顿检测分析

市面上的iOS卡顿分析方案有三种：监控FPS、监控RunLoop、ping主线程。

方案一：监控FPS

一般来说，我们约定60FPS即为流畅。那么反过来，如果App在运行期间出现了掉帧，即可认为出现了卡顿。

监控FPS的方案几乎都是基于CADisplayLink实现的。简单介绍一下CADisplayLink：CADisplayLink是一个和屏幕刷新率保持一致的定时器，一但 CADisplayLink 以特定的模式注册到runloop之后，每当屏幕需要刷新的时候，runloop就会调用CADisplayLink绑定的target上的selector。
可以通过向RunLoop中添加CADisplayLink，根据其回调来计算出当前画面的帧数。

//
//  FPSMonitor.m
//  DemoTest2022
//
//  Created by wangyun on 2022/6/21.
//
 
#import "FPSMonitor.h"
#import "UIKit/UIKit.h"
@interface FPSMonitor()
@property(nonatomic,strong) CADisplayLink *link;
@property(nonatomic,assign) NSInteger count;
@property(nonatomic,assign) NSTimeInterval lastTime;
@end
 
@implementation FPSMonitor
-(void)beginMonitor{
    _link = [CADisplayLink displayLinkWithTarget:self selector:@selector(fpsInfoCaculate:)];
    [_link addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
    
}
-(void)fpsInfoCaculate:(CADisplayLink *)sender{
    if (_lastTime==0) {
        _lastTime = sender.timestamp;
    }
    _count ++;
    double deltaTime = sender.timestamp - _lastTime;
    if (deltaTime >= 1) {
        NSInteger FPS = _count/deltaTime;
        _lastTime = sender.timestamp;
        _count = 0;
        NSLog(@"FPS:%li",(NSInteger)ceil(FPS+0.5));
    }
}
@end

 FPS的好处就是直观，小手一划后FPS下降了，说明页面的某处有性能问题。坏处就是只知道这是页面的某处，不能准确定位到具体的堆栈。

如tableview快速滑动FPS会降低，说明有性能损耗比较大。

方案二：监控RunLoop

首先来介绍下什么是RunLoop。RunLoop是维护其内部事件循环的一个对象，它在程序运行过程中重复的做着一些事情，例如接收消息、处理消息、休眠等等。

所谓的事件循环，就是对事件/消息进行管理，没有消息时，休眠线程以避免资源消耗，从用户态切换到内核态。

有事件/消息需要进行处理时，立即唤醒线程，回到用户态进行处理。

#import <UIKit/UIKit.h>
#import "AppDelegate.h"
 
int main(int argc, char * argv[]) {
    NSString * appDelegateClassName;
    @autoreleasepool {
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
    }
    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}

UIApplicationMain函数内部会启动主线程的RunLoop，使得iOS程序持续运行。

iOS系统中有两套API来使用RunLoop，NSRunLoop（CFRunLoopRef的封装）和CFRunLoopRef。Foundation框架是不开源的，可以通过开源的CoreFoundation来分析RunLoop内部实现。

RunLoop对象底层就是一个CFRunLoopRef结构体，内部数据如下：

struct __CFRunLoop {
    pthread_t _pthread;               // 与RunLoop一一对应的线程
    CFMutableSetRef _commonModes;     // 存储着NSString（mode名称）的集合
    CFMutableSetRef _commonModeItems; // 存储着被标记为commonMode的Source0/Source1/Timer/Observer
    CFRunLoopModeRef _currentMode;    // RunLoop当前的运行模式
    CFMutableSetRef _modes;           // 存储着RunLoop所有的 Mode（CFRunLoopModeRef）模式
        // 其他属性略 
};

struct __CFRunLoopMode {
    CFStringRef _name;            // mode 类型，如：NSDefaultRunLoopMode
    CFMutableSetRef _sources0;    // 事件源 sources0
    CFMutableSetRef _sources1;    // 事件源 sources1
    CFMutableArrayRef _observers; // 观察者
    CFMutableArrayRef _timers;    // 定时器
        // 其他属性略
};

Source0被添加到RunLoop上时并不会主动唤醒线程，需要手动去唤醒。Source0负责对触摸事件的处理以及performSeletor:onThread:。

Source1具备唤醒线程的能力，使用的是基于Port的线程间通信。Source1负责捕获系统事件，并将事件交由Source0处理。

struct __CFRunLoopSource {
    CFRuntimeBase _base;
    uint32_t _bits;
    pthread_mutex_t _lock;
    CFIndex _order;         /* immutable */
    CFMutableBagRef _runLoops;
    union {
                CFRunLoopSourceContext version0;      // 表示 sources0
        CFRunLoopSourceContext1 version1;     // 表示 sources1
    } _context;
};

简单过一下RunLoop的源码。

void CFRunLoopRun(void) {   /* DOES CALLOUT */
    int32_t result;
    do {
        result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
        CHECK_FOR_FORK();
    } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
}

简单来看RunLoop是个 do..while循环，下面来看看循环中具体干了哪些事情。

SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) {     /* DOES CALLOUT */
    CHECK_FOR_FORK();
    if (__CFRunLoopIsDeallocating(rl)) return kCFRunLoopRunFinished;
    __CFRunLoopLock(rl);
    //根据modeName来查找本次运行的mode
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(rl, modeName, false);
    // 如果没找到mode 或者 mode里没有任何的事件，就此停止，不再循环
    if (NULL == currentMode || __CFRunLoopModeIsEmpty(rl, currentMode, rl->_currentMode)) {
             Boolean did = false;
             if (currentMode) __CFRunLoopModeUnlock(currentMode);
             __CFRunLoopUnlock(rl);
             return did ? kCFRunLoopRunHandledSource : kCFRunLoopRunFinished;
    }
    CFRunLoopModeRef previousMode = rl->_currentMode;
    rl->_currentMode = currentMode;
    int32_t result = kCFRunLoopRunFinished;
    // 通知 observers 即将进入RunLoop
    if (currentMode->_observerMask & kCFRunLoopEntry ) __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);
  // RunLoop具体要做的事情
    result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);
  // 通知 observers 即将退出RunLoop
    if (currentMode->_observerMask & kCFRunLoopExit ) __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
 
        __CFRunLoopModeUnlock(currentMode);
        __CFRunLoopPopPerRunData(rl, previousPerRun);
    rl->_currentMode = previousMode;
    __CFRunLoopUnlock(rl);
    return result;
}

整体流程如下图所示。

事件循环机制

根据这张图可以看出：RunLoop在BeforeSources和AfterWaiting后会进行任务的处理。可以在此时阻塞监控线程并设置超时时间，若超时后RunLoop的状态仍为RunLoop在BeforeSources或AfterWaiting，表明此时RunLoop仍然在处理任务，主线程发生了卡顿。

- (void)beginMonitor {
    self.dispatchSemaphore = dispatch_semaphore_create(0);
    // 第一个监控，监控是否处于 运行状态
    CFRunLoopObserverContext context = {0, (__bridge void *) self, NULL, NULL, NULL};
    self.runLoopBeginObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                                        kCFRunLoopAllActivities,
                                                        YES,
                                                        LONG_MIN,
                                                        &myRunLoopBeginCallback,
                                                        &context);
    //  第二个监控，监控是否处于 睡眠状态
    self.runLoopEndObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                                      kCFRunLoopAllActivities,
                                                      YES,
                                                      LONG_MAX,
                                                      &myRunLoopEndCallback,
                                                      &context);
    CFRunLoopAddObserver(CFRunLoopGetMain(), self.runLoopBeginObserver, kCFRunLoopCommonModes);
    CFRunLoopAddObserver(CFRunLoopGetMain(), self.runLoopEndObserver, kCFRunLoopCommonModes);
    
    // 创建子线程监控
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        //子线程开启一个持续的loop用来进行监控
        while (YES) {
            long semaphoreWait = dispatch_semaphore_wait(self.dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 17 * NSEC_PER_MSEC));
            if (semaphoreWait != 0) {
                if (!self.runLoopBeginObserver || !self.runLoopEndObserver) {
                    self.timeoutCount = 0;
                    self.dispatchSemaphore = 0;
                    self.runLoopBeginActivity = 0;
                    self.runLoopEndActivity = 0;
                    return;
                }
                // 两个runloop的状态，BeforeSources和AfterWaiting这两个状态区间时间能够检测到是否卡顿
                if ((self.runLoopBeginActivity == kCFRunLoopBeforeSources || self.runLoopBeginActivity == kCFRunLoopAfterWaiting) ||
                    (self.runLoopEndActivity == kCFRunLoopBeforeSources || self.runLoopEndActivity == kCFRunLoopAfterWaiting)) {
                    // 出现三次出结果
                    if (++self.timeoutCount < 2) {
                        continue;
                    }
                    NSLog(@"调试：监测到卡顿");
                } // end activity
            }// end semaphore wait
            self.timeoutCount = 0;
        }// end while
    });
}
 
// 第一个监控，监控是否处于 运行状态
void myRunLoopBeginCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
    RunLoopMonitor2* lagMonitor = (__bridge RunLoopMonitor2 *)info;
    lagMonitor.runLoopBeginActivity = activity;
    dispatch_semaphore_t semaphore = lagMonitor.dispatchSemaphore;
    dispatch_semaphore_signal(semaphore);
}
 
//  第二个监控，监控是否处于 睡眠状态
void myRunLoopEndCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
    RunLoopMonitor2* lagMonitor = (__bridge RunLoopMonitor2 *)info;
    lagMonitor.runLoopEndActivity = activity;
    dispatch_semaphore_t semaphore = lagMonitor.dispatchSemaphore;
    dispatch_semaphore_signal(semaphore);
}

运行效果，当卡顿发生是能够定位到并打印提示。

方案三：Ping主线程

Ping主线程的核心思想是向主线程发送一个信号，一定时间内收到了主线程的回复，即表示当前主线程流畅运行。没有收到主线程的回复，即表示当前主线程在做耗时运算，发生了卡顿。