我们知道， Android系统每隔16ms发出VSYNC信号，来通知界面进行重绘、渲染，每一次同步的周期为16.6ms，代表一帧的刷新频率。SDK中包含了一个相关类，以及相关回调。理论上来说两次回调的时间周期应该在16ms，如果超过了16ms我们则认为发生了卡顿，利用两次回调间的时间周期来判断是否发生卡顿（这个方案是Android 4.1 API 16以上才支持）。
这个方案的原理主要是通过Choreographer类设置它的FrameCallback函数，当每一帧被渲染时会触发回调FrameCallback， FrameCallback回调void doFrame (long frameTimeNanos)函数。一次界面渲染会回调doFrame方法，如果两次doFrame之间的间隔大于16.6ms说明发生了卡顿。
优点：不仅可用来从app层面来监控卡顿，同时可以实时计算帧率和掉帧数，实时监测App页面的帧率数据，一旦发现帧率过低，可自动保存现场堆栈信息。
缺点：需另开子线程获取堆栈信息，会消耗少量系统资源。
总结下上述四种方案的对比情况：
SurfaceFlinger gfxinfo Looper.loop Choreographer.FrameCallback监控是否卡顿 √ √ √ √
支持静态页面卡顿检测 × × √ √
支持计算帧率 √ √ × √
支持获取App运行信息 × × √ √
实际项目使用中，我们一开始两种监控方式都用上，上报的两种方式收集到的卡顿信息我们分开处理，发现卡顿的监控效果基本相当。同一个卡顿发生时，两种监控方式都能记录下来。 由于Choreographer.FrameCallback的监控方式不仅用来监控卡顿，也方便用来计算实时帧率，因此我们现在只使用Choreographer.FrameCallback来监控app卡顿情况。
痛点1：如何保证捕获卡顿堆栈的准确性？
细心的同学可以发现，我们通过上述两种方案（Looper.loop和Choreographer.FrameCallback）可以判断是当前主线程是否发生了卡顿，进而在计算发现卡顿后的时刻dump下了主线程的堆栈信息。实际上，通过一个子线程，监控主线程的活动情况，计算发现超过阈值后dump下主线程的堆栈，那么生成的堆栈文件只是捕捉了一个时刻的现场快照。打个不太恰当的比方，相当于闭路电视监控只拍下了凶案发生后的惨状，而并没有录下这个案件发生的过程，那么作为警察的你只看到了结局，依然很难判断案情和凶手。在实际的运用中，我们也发现这种方式下获取到的堆栈情况，查看相关的代码和函数，经常已经不是发生卡顿的代码了。
如图所示，主线程在T1~T2时间段内发生卡顿，上述方案中获取卡顿堆栈的时机已经是T2时刻。实际卡顿可能是这段时间内某个函数的耗时过大导致卡顿，而不一定是T2时刻的问题，如此捕获的卡顿信息就无法如实反应卡顿的现场。
我们看看在这之前微信iOS主线程卡顿监控系统是如何实现的捕获堆栈。微信iOS的方案是起检测线程每1秒检查一次，如果检测到主线程卡顿，就将所有线程的函数调用堆栈dump到内存中。本质上，微信iOS方案的计时起点是固定的，检查次数也是固定的。如果任务1执行花费了较长的时间导致卡顿，但由于监控线程是隔1秒扫一次的，可能到了任务N才发现并dump下来堆栈，并不能抓到关键任务1的堆栈。这样的情况的确是存在的，只不过现上监控量大走人海战术，通过概率分布抓到卡顿点，但依然不是最佳的捕获方案。
因此，摆在我们面前的是如何更加精准地获取卡顿堆栈。为了卡顿堆栈的准确度，我们想要能获取一段时间内的堆栈，而不是一个点的堆栈，如下图：
