原文链接：如何利用 RunLoop 原理去监控卡顿？
前言
一个App想要提升用户体验最重要的就是 降低程序崩溃 和 提升程序流畅度。前者在上一篇 崩溃监控 中稍有介绍，而今天要看的就是如何监控程序的卡顿，从而有目的性的优化程序流畅度，提升用户体验。
虽然达到程序60FPS稳定运行是我们的终极目标，但是原文中戴铭老师直接否定了通过 监控FPS 来判断程序是否卡顿的方案，进而提出使用 监控主线程RunLoop的状态 来判断是否卡顿的方法。
RunLoop监控卡顿原理
1 卡顿情况
- 复杂 UI、图文混排的绘制量过大
- 在主线程上做网络同步请求
- 在主线程做大量 IO 操作
- 运算量过大，CPU持续高占用
- 死锁或主子线程间抢锁
2 RunLoop基础概念
简单来说，RunLoop 的工作模式就是，当有事件要处理时保持线程忙，当没有事件要处理时让线程进入休眠。
2.1 相关的类：
CFRunLoopRef
CFRunLoopModeRef
CFRunLoopSourceRef
CFRunLoopTimerRef
CFRunLoopObserverRef
2.2 Mode:
一个RunLoop包含若干个Mode，每个Mode又包含若干个Source/Timer/Observer。
系统默认注册了5个Mode。每次调用RunLoop的主函数时，只能指定其中一个Mode，也就是说RunLoop中的Mode在不断切换。
kCFRunLoopDefaultMode //App的默认Mode，通常主线程是在这个Mode下运行
UITrackingRunLoopMode //界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响
UIInitializationRunLoopMode // 在刚启动 App 时第进入的第一个 Mode，启动完成后就不再使用
GSEventReceiveRunLoopMode // 接受系统事件的内部 Mode，通常用不到
kCFRunLoopCommonModes //这是一个占位用的Mode，不是一种真正的Mode
2.3 工作过程：
工作过程大致总结为上图的10个步骤：
1 通知Observers，RunLoop要开始进入loop了
2-3 进入loop，开启一个 do while 保活线程。通知Observers，将要处理Timer回调和Source0回调，接着执行block
// 通知 Observers RunLoop 会触发 Timer 回调
if (currentMode->_observerMask & kCFRunLoopBeforeTimers)
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
// 通知 Observers RunLoop 会触发 Source0 回调
if (currentMode->_observerMask & kCFRunLoopBeforeSources)
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
// 执行 block
__CFRunLoopDoBlocks(runloop, currentMode);
4-5 处理Source0回调，如果这里有Source1是ready状态，就会跳转handle_msg去处理消息
if (MACH_PORT_NULL != dispatchPort ) {
Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
if (hasMsg) goto handle_msg;
}
6 回调触发后，通知Observers，该线程即将进入休眠
7-8 进入休眠后，如果出现下面四个事件时RunLoop会通知Observers，线程被唤醒了
- 基于 port 的 Source 事件
- Timer 时间到
- RunLoop 超时
- 被调用者唤醒
9 RunLoop 被唤醒后就重新开始处理消息，重复2-3的过程
10 当被外部强制停止或loop超时，就不继续下一个loop了，此时通知Observers，即将退出loop
if (sourceHandledThisLoop && stopAfterHandle) {
// 事件已处理完
retVal = kCFRunLoopRunHandledSource;
} else if (timeout) {
// 超时
retVal = kCFRunLoopRunTimedOut;
} else if (__CFRunLoopIsStopped(runloop)) {
// 外部调用者强制停止
retVal = kCFRunLoopRunStopped;
} else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
// mode 为空，RunLoop 结束
retVal = kCFRunLoopRunFinished;
}
2.4 Observer，loop的六个状态
观察者，可以监听RunLoop的状态改变
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 进入 loop
kCFRunLoopBeforeTimers = (1UL << 1), //即将处理 Timer
kCFRunLoopBeforeSources = (1UL << 2), //即将处理 Sources0
kCFRunLoopBeforeWaiting = (1UL << 5), //即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6), //刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7), // 退出 loop
kCFRunLoopAllActivities = 0x0FFFFFFFU //所有状态改变
};
3 RunLoop，通过Observer监控卡顿
我们通过RunLoop的工作流程可以知道，如果在 loop进入睡眠前执行方法时间过长（过程2-5） 或者 线程唤醒时接收消息时间过长（过程8）而无法处理下一个事件，我们就可以认为线程受阻而出现了卡顿。
上面两种情况，我们可以通过监听RunLoop的 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 这两个状态所停留的时长来判断。
如何检查卡顿
这里我们从老师分享的源码 截取关键部分 进行分析和学习。
#import "SMLagMonitor.h"
#import "SMCallStack.h"
#import "SMCPUMonitor.h"
@interface SMLagMonitor() {
int timeoutCount;
CFRunLoopObserverRef runLoopObserver;
@public
dispatch_semaphore_t dispatchSemaphore;
CFRunLoopActivity runLoopActivity;
}
@end
@implementation SMLagMonitor
#pragma mark - Interface
+ (instancetype)shareInstance {
static id instance = nil;
static dispatch_once_t dispatchOnce;
dispatch_once(&dispatchOnce, ^{
instance = [[self alloc] init];
});
return instance;
}
- (void)beginMonitor {
//监测卡顿
if (runLoopObserver) {
return;
}
dispatchSemaphore = dispatch_semaphore_create(0); //Dispatch Semaphore保证同步
//创建一个观察者
CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,
kCFRunLoopAllActivities,
YES,
0,
&runLoopObserverCallBack,
&context);
//将观察者添加到主线程runloop的common模式下的观察中
CFRunLoopAddObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);
//创建子线程监控
dispatch_async(dispatch_get_global_queue(0, 0), ^{
//子线程开启一个持续的loop用来进行监控
while (YES) {
long semaphoreWait = dispatch_semaphore_wait(dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 3*NSEC_PER_MSEC));
if (semaphoreWait != 0) {
if (!runLoopObserver) {
timeoutCount = 0;
dispatchSemaphore = 0;
runLoopActivity = 0;
return;
}
//两个runloop的状态，BeforeSources和AfterWaiting这两个状态区间时间能够检测到是否卡顿
if (runLoopActivity == kCFRunLoopBeforeSources || runLoopActivity == kCFRunLoopAfterWaiting) {
// 出现异常情况
NSLog(@"monitor trigger");
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
// 异步提交/上传错误的堆栈信息
});
} //end activity
}// end semaphore wait
timeoutCount = 0;
}// end while
});
}
- (void)endMonitor {
if (!runLoopObserver) {
return;
}
CFRunLoopRemoveObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);
CFRelease(runLoopObserver);
runLoopObserver = NULL;
}
#pragma mark - Private
static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info){
SMLagMonitor *lagMonitor = (__bridge SMLagMonitor*)info;
lagMonitor->runLoopActivity = activity;
dispatch_semaphore_t semaphore = lagMonitor->dispatchSemaphore;
dispatch_semaphore_signal(semaphore);
}
@end
思路总结
通过 RunLoop 的 Observer 监控 主线程 中各个状态的变化。如果 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 这两个状态所停留的时间过长，我们便认定为发生了一次主线程卡顿。
具体做法
1 我们需要创建一个 CFRunLoopObserverContext 观察者，且创建一个 Observer，并监控主线程状态的变化
CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,kCFRunLoopAllActivities,YES,0,&runLoopObserverCallBack,&context);
//将观察者添加到主线程runloop的common模式下的观察中
CFRunLoopAddObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);
这个Observer会监听 kCFRunLoopAllActivities（所有状态改变），并在状态改变时执行 runLoopObserverCallBack 中的代码。
static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info){
SMLagMonitor *lagMonitor = (__bridge SMLagMonitor*)info;
lagMonitor->runLoopActivity = activity;
dispatch_semaphore_t semaphore = lagMonitor->dispatchSemaphore;
dispatch_semaphore_signal(semaphore);
}
这个闭包中执行了4行代码：
1.1 通过 info 属性，拿到当前类
1.2 记录当前 Observers 的状态，并赋值给成员变量 runLoopActivity
1.3 使用信号量 dispatch_semaphore_t 监控 Observers 状态间停留的时长。这里获取当前类声明的 dispatch_semaphore_t 信号量属性
1.4 激活信号量，通过 dispatch_semaphore_signal() 方法使正在等待的信号量继续执行
对应之前创建 dispatch_semaphore_t 对象的的代码是：
dispatchSemaphore = dispatch_semaphore_create(0); //Dispatch Semaphore保证同步
2 创建一个子线程，使用while循环保活，并通过信号量阻塞该线程
long semaphoreWait = dispatch_semaphore_wait(dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 3*NSEC_PER_MSEC));
if (semaphoreWait != 0) {
// Returns zero on success, or non-zero if the timeout occurred.
}
dispatch_semaphore_wait 这个方法会阻塞当前线程一段时间，如果 在阻塞时间内收到激活信号 或者 阻塞时间超时，代码会继续执行，如果超时，该方法的返回值为 非0
对应前面的闭包中的代码，如果各状态切换没有发生阻塞，那么会及时发出信号量的激活信号，此时 dispatch_semaphore_wait 方法的返回值为0，不视为卡顿。反之各状态耗时过长，没有及时发出信号，dispatch_semaphore_wait 方法的返回值为非0，就视为发生卡顿。
3 触发卡顿的时间阈值
我们根据 WatchDog 机制来设置。
- 启动 20s
- 恢复 10s
- 挂起 10s
- 退出 6s
- 后台 3min（iOS7之前每次申请10min，之后改为3min，可以连续申请，最多申请到10min）
总的原则就是，要小于 WatchDog 的限制时间，3s仅做参考值。
4 获取卡顿的方法堆栈信息
监控到卡顿发生后，自然要解决问题，那么如何获取卡顿的堆栈信息呢？
原文中推荐的是直接用 plcrashreporter 能够定位到问题代码的具体位置，而且性能消耗也不大。
具体使用的代码：
// 获取数据
NSData *lagData = [[[PLCrashReporter alloc] initWithConfiguration:[[PLCrashReporterConfig alloc] initWithSignalHandlerType:PLCrashReporterSignalHandlerTypeBSD symbolicationStrategy:PLCrashReporterSymbolicationStrategyAll]] generateLiveReport];
// 转换成 PLCrashReport 对象
PLCrashReport *lagReport = [[PLCrashReport alloc] initWithData:lagData error:NULL];
// 进行字符串格式化处理
NSString *lagReportString = [PLCrashReportTextFormatter stringValueForCrashReport:lagReport withTextFormat:PLCrashReportTextFormatiOS];
// 将字符串上传服务器
NSLog(@"lag happen, detail below: \n %@",lagReportString);
最后
现在，我们可以监控卡顿，并且获取发生卡顿的方法信息了。
这里涉及的知识主要包括了 RunLoop 和 信号量（线程锁知识）。当然也只是皮毛，更多是需要我们自己去实战和应用。
比起事后排查和改进，我们更应该养成良好且正确的代码习惯，通常情况下，设备的性能都足以支撑正确程序的流畅运行。
说回提升用户体验的话题，我觉得更重要的是从产品角度和产品交互出发，卡顿监控只是一项必做的基本功课。好的产品交互才是提升用户体验的重头戏。