iOS卡顿检测方案

方案一：基于RunLoop

主线程绝大部分计算或者绘制任务都是以Runloop为单位发生。单次Runloop如果时长超过16ms，就会导致UI体验的卡顿。那如何检测单次Runloop的耗时呢？
Runloop的生命周期及运行机制虽然不透明，但苹果提供了一些API去检测部分行为。

我们可以通过如下代码监听Runloop每次进入的事件：

- (void)setupRunloopObserver{
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        CFRunLoopRef runloop = CFRunLoopGetCurrent(); 
        CFRunLoopObserverRef enterObserver;
        enterObserver = CFRunLoopObserverCreate(CFAllocatorGetDefault(),
                                               kCFRunLoopEntry | kCFRunLoopExit,
                                               true,
                                               -0x7FFFFFFF,
                                               BBRunloopObserverCallBack, NULL);
        CFRunLoopAddObserver(runloop, enterObserver, kCFRunLoopCommonModes);
        CFRelease(enterObserver);
    });
}
static void BBRunloopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
    switch (activity) {
        case kCFRunLoopEntry: {
            NSLog(@"enter runloop...");
        }
            break;
        case kCFRunLoopExit: {
            NSLog(@"leave runloop...");
        }
            break;
        default: break;
    }
}

看起来kCFRunLoopExit的时间，减去kCFRunLoopEntry的时间，即为一次Runloop所耗费的时间，这样就能找出大于16ms的runloop。
但是demo实践结果是：kCFRunLoopExit的时间减去kCFRunLoopEntry，得到的时间差，貌似不准。
缺陷：但无法定位到具体的函数，只能起到预报的作用。

方案一是可以通过监测runloop计算每次主线程的任务执行时间是否超过16ms来判断是否有卡顿，但是缺点在于无法定位卡顿的位置，所以有了方案二。

方案二：基于线程

最理想的方案是让UI线程“主动汇报”当前耗时的任务，听起来简单做起来不轻松。

我们可以假设这样一套机制：每隔16ms让UI线程来报道一次，如果16ms之后UI线程没来报道，那就一定是在执行某个耗时的任务。这种抽象的描述翻译成代码，可以用如下表述：
我们启动一个worker线程，worker线程每隔一小段时间（delta）ping一下主线程（发送一个NSNotification），如果主线程此时有空，必然能接收到这个通知，并pong以下（发送另一个NSNotification），如果worker线程超过delta时间没有收到pong的回复，那么可以推测UI线程必然在处理其他任务了，此时我们执行第二步操作，暂停UI线程，并打印出当前UI线程的函数调用栈。

难点在这第二步，如何暂停UI线程，同时获取到callstack。

iOS的多线程编程一般使用NSOperation或者GCD，这两者都无法暂停每个正在执行的线程。
所谓的cancel调用也只能在目标线程空闲的时候，主动检测cancelled状态，然后主动sleep，这显然非我所欲。

如果我们从worker线程给UI线程发送signal，UI线程会被即刻暂停，并进入接收signal的回调，再将callstack打印就接近目标了。

iOS确实允许在主线程注册一个signal处理函数，类似这样：

//在主线程注册signal handler
signal(CALLSTACK_SIG, thread_singal_handler);

//通过NSNotification完成ping pong流程
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(detectPingFromWorkerThread) name:Notification_PMainThreadWatcher_Worker_Ping object:nil];
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(detectPongFromMainThread) name:Notification_PMainThreadWatcher_Main_Pong object:nil];

//如果ping超时，pthread_kill主线程。
pthread_kill(mainThreadID, CALLSTACK_SIG);

//主线程被暂停，进入signal回调，通过[NSThread callStackSymbols]获取主线程当前callstack。
static void thread_singal_handler(int sig) {
    NSLog(@"main thread catch signal: %d", sig);
    if (sig != CALLSTACK_SIG) {
        return;
    }
    NSArray* callStack = [NSThread callStackSymbols];
    id<PMainThreadWatcherDelegate> del = [PMainThreadWatcher sharedInstance].watchDelegate;
    if (del != nil && [del respondsToSelector:@selector(onMainThreadSlowStackDetected:)])  {
        [del onMainThreadSlowStackDetected:callStack];
    }
    else {
        NSLog(@"detect slow call stack on main thread! \n");
        for (NSString* call in callStack) {
            NSLog(@"%@\n", call);
        }
    }
    return;
}

说明：
值得一提的是上述代码不能调试，因为调试时gdb会干扰signal的处理，导致signal handler无法进，但UI线程在遇到卡顿的时候还是能正常被中断。
现阶段的实现，worker线程每隔1秒会ping一次UI线程，检测出运行超过16ms的调用栈。开发阶段可以将1s的间隔调至更短，可能会对app整体性能造成少许的负担，但能检测出更多的卡顿调用。

signal相关的知识点
iOS系统的signal可以被归为两类：

第一类内核signal，这类signal由操作系统内核发出，比如当我们访问VM上不属于自己的内存地址时，会触发EXC_BAD_ACCESS异常，内核检测到该异常之后会发出第二类signal：BSD signal，传递给应用程序。

第二类BSD signal，这类signal需要被应用程序自己处理。通常当我们的App进程运行时遇到异常，比如NSArray越界访问。产生异常的线程会向当前进程发出signal，如果这个signal没有别处理，我们的app就会crash了。

平常我们调试的时候很容易遇到第二类signal导致整个程序被中断的情况，gdb同时会将每个线程的调用栈呈现出来。

pthread_kill允许我们向目标线程（UI线程）发送signal，目标线程被暂停，同时进入signal回调，将当前线程的callstack获取并处理，处理完signal之后UI线程继续运行。将callstack打印即可精确定位产生问题的函数调用栈。

方案三：CADisplayLink监控

CADisplayLink监控的思路是每个屏幕刷新周期，派发标记位设置任务到主线程中，如果多次超出16.7ms的刷新阙值，即可看作是发生了卡顿。

什么是CADisplayLink？
CADisplayLink是一个能让我们以和屏幕刷新率相同的频率将内容画到屏幕上的定时器。
我们在应用中创建一个新的 CADisplayLink 对象，把它添加到一个runloop中，并给它提供一个 target 和selector 在屏幕刷新的时候调用。
一旦 CADisplayLink 以特定的模式注册到runloop之后，每当屏幕需要刷新的时候，runloop就会调用CADisplayLink绑定的target上的selector，这时target可以读到 CADisplayLink 的每次调用的时间戳，用来准备下一帧显示需要的数据。

#define LXD_RESPONSE_THRESHOLD 10
dispatch_async(lxd_fluecy_monitor_queue(), ^{
    CADisplayLink * displayLink = [CADisplayLink displayLinkWithTarget: self selector: @selector(screenRenderCall)];
    [self.displayLink invalidate];
    self.displayLink = displayLink;

    [self.displayLink addToRunLoop: [NSRunLoop currentRunLoop] forMode: NSDefaultRunLoopMode];
    CFRunLoopRunInMode(kCFRunLoopDefaultMode, CGFLOAT_MAX, NO);
});

- (void)screenRenderCall {
    __block BOOL flag = YES;
    dispatch_async(dispatch_get_main_queue(), ^{
        flag = NO;
        dispatch_semaphore_signal(self.semphore);
    });
    dispatch_wait(self.semphore, 16.7 * NSEC_PER_MSEC);
    if (flag) {
        if (++self.timeOut < LXD_RESPONSE_THRESHOLD) { return; }
        [LXDBacktraceLogger lxd_logMain];
    }
    self.timeOut = 0;
}