关于线上检测主线程卡顿的问题

大家好,一年多没有更新文章了,最大的原因我想是不知道该分享些什么,这次是在一个巧合下发现网上经常被人讨论的APP在线上状态如何检测到主线程的卡顿情况,我也稍微了解了一下,前段时间就在一个博主的文章里看到一篇有部分讲解这个问题的,据说美团用的也是这种方案,具体不得而知,然后我发现网上关于这种问题的实现方案都十分类似,如果屏幕前的你还没有意识过这个问题,那就请听我往下分析这个网上常用的检测方案:

利用runloop的检测方案

关于runloop是什么我就不多说了,因为网上有很多关于这个的文章,最推荐的还是YYKit的作者博客上那篇。
我要拿出来注意的是 runloop 的状态:

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry         = (1UL << 0), // 即将进入Loop
    kCFRunLoopBeforeTimers  = (1UL << 1), // 即将处理 Timer
    kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
    kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
    kCFRunLoopAfterWaiting  = (1UL << 6), // 刚从休眠中唤醒
    kCFRunLoopExit          = (1UL << 7), // 即将退出Loop
};

网上热议的是利用 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 这两个状态之间的耗时进行判断是否有太多事件处理导致出现了卡顿,下面直接上代码:

static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info)
{
    PingConfig *object = (__bridge PingConfig*)info;
    
    // 记录状态值
    object->activity = activity;

    // 发送信号
    dispatch_semaphore_t semaphore = object->semaphore;
    dispatch_semaphore_signal(semaphore);
}

上面这些是监听runloop的状态而写的回调函数

- (void)registerObserver
{
    PingConfig *config = [PingConfig new];
    // 创建信号
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
    config->semaphore = semaphore;
    
    CFRunLoopObserverContext context = {0,(__bridge void*)config,NULL,NULL};
    CFRunLoopObserverRef observer = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                                            kCFRunLoopAllActivities,
                                                            YES,
                                                            0,
                                                            &runLoopObserverCallBack,
                                                            &context);
    CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
    
    __block uint8_t timeoutCount = 0;

    // 在子线程监控时长
    dispatch_async(dispatch_get_global_queue(0, 0), ^{

        
        while (YES)
        {
            // 假定连续5次超时50ms认为卡顿(当然也包含了单次超时250ms)
            long st = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC));

            if (st != 0)
            {

//                NSLog(@"循环中--%ld",config->activity);
                if (config->activity==kCFRunLoopBeforeSources || config->activity==kCFRunLoopAfterWaiting)
                {
                    if (++timeoutCount < 5){
                        continue;
                    }else{
                        NSLog(@"卡顿了");
                    }

                }
                
 
            }
            timeoutCount = 0;
        }
    });
}

现在我解读一下这段代码:

  1. PingConfig 只是我随便写的一个用来存储runloop的状态和信号量的自定义类,其中的结构如下:
@interface PingConfig : NSObject
{
    @public
    CFRunLoopActivity activity;
    dispatch_semaphore_t semaphore;
}
@end

恩,只有这么多足矣。

  1. APP启动时我可以进入 registerObserver 方法,其中首先我创建一个记录信息的类PingConfig实例,然后创建一个信号,并且保存在这个PingConfig实例中(其实只是为了方便拿到)。
  2. 接下来我创建了一个观察者监测主线程的 runloop,它会在主线程runloop状态切换时进行回调。
  3. 开启一个子线程,并且在里面进行一个 while 循环,在 循环的开始处 wait 一个信号量,并且设置超时为 50毫秒,失败后会返回一个非0数,成功将会返回0,这时候线程会阻塞住等待一个信号的发出。
  4. 如果runloop状态正常切换,那么就会进入回调函数,在回调函数中我们发出一个信号,并且记录当前状态到PingConfig实例中,下面的判断语句中发现为0,timeoutCount自动置为0,一切正常。
  5. 当主线程出现卡顿,while循环中的信号量再次等待,但是回调函数没有触发,从而导致等待超时,返回一个非0数,进入判断句后,我们再次判断状态是否处于 kCFRunLoopBeforeSources 或 kCFRunLoopAfterWaiting,如果成立,timeoutCount+1。
  6. 持续五次runloop不切换状态,说明runloop正在处理某个棘手的事件无法休息且不更新状态,这样while循环中的信号量超时会一直发生,超过五次后我们将断定主线程的卡顿并上传堆栈信息。

经过测试,的确可以检测到主线程的卡顿现象,不得不佩服大佬们的方案。
但是在一次测试中,发现当主线程卡在界面尚未完全显示前,这个方案就检测不出来卡顿了,比如我将下面的代码放在B控制器中:

    dispatch_semaphore_t t = dispatch_semaphore_create(0);
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3.0 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@"----");
        dispatch_semaphore_signal(t);
    });
    dispatch_semaphore_wait(t, DISPATCH_TIME_FOREVER);

