Alpha iOS App的卡顿监控初探

作为一个iOS或者说是app 开发工程师，面对如此激烈的市场竞争，我们需要对我们的app质量做到精益求精。我们首先要保证APP没有崩溃现象，并且在没有功能和系统bug的前提下，提高我们的App的性能，从而能够给用户更加良好的体验。

Alpha作为一款面向律师群体的App更是将性能作为一个非常重要的课题来进行考虑。毕竟我们面对的用户是时间就是金钱的一个群体。

其实我们说的卡顿，就是App在渲染过程中的掉帧现象，即一个页面特别是列表滚动过程中，产生不连续的感觉。根据研究，当渲染的帧率小于每秒55帧的时候，人们就可以肉眼察觉到App的卡顿了。

那么在app的开发过程中，我们首先就需要知道我们的App 在什么地方可能产生卡顿，或者说性能需要提高的地方。毕竟，要先找到问题，才能说优化。我们的工程师参考了很多业界通用的方法后，加上自身的研究，总结出几项常用的性能检测方案。

1.根据runloop的启动和结束检测

主线程绝大部分计算或者绘制任务都是发生在每一次的Runloop中。单次Runloop如果时长超过16ms，那么我们便认为有UI卡顿(16ms * 55 > 1s)。那如何检测单次Runloop的时长呢？其实苹果为我们提供了监控Runloop几种状态的方法，我们只需要记录kCFRunLoopExit的时间点和kCFRunLoopEntry的时间点，并且计算二者的差值，如果大于16ms,则认为产生了一次卡顿。但是在我们试验后发现的实际体验中，如果只出现一次卡顿，我们也可以认为是可以被原谅的，但是如果在十次的runloop执行中，出现了50%以上的>16ms，我们则认为产生了卡顿现象，此时我们就要跟踪是什么导致了这次卡顿。

代码展示如下：

- (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(@"进入一次runloop并且记录时间"); }

break;

case kCFRunLoopExit:

{ NSLog(@"退出一次runloop并且记录时间，然后计算差值"); }

break;

default: break;

} }

但是我们可以知道，这个方法虽然已经是业界最通用也最普遍的做法，但是这个方法依然会导致一个问题，就是这种做法会导致runloop污染，特别是我们需要监控的是主线程，而此时如果我们需要打印主线程当前的函数调用栈，并且通过其他线程发送给外界的时候(后续会有介绍)，就可能会导致一些其他的问题。所以说尽管这个犯法有很多的好处，但是我们目前还不推荐这个方法。

2.通过CADisplayLink监控

这个方法其实是从计算机的角度来理解的，就是在一个绘制周期内，如果产生了无法绘制成功，或者说还在绘制上一个绘制周期应该绘制的内容的话，即可认为是产生了掉帧现象，此时我们通知外界，打印当前调用栈，从而能够分析原因。我们我们这里使用iOS开放的CADisplayLink对象对屏幕的绘制周期进行监控(没错，又是监控，Apple为了能让我们开发者对他们的系统进行监控真是操碎了心)。

代码如下：

dispatch_async(users_monitor_queue(), ^{

CADisplayLink * displayLink = [CADisplayLink displayLinkWithTarget: self selector: @selector(screenRenderCall)];

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; }

   NSLog(@”打印调用栈”); }

   self.timeOut = 0;

}

通过这个方法，我们可以在另一个线程中，通过监控CADisplayLink的刷新帧的时间的方式，更安全（优雅）地对我们的app性能进行监控。

以上就是Alpha App开发团队对于可能产生卡顿的地方的一些看法，如有不足之处还请指出，我们一同交流。后期我们还会介绍如果打印当前线程或某个线程的函数调用栈，从而能在当app卡顿或发生其他情况时，获取一定的排查线索，敬请期待。

如果您想加入我们，一家致力于用技术改变法律的公司，那么请您随时投递建立shangjing@icourt.cc.