Android卡顿的检测及优化方法汇总（线下+线上）

时间 2021-08-15 标签 Android性能 android 性能卡顿监控工具

卡顿概述

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

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

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

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

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

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

务必确保您看到的内容与用户将会看到的内容类似，要使用应用的发布版本（或至少是不可调试的版本）进行测试。因为Debug版本和发布版本在性能上会存在较大的差异。
启用 GPU 渲染模式分析功能。GPU 呈现模式分析功能会在屏幕上显示一些条形，以相对于每帧16ms的基准，快速直观地显示呈现界面窗口帧所花的时间。每个条形都有带颜色的区段，对应于呈现管道中的一个阶段，这样我们就可以看到哪个部分用时最长。例如，如果帧花费大量时间处理输入，我们就应该查看负责处理用户输入的应用代码。
某些组件（如 RecyclerView）是卡顿的常见来源。如果我们使用了这一类组件，最好查看一下应用的这些部分。
有的卡顿只有在通过冷启动的方式启动时，才会出现。
我们可以尝试在速度较慢的设备上运行您的应用，以放大卡顿问题。

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

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

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

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

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

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

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

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

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

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

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

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

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

示例图：

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

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

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