上面是一段有问题的代码,将导致主线程的持续堵塞,如果我们在这段代码放在B控制器的ViewDidLoad方法中(ViewWillAppear同样),这样运行后,当你希望push到B控制器时,项目将在上一个界面完全卡住,并且无法用上面的方案检测到,而且CPU及内存都显示正常:

QQ20170930-153549@2x.png

具体原因我想了一下,由于runloop在处理完source0或者source1后,比如界面的跳转也是执行了方法,具体有没有用到source0这不重要,但是后面会紧接着进入准备睡眠(kCFRunLoopBeforeWaiting)的状态,然而此时线程的阻塞导致runloop的状态也被卡住无法切换,这样也就导致在那段检测代码中无法进入条件,从而检测不出来。
但是话说回来,APP在静止状态(保持休眠)和刚刚那种卡死状态都会使runloop维持在 kCFRunLoopBeforeWaiting状态,这样我们就无法在那段代码中增加判断来修复,因为无法知道到底是真的静止没有操作还是被阻塞住,我也没找到线程的阻塞状态属性,如果你发现这个属性,那么就可以使用那个属性来判断。但是我也得说下在没找到那个属性时我的检测方案:

我的检测方案

先上代码:

    dispatch_queue_t serialQueue = dispatch_queue_create("serial", DISPATCH_QUEUE_SERIAL);
    self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, serialQueue);
    dispatch_source_set_timer(self.timer, DISPATCH_TIME_NOW, 0.25 * NSEC_PER_SEC, 0);
    
    __block int8_t chokeCount = 0;
    dispatch_semaphore_t t2 = dispatch_semaphore_create(0);
    dispatch_source_set_event_handler(self.timer, ^{
        if (config->activity == kCFRunLoopBeforeWaiting) {
            static BOOL ex = YES;
            if (ex == NO) {
                chokeCount ++;
                if (chokeCount > 40) {
                    NSLog(@"差不多卡死了");
                    dispatch_suspend(self.timer);
                    return ;
                }
                NSLog(@"卡顿了");
                return ;
            }
            dispatch_async(dispatch_get_main_queue(), ^{
                ex = YES;
                dispatch_semaphore_signal(t2);
            });
            BOOL su = dispatch_semaphore_wait(t2, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC));
            if (su != 0) {
                ex = NO;
            };
        }
    });
    dispatch_resume(self.timer);

解释一下我的方案:

  1. 开启一个异步队列,并且创建一个定时器,时间我设置的是0.25秒,具体时间随你自己,这个时间是用来检测卡死的持续时间。
  2. 在定时器外面我也同样创建了一个用来同步的信号量,这个不解释了,不会的就去看一下信号量的使用方式。进入定时器的回调后,我设置了一个静态变量来记录主队列是否执行完成。
  3. 我们判断当前runloop的状态是否为kCFRunLoopBeforeWaiting,所以这个方案是用来弥补前面那个方案,如果主线程此时没有阻塞住,我们在这里向main Queue抛一个block,看它是否能够成功执行,如果成功执行,说明主线程没有阻塞住,如果已经被阻塞住,那我抛过去的block是肯定不会被执行的。
  4. 下面的代码就是一些辅助操作,当信号量超过50毫秒,抛给主线程的block没有执行,那么说明此时就有一些阻塞了,返回一个非0数,并设置 ex为NO,从而在下一次定时器回调到来时进行上报。

我写的这段解决方案中的示例代码只是用来演示,具体是原理可以大家尽情在此基础上优化,目前在我的项目中可以正常检测到之前那种阻塞造成的APP卡死现象,如果你发现有更好的检测方案,希望能告诉我,谢谢!

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,884评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,755评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,369评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,799评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,910评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,096评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,159评论 3 411
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,917评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,360评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,673评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,814评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,509评论 4 334
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,156评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,882评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,123评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,641评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,728评论 2 351

推荐阅读更多精彩内容

  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 171,870评论 25 707
  • 从哪说起呢? 单纯讲多线程编程真的不知道从哪下嘴。。 不如我直接引用一个最简单的问题,以这个作为切入点好了 在ma...
    Mr_Baymax阅读 2,740评论 1 17
  • Object C中创建线程的方法是什么?如果在主线程中执行代码,方法是什么?如果想延时执行代码、方法又是什么? 1...
    AlanGe阅读 1,722评论 0 17
  • 本文将从以下几个部分来介绍多线程。 第一部分介绍多线程的基本原理。 第二部分介绍Run loop。 第三部分介绍多...
    曲年阅读 1,258评论 2 14
  • 文/爱学习的飞哥 ‖飞哥有话说,专注于探求大学生学习、读书、生活那些事。 ‖本文系作者原创文章,未经许可,不得转载...
    爱学习的飞哥阅读 683评论 1 28