应用卡顿是导致用户流失的重要原因之一，卡顿监控模块致力于协助用户治理卡顿问题。卡顿治理的一个重要思路是，通过提取有效的指标衡量应用当前的状况，抓取足够的信息提供优化方向。卡顿监控模块通过FPS及挂起率两个指标来衡量应用的流畅度情况，通过卡顿问题监控，直接抓取卡顿堆栈，协助用户定位卡顿原因，为用户提供优化方向。

FrameRate：帧率是GPU和CPU合作，在应用运行时，可产生的图像的数量，计量单位是帧/秒（FramesPerSecond，缩写FPS），通常是评估硬件性能与应用体验流畅度的指标。

Bugly专业版的卡顿监控统计的是包含真实UI刷新的FPS，剔除了页面静止期间的数据。这样统计的数据反应了用户使用应用的真实感受。

我们举例说明一下，相册页面，如果应用没有处理好异步加载的话，在用户滑动时，可能特别卡。用户安静观看照片时，由于没有触发耗时操作，可能看起来一切正常。如果以用户停留页面总时长来统计FPS，则页面无刷新的时间可能将滑动时的卡顿表现给平均掉了。使用Bugly专业版的卡顿指标监控，则没有这个问题，我们只统计包含页面真实刷新时FPS，不会因为页面无刷新的时长变化而导致FPS变化。

除此之外，Bugly充分考虑了不同屏幕刷新率的情况。不同的屏幕刷新率最终影响VSYNC信号的产生频率（见下图）。当前市面上存在各种屏幕刷新率的手机，常见的是60Hz, 90Hz, 120Hz。简单来讲，如果一个应用性能非常好，UI更新不耗时，那么其帧率是受屏幕刷新率限制的，其帧率不可能高于屏幕刷新率。也就是说，即使一个性能非常好的应用，在不同屏幕刷新率下，其帧率是不一样的。这也是一些游戏手机，为了提升体验，屏幕刷新率一般比较高，超过传统的60Hz。 Bugly的帧率监控是希望直接运行在线上的，需要兼容不同的屏幕刷新率。经过多方考量后，我们决定采用归一化的思想，将不同屏幕刷新率统一归一到60Hz的情况。也就是说，即使两台不同刷新率的手机，Bugly统计到的一款应用的FPS基本一致。

当前Bugly是按场景来统计FPS，在应用运行过程中，卡顿指标统计模块，统计一个个场景的数据，用户切换场景后，统计模块会保存上一个场景的数据。在应用下次启动后，上报模块会提取上次运行期间所采集的数据，合并相同场景的数据，最终得到一个个不同场景的数据记录。这些数据记录上报到服务器，服务器会保存这些原始记录，同时统计平均值，分位值(P50、P90、P99)。

用户可以在趋势分析中，查看一天，或者一段时间的FPS变化趋势。Bugly提供了平均值，分位值(P50、P90、P99)多种统计方式，帮助用户更好理解应用FPS的整体状况。

假如，A应用的某次运行，用户体验了10个场景，产生10条记录上报到服务器。共有10个用户上报，总共产生了100条记录。每条记录都有FPS，Bugly服务器将这100条记录按FPS的大小排序，从大到小排序。已排序数据中的第50个，即这批数据中的P50。已排序数据中的第90个，即为这批数据中的P90。已排序数据中的第99个，即为这批数据中的P99。

在FPS中，分位值是按从大到小排序的，因此 P50 >= P90 >= P99 。

用户可以查询指定条件下的FPS数据，如下图所示的，指定场景的FPS：

在趋势分析中，我们可以将一组查询结果添加到对比列表中，添加多组查询结果后，后续可以在对比列表中，对比分析这两组数据。

如下图所示，我们期望对比分析两个不同场景的数据情况，分别查询这两个场景的数据，添加到对比列表中，点击 趋势预览 即可查看不同统计维度的对比结果。

有些情况下，我们想查看一段时间，所有APP版本，或者所有场景的数据情况，通过多维分析，可以解决这个问题。

我们还有可能想分析指定版本，在某些场景下的数据情况。

