Objective-C 之利用RunLoop监测卡顿

2019-05-24 本文已影响53人我唔知啊

最近学习戴铭大神的课程，其中一篇文章介绍了如何利用RunLoop监测卡顿，在此做个记录。

一、监测卡顿的原理

文中介绍到：

RunLoop是用来监听输入源，进行调度处理的。如果RunLoop的线程进入睡眠前方法的执行时间过长而导致无法进入睡眠，或者线程唤醒后接收消息时间过长而无法进入下一步，就可以认为是线程受阻了。如果这个线程是主线程的话，表现出来的就是出现了卡顿。

RunLoop有以下几种状态：

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry , // 即将进入 loop，值是2^0
    kCFRunLoopBeforeTimers , // 即将处理 Timer ，值是2^1
    kCFRunLoopBeforeSources , // 即将处理 Source0 ，值是2^2
    kCFRunLoopBeforeWaiting , // 即将进入睡眠，等待 mach_port 消息，值是2^5
    kCFRunLoopAfterWaiting , // 即将处理 mach_port 消息，值是2^6
    kCFRunLoopExit , // 即将退出 loop，值是2^7
    kCFRunLoopAllActivities  // loop 所有状态改变。通过监测该值的变化，就知道runLoop的状态发生了变化
}

而文中提到的2种线程受阻情况，它们的状态分别是：kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting。

二、思路

根据原理，可以得到一个监测卡顿的思路：

监测主线程RunLoop的状态，如果状态在一定时长内都是kCFRunLoopBeforeSources或者kCFRunLoopAfterWaiting，则认为卡顿。

步骤如下：

创建一个RunLoop的观察者（CFRunLoopObserverRef）
把观察者加入主线程的kCFRunLoopCommonModes模式中，以监测主线程
创建一个子线程来维护观察者
根据主线程RunLoop的状态来判断是否卡顿

三、实现方法

1. 实现代码

// 在AppDelaget.m文件添加几个属性
@interface AppDelegate ()
{
    int timeoutCount;
    CFRunLoopObserverRef runLoopObserver;
@public
    dispatch_semaphore_t dispatchSemaphore;
    CFRunLoopActivity runLoopActivity;
}
@end

@implementation AppDelegate

// 开始监测
- (void)beginMonitor {

    if (runLoopObserver) {
        return;
    }
    
    // dispatchSemaphore的知识参考：https://www.jianshu.com/p/24ffa819379c
    // 初始化信号量，值为0
    dispatchSemaphore = dispatch_semaphore_create(0); //Dispatch Semaphore保证同步
    
    // 创建一个观察者
    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                              kCFRunLoopAllActivities,
                                              YES,
                                              0,
                                              &runLoopObserverCallBack,
                                              &context);
    // 将观察者添加到主线程runloop的commonModes中
    CFRunLoopAddObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);
    
    // 创建子线程监控
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        // 子线程开启一个持续的loop用来进行监控
        while (1) {
            // 等待信号量：如果信号量是0，则阻塞当前线程；如果信号量大于0，则此函数会把信号量-1，继续执行线程。此处超时时间设为20毫秒。
            // 返回值：如果线程是唤醒的，则返回非0，否则返回0
            long semaphoreWait = dispatch_semaphore_wait(self->dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 20*NSEC_PER_MSEC));
//            NSLog(@"%@",@(semaphoreWait));
            if (semaphoreWait != 0) {
                if (!self->runLoopObserver) {// observer创建失败，直接返回
                    self->timeoutCount = 0;
                    self->dispatchSemaphore = 0;
                    self->runLoopActivity = 0;
                    return;
                }
                
                // 如果RunLoop执行任务的时间过长(kCFRunLoopBeforeSources)，或者线程唤醒后接收消息时间过长(kCFRunLoopAfterWaiting)，则认为线程受阻。
                if (self->runLoopActivity == kCFRunLoopBeforeSources || self->runLoopActivity == kCFRunLoopAfterWaiting) {
                    NSLog(@"runloop状态：%@",@(self->runLoopActivity));
                    // 60毫秒内一直保持其中一种状态，说明卡顿（20毫秒测1次，共3次）
                    if (++self->timeoutCount < 3) {
                        continue;
                    }
                    NSLog(@"发生卡顿...");
                }
            }
            self->timeoutCount = 0;
        }
    });
    
}

static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
//    NSLog(@"监测到线程主线程有变化，信号量+1");
    AppDelegate *delegate = (__bridge AppDelegate*)info;
    delegate->runLoopActivity = activity;
    
    dispatch_semaphore_t semaphore = delegate->dispatchSemaphore;
    // 让信号量+1
    dispatch_semaphore_signal(semaphore);
}

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // 开始监测
    [self beginMonitor];
    
    return YES;
}

@end

监测到卡顿后，使用PLCrashRepoter获取堆栈信息，根据这些信息找到造成卡顿的方法。

#import <CrashReporter/CrashReporter.h>

// 获取数据
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);

2. 流程说明：

为了保证子线程的同步监测，刚开始创建一个信号量是0的dispatch_semaphore。当监测到主线程的RunLoop的状态发生变化，触发回调：

static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {

在回调里面发送信号，使信号量+1，值变为1：

dispatch_semaphore_signal(semaphore)

当dispatch_semaphore_wait接收到信号量不为0，会返回一个不为0的值（semaphoreWait），并把信号量减1：

long semaphoreWait = dispatch_semaphore_wait(self->dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 20*NSEC_PER_MSEC));

然后触发一次监测功能，记录RunLoop状态。此时信号量是0，继续等待下一个信号量。

反复监测后，如果状态连续3次都是kCFRunLoopBeforeSources或者kCFRunLoopAfterWaiting，则判定为卡顿。

3. 关于触发卡顿的时间阈值

代码中定义了卡顿阈值是3*20ms=60ms，在线下做测试的话，这个值是合理的。但是如果在线上使用这种监测卡顿的方法，大神建议把该值设为3秒，文中介绍如下：

其实，触发卡顿的时间阈值，我们可以根据 WatchDog 机制来设置。WatchDog 在不同状态下设置的不同时间，如下所示：

启动（Launch）：20s；
恢复（Resume）：10s；
挂起（Suspend）：10s；
退出（Quit）：6s；
后台（Background）：3min（在 iOS 7 之前，每次申请 10min；之后改为每次申请 3min，可连续申请，最多申请到 10min）。

通过 WatchDog 设置的时间，我认为可以把启动的阈值设置为 10 秒，其他状态则都默认设置为 3 秒。总的原则就是，要小于 WatchDog 的限制时间。当然了，这个阈值也不用小得太多，原则就是要优先解决用户感知最明显的体验问题。

参考项目：https://github.com/ming1016/DecoupleDemo/blob/master/DecoupleDemo/SMLagMonitor.m

Objective-C 之利用RunLoop监测卡顿

一、监测卡顿的原理

二、思路

三、实现方法

1. 实现代码

2. 流程说明：

3. 关于触发卡顿的时间阈值

猜你喜欢

热点阅读

Objective-C 之 利用RunLoop监测卡顿

一、监测卡顿的原理

二、思路

三、实现方法

1. 实现代码

2. 流程说明：

3. 关于触发卡顿的时间阈值

猜你喜欢

热点阅读

Objective-C 之利用RunLoop监测卡顿