微信开发者对于卡顿的定义，很简单，很清晰，很明了，这里就cv过来了，一定要仔细读对卡顿的定义
什么是卡顿，很多人能马上联系到的是帧率 FPS (每秒显示帧数)。那么多低的 FPS 才是卡顿呢？又或者低 FPS 真的就是卡顿吗？（以下 FPS 默认指平均帧率）
其实并非如此，举个例子，游戏玩家通常追求更流畅的游戏画面体验一般要达到 60FPS 以上，但我们平时看到的大部分电影或视频 FPS 其实不高，一般只有 25FPS ~ 30FPS，而实际上我们也没有觉得卡顿。
在人眼结构上看，当一组动作在 1 秒内有 12 次变化（即 12FPS），我们会认为这组动作是连贯的；而当大于 60FPS 时，人眼很难区分出来明显的变化，所以 60FPS 也一直作为业界衡量一个界面流畅程度的重要指标。一个稳定在 30FPS 的动画，我们不会认为是卡顿的，但一旦 FPS 很不稳定，人眼往往容易感知到。
FPS 低并不意味着卡顿发生，而卡顿发生 FPS 一定不高。FPS 可以衡量一个界面的流程性，但往往不能很直观的衡量卡顿的发生，这里有另一个指标（掉帧程度）可以更直观地衡量卡顿。
什么是掉帧（跳帧）？按照理想帧率 60FPS 这个指标，计算出平均每一帧的准备时间有 1000ms/60 = 16.6667ms，如果一帧的准备时间超出这个值，则认为发生掉帧，超出的时间越长，掉帧程度越严重。
假设每帧准备时间约 32ms，每次只掉一帧，那么 1 秒内实际只刷新 30 帧，即平均帧率只有 30FPS，但这时往往不会觉得是卡顿。反而如果出现某次严重掉帧（>300ms），那么这一次的变化，通常很容易感知到。所以界面的掉帧程度，往往可以更直观的反映出卡顿。
流畅性
综上所述，其实可以明白对于卡顿的定义，衡量流畅性的指标可以简单理解为：
在用户有操作的前提下平均掉帧率。只有在某一时刻发生的掉帧情况远远大于其他时刻，那么才界定为卡顿，这也是上面说到的界面的掉帧程度，才更直观的反映出卡顿
流畅指标，佳0，正常1，中等2，严重3，冻帧4
综上，就是Matrix中对页面流畅性分析的核心代码，而对于Matrix中精准命中堆栈则可以取自冻帧或者所谓的duration >= 200这个条件下dump一次主线程的堆栈来获取
慢函数
其实关于上述严重掉帧情况下的抓取堆栈的数量不多，同样避不开上面提到的漏掉其他耗时代码的情况，不过笔者认为这样的情况不会特别多，因为卡顿发生的时候，大概率避免不了正在执行一个耗时操作，那么这个耗时操作的堆栈出现在此刻dump出来的堆栈里面的可能性很大，所以Matrix干脆利落的出了一个慢函数检测。
这样感觉就无孔不入了，对所有在主线程上运行的函数耗时进行收集，和BlockCanary检测卡顿的策略一样，但是堆栈的抓取就要复杂一些，这也是为什么Matrix性能更好的原因，能在灰度下上线的能力。同时也能有对应的聚合策略，这样结合后端的能力方便我们分析代码运行情况，然后做 “狭义” 上的优化。
网友评论