Bugly卡顿监控，对于挂起率的统计是，如果应用两帧之间的刷新延时超过200ms，则认为此时应用不能很好地响应用户的交互，并且累加到挂起时间中。一个设备的挂起率，是指这个设备在一天中，总的挂起时间除以设备的前台总时长。也就是说，卡顿监控的挂起率，是以设备，按天聚合统计的。

设备挂起率 = 设备一天的累计挂起时间（单位是秒）/ 设备一天的前台总时长 （单位是小时）

对于一个应用而言，我们关注的是设备挂起率的分位值，如P50, P90, P99等。例如，某个应用A，在某天中，有100台设备上报了挂起率数据，则后台按设备ID聚合，得到100条记录，每条记录统计挂起率。这100条记录，从小到大排序。在已排序的数据中，第50个为45.23s/h，则P50 = 45.23s/h。依次类推，第90个数据为134.23s/h，则P90=134.23s/h。

跟FPS类似，挂起率也支持趋势分析，对比分析以及多维分析，交互参考前面的FPS指标。

卡顿问题监控核心专注于帮助用户找到导致应用卡顿的原因，通过监控UI线程消息执行耗时，结合高频、连续抓栈策略，将耗时超过阈值的情况上报到服务器。服务器基于卡顿堆栈树，提取关键耗时特征，将个例聚合成Issue（问题），得到卡顿问题列表。

问题详情分为三部分，问题头部，详情分析以及下钻分析。

查看某个卡顿个例，我们核心关注的是以下信息：

虽然卡顿堆栈的耗时是根据抓栈次数以及抓栈间隔估算得到，但是卡顿耗时却是准确的，表示一个UI线程的消息执行的耗时。当前卡顿监控通过监控UI线程的消息执行耗时来判断应用是否发生了卡顿。

以下图示例，这个堆栈连续6帧都被抓中，当前的抓栈间隔是52ms，堆栈的耗时估算为 52 x 6 = 312 ms。

Android 与 iOS，甚至iOS的不机型，抓栈间隔可能都有差异，大家可以结合时间片中显示的抓栈次数，再结合推算的抓栈耗时推算出本个例的抓栈间隔。

另外，用户还可以结合操作日志以及现场数据来进一步分析卡顿现场。

用户可以通过下钻分析来查看Issue的上报趋势，以及在一些字段的分布情况。

指这个字段包含有效值的上报情况。有些情况下，某些字段可能存在取不到值，或者取的值不合法的情况。因此虽然搜索条件一致，有可能不同字段的有效上报次数不一致。

结合业务的卡顿治理经验，我们总结了一些通用的技能，以提升分析卡顿问题效率。

卡顿治理往往最先遇到的问题是，开启卡顿监控后，发现上报了几万个问题，分析成本巨大。根据应用的实际情况，阶段阶段调整卡顿阈值，先解决一些比较明显的卡顿问题，例如卡顿耗时大于500ms的。通过分阶段调整卡顿阈值，既可以专注有效的精力在重要问题上，又可以降低上报成本。

根据二八原则，80%的上报集中在20%的问题上，所以你只需要聚焦Top问题。这些Top问题首先从上报量表现这是一个用户容易遇到的问题，而不会受个例特殊环境的影响。根据搜索结果的摘要，我们可以快速了解问题的大致情况，再根据实际情况来选择合适的Top问题来分析。

如下图所示：满足条件的问题共有5590个，但是Top500的问题包含了80%以上的上报个例。也就是说，我们只需要聚集这Top500的问题，而不需要分析所有的问题。

如何评估一个问题是否对用户体验影响大，以及其影响面是不是比较广呢？需要结合卡顿问题列表的卡顿耗时P50，关键堆栈耗时P50，叶子结点耗时P50，以及触发次数。

如下图所示：在资源有限的情况，如果只能解决一个问题，选择第3个问题来解决的性价比会比较高。首次其上报次数比较高，占Top3的问题，其次其卡顿耗时比较大，并且叶子结点最大耗时P50比较大，说明是一个单一节点耗时问题，修复的成本通常会比较小。

