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