卡顿概述

界面呈现是指从应用生成帧并将其显示在屏幕上的动作。我们要确保用户能够流畅地与应用互动，我们的应用呈现每帧的时间不应超过16ms，以达到每秒 60 帧的呈现速度。如果我们的应用存在界面呈现缓慢的问题，系统会不得不跳过一些帧，这会导致用户感觉您的应用不流畅。我们将这种情况称为卡顿。

如果我们的应用存在卡顿，应该如何进行诊断和解决呢？

识别卡顿

想要在应用中找出导致卡顿的代码可能并非易事。接下来我们将介绍常用的一些方法和工具。

有效识别卡顿，有如下几种方法：

目视检查法

打开你的应用并手动查看应用的不同部分，看看是否有卡顿的界面。该方法有助于你找出导致卡顿的用例和场景。

使用目视检查时，要注意以下几点：

务必确保您看到的内容与用户将会看到的内容类似，要使用应用的发布版本（或至少是不可调试的版本）进行测试。因为版本和发布版本在性能上会存在较大的差异。

启用 GPU 渲染模式分析功能。GPU 呈现模式分析功能会在屏幕上显示一些条形，以相对于每帧16ms的基准，快速直观地显示呈现界面窗口帧所花的时间。每个条形都有带颜色的区段，对应于呈现管道中的一个阶段，这样我们就可以看到哪个部分用时最长。例如，如果帧花费大量时间处理输入，我们就应该查看负责处理用户输入的应用代码。

某些组件（如 ）是卡顿的常见来源。如果我们使用了这一类组件，最好查看一下应用的这些部分。

有的卡顿只有在通过冷启动的方式启动时，才会出现。

我们可以尝试在速度较慢的设备上运行您的应用，以放大卡顿问题。

通过目视检查法，我们发现了导致卡顿的用例和场景，通过本地代码分析，我们可能已经找到了卡顿原因。但是，如果卡顿原因并没有准确定位，就需要我们收集更多的信息来进一步深入分析了。

方法

工具用于显示整个设备在做些什么，不过也可用于识别应用中的卡顿。 的系统开销非常小，因此我们可以在插桩测试期间体验实际卡顿情况。

在设备上执行卡顿的用例的场景时，我们可以使用 记录跟踪信息。系统跟踪信息会按进程和线程进行细分，我们可以在 中查看应用的进程，该进程应如图所示：

图：信息（系统跟踪信息）

系统跟踪信息包含以下用于识别卡顿的信息：

系统跟踪信息会显示每帧的绘制时间，并对每帧进行颜色编码以突出显示渲染速度缓慢的时间。与目视检查相比，这种方法有助于您更准确地找出各个卡顿的帧。

系统跟踪信息会检测应用中的问题，并在各个帧和提醒面板中同时显示提醒。

框架和库的某些部分（如 ）包含跟踪标记。因此，系统跟踪信息时间轴会显示在界面线程上执行这些方法的时间以及时长。

查看系统跟踪信息输出后，可能我们会怀疑应用中的某些方法是导致卡顿的因素。

例如，如果时间轴显示某个帧的呈现速度较慢是因为 花费很长时间导致的，这时，我们可以在相关代码中添加跟踪标记（性能分析工具的使用详解），然后重新运行 以获取更多信息。在新的系统跟踪信息中，时间轴会显示应用中的方法的调用时间和执行时长。

注意：记录系统跟踪信息时，每个跟踪标记（执行的开始和结束对）会增加大约 10μs 的开销。为了避免出现假正例卡顿，对于在一帧中会被调用数十次或用时少于 的方法，请勿为其添加跟踪标记。

注：关于的详细使用方法，请参考前文《性能分析工具的使用详解》。

CPU 工具

如果信息未显示关于界面线程工作为何用时较长的详细信息，我们可能需要使用 CPU 来记录采样或插桩测试的方法跟踪信息。

CPU 性能剖析器可实时检查应用的 CPU 使用率和线程活动。你还可以检查方法跟踪记录、函数跟踪记录和系统跟踪记录中的详细信息。

使用CPU 可以查看主线程中，每个方法的耗时情况，以及每个方法的调用栈，可以很方便的分析卡顿产生的原因，以及定位到具体的代码方法。

通常情况下，方法跟踪信息不适合用于识别卡顿，因为它们会因开销过大而导致出现假正例卡顿，且无法查看线程何时运行以及何时处于阻塞状态。不过，方法跟踪信息可以帮助我们找出应用中用时最多的方法。找出这些方法后，我们就可以添加跟踪标记并重新运行 以查看这些方法是否会导致卡顿。

示例图：

CPU 的使用方法请参考前文《 CPU 性能分析工具介绍和使用详解》。

线上性能监控方法

以上的方法都属于线下性能检测场景，使用它们可以发现一些特定的场景或者卡顿明显的场景。但是针对线上用户，用户的使用场景和机型千差万别，这时我们必须要具备线上的性能采集方案，监控线上用户的使用状况。

线上卡顿监控方案，可以参考之前写的几个方案：

UI卡顿检测（一）——基于机制的实现方案（线上方案） UI卡顿检测（二）——基于原理的方案（线上方案）线上帧率的检测。（通过.回调来实现帧率监控） 总结

本文介绍了卡顿是什么，以及如何使用适合的工具发现卡顿、如何在线上和线下环境实现卡顿的监控。

PS：性能优化专栏：《性能》持续更新中……