问题列表包含卡顿耗时，关键堆栈耗时，以及叶子结点最大耗时等特性的平均值，以及分位值。

下图展示了，在一个卡顿个例中，卡顿耗时，关键堆栈耗时以及叶子结点最大耗时的含义。

分位值，亦称分位点，是指将一个随机变量的概率分布范围分为几个等份的数值点，常用的有中位数（即二分位数）、四分位数、百分位数等。这里Bugly平台使用的是百分位数。百分位数是统计学术语，如果将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。以卡顿耗时来说，一个问题包含多个例上报，每个个例上报的耗时都不是完全相同的。我们可以将这一个个的上例上报的卡顿耗时，从小到大进行排序，如下图所示，共30个上报，P50 = 排序15对应的卡顿耗时468ms。

卡顿问题分为三大类：单点耗时，多点耗时，复杂或频繁执行。

单点耗时

多点耗时

不同类型的问题，治理的成本是有差异的。一般来说，单点耗时问题，比较容易推动解决。其次就是多点耗时问题。而复杂或者频繁执行的问题，往往需要做一些比较大范围的重构，治理的成本也是最高的。

如下图所示：满足条件的问题有27个，其中Top9的问题包含81.48%的上报个例，说明我们只需要关注Top9的问题即可。在这Top9的问题中，通过叶子节点耗时P50排序，我们找到单点耗时问题，优先解决性价比最高的问题。

应用的历史问题可能特别多，推动这些问题解决不太容易，特别有一些是历史代码，调整的成本比较高，也容易引发质量问题。但是，新问题就不一样，一般是近期开发所导致的问题，这类问题比较容易推动开发解决，而且解决的成本也往往比较低。通过条件对比功能，可以帮助我们快速定位到新增问题。

如下图所示，1.4.4版本为我们最新开发版本，在发布前，我们通过条件对比功能，我们可以快速找到1.4.4版本的新增问题。

挂起率是以设备为单位，按天统计，该设备在一天中，应用在前台时，两帧耗时超过200ms的挂起时长，以及应用在前台的时长。设备挂起率 = 设备一天的累计挂起时间（单位是秒）/ 设备一天的前台总时长 （单位是小时），挂起率的单位是 秒/小时（s/h）。

FPS按场景统计，当前统计的是应用包含UI真实刷新的FPS，剔除了页面无UI刷新时的数据。Bugly当前展示的FPS数据通过了归一化处理，以兼容不同屏幕刷新率。

卡顿问题监控中，方法耗时是通过连续抓栈，结合抓栈间隔，估算得到。例如一个堆栈被连续抓中6次，抓栈间隔是52ms，则这个堆栈的执行耗时是 6 x 52 = 320 ms 。这种估算方式存在误差，误差为抓栈间隔。但是卡顿耗时却是准确的，表示一个UI线程的消息执行的耗时。当前卡顿监控通过监控UI线程的消息执行耗时来判断应用是否发生了卡顿。

如果一个堆栈耗时为52ms，表示这个堆栈在连续抓栈过程中，只被抓中了一次，并不代表其真正耗时为52ms。如果一个堆栈被抓中N次，其中N大于1，则表示该堆栈耗时一定大于(N-1)*52ms。

Android 与 iOS，甚至iOS的不机型，抓栈间隔可能都有差异，大家可以结合时间片中显示的抓栈次数，再结合推算的抓栈耗时推算出本个例的抓栈间隔。

根据前面内容可知，每一个个例包含一棵堆栈树。为了聚合问题，需要抽取特征。导致卡顿的主要原因是不是就是关键堆栈。如下所示，以下就是这个个例的关键堆栈了。

叶子结点最大耗时是指一个堆栈树，所有叶子结点中耗时最大的。如果一个卡顿问题，其叶子结点最大耗时比较大，甚至接近于关键堆栈耗时，说明叶子结点的堆栈就是卡顿的主要原因。像死锁，UI线程执行IO操作，UI线程访问DB，往往叶子结点最大耗时会比较大。