Android性能分析工具

卡顿检测工具

• GPU呈现模式分析 Profile GPU Rendering
  它的功能特点如下：

1. 它是一个图形监测工具，能实时反应当前绘制的耗时。
2. 横轴表示时间，纵轴表示每一帧的耗时（单位为 ms）。
3. 随着时间推移，从左到右的刷新呈现。
4. 提供了一个标准的耗时，如果高于标准耗时，表示当前这一帧丢失。

打开方式：以小米手机为例（android8.1）：在开发者选项 --> GPU呈现模式分析 --> 在屏幕上显示为条形图
打开以后可以在屏幕看到实时刷新的彩色图如下图所示：

每一条柱状图都由几种颜色构成，下面说说他们的含义
官方中文说明 链接

• android 6.0以上：

竖条区段	渲染阶段	说明
	交换缓冲区	表示 CPU 等待 GPU 完成其工作的时间。 如果此竖条升高，则表示应用在 GPU 上执行太多工作。
	命令问题	表示 Android 的 2D 渲染器向 OpenGL 发起绘制和重新绘制显示列表的命令所花的时间。 此竖条的高度与它执行每个显示列表所花的时间的总和成正比—显示列表越多，红色条就越高。
	同步和上传	表示将位图信息上传到 GPU 所花的时间。 大区段表示应用花费大量的时间加载大量图形。
	绘制	表示用于创建和更新视图显示列表的时间。 如果竖条的此部分很高，则表明这里可能有许多自定义视图绘制，或 onDraw 函数执行的工作很多。
	测量/布局	表示在视图层次结构中的 onLayout 和 onMeasure 回调上所花的时间。 大区段表示此视图层次结构正在花很长时间进行处理。
	动画	表示评估运行该帧的所有动画程序所花的时间。 如果此区段很大，则表示您的应用可能在使用性能欠佳的自定义动画程序，或因更新属性而导致一些意料之外的工作。
	输入处理	表示应用执行输入 Event 回调中的代码所花的时间。 如果此区段很大，则表示此应用花太多时间处理用户输入。 考虑将此处理任务分流到另一个线程。
	其他时间/VSync 延迟	表示应用执行两个连续帧之间的操作所花的时间。 它可能表示界面线程中进行的处理太多，而这些处理任务本可以分流到其他线程。

表 1. Android 6.0 及更高版本中的竖条区段。

• android 4.1-android5.0之间

竖条区段	渲染阶段	说明
	进程	表示 CPU 等待 GPU 完成其工作的时间。 如果此竖条升高，则表示应用在 GPU 上执行太多工作。
	执行	表示 Android 的 2D 渲染器向 OpenGL 发起绘制和重新绘制显示列表的命令所花的时间。 此竖条的高度与它执行每个显示列表所花的时间的总和成正比—显示列表越多，红色条就越高。
	XFer	表示将位图信息上传到 GPU 所花的时间。 大区段表示应用花费大量的时间加载大量图形。 此区段在运行 Android 4.0 或更低版本的设备上不可见。
	更新	表示用于创建和更新视图显示列表的时间。 如果竖条的此部分很高，则表明这里可能有许多自定义视图绘制，或 onDraw 函数执行的工作很多。

表 2. Android 4.0 及 5.0 中的竖条区段。

• 在最GPU呈现模式分析图中，任何时候超过绿线（警戒线，16ms）就有可能丢失一帧的内容，虽然对大部分应用来说丢失几帧确实看不出卡顿，但是保持UI流畅的关键就在于让这些垂直柱状图尽可能得保持在绿线下面。

在实际开发中，从视图上虽然可以看到绘制的时间，但不便于进行数据分析，比如进入某一个界面，柱状图虽然实时绘制出来，但是不能更好的分析，这里可以通过adb命令来把具体耗时输出输出到日志中来分析。

adb shell dumpsys gfxinfo com.包名

输出样式如下：

Applications Graphics Acceleration Info:
Uptime: 3081740331 Realtime: 7259093546

** Graphics info for pid 26484 [com包名] **  //pid 26484 

Stats since: 3076198602841311ns
Total frames rendered: 2029 //共收集了2029 帧信息
Janky frames: 132 (6.51%)
50th percentile: 8ms
90th percentile: 13ms
95th percentile: 23ms
99th percentile: 73ms
Number Missed Vsync: 68 //垂直同步失败的帧
Number High input latency: 0 //处理input时间超时的帧
Number Slow UI thread: 94 //因为ui线程导致slow的帧
Number Slow bitmap uploads: 13 //因为bitmap加载slow的帧
Number Slow issue draw commands: 14  //因为绘制导致slow的帧
HISTOGRAM: 5ms=646 6ms=95 7ms=104 8ms=211 9ms=243 10ms=310 11ms=146 12ms=68 13ms=30 14ms=22 15ms=13 16ms=10 17ms=4 18ms=5 19ms=2 20ms=6 21ms=8 22ms=2 23ms=4 24ms=6 25ms=4 26ms=2 27ms=6 28ms=3 29ms=1 30ms=3 31ms=0 32ms=6 34ms=5 36ms=1 38ms=5 40ms=1 42ms=4 44ms=4 46ms=4 48ms=6 53ms=3 57ms=5 61ms=6 65ms=4 69ms=0
 73ms=1 77ms=0 81ms=4 85ms=0 89ms=1 93ms=1 97ms=2 101ms=1 105ms=1 109ms=1 113ms=0 117ms=1 121ms=0 125ms=2 129ms=0 133ms=1 150ms=2 200ms=1 250ms=1 300ms=1 350ms=0 400ms=0 450ms=0 500ms=0 550ms=0 600ms=0 650ms=0 700ms=0 750ms=0 800ms=0 850ms=0 900ms=0 950ms=0 1000ms=0 1050ms=0 1100ms=0 1150ms=0 1200ms=0 1250ms=
0 1300ms=0 1350ms=0 1400ms=0 1450ms=0 1500ms=0 1550ms=0 1600ms=0 1650ms=0 1700ms=0 1750ms=0 1800ms=0 1850ms=0 1900ms=0 1950ms=0 2000ms=0 2050ms=0 2100ms=0 2150ms=0 2200ms=0 2250ms=0 2300ms=0 2350ms=0 2400ms=0 2450ms=0 2500ms=0 2550ms=0 2600ms=0 2650ms=0 2700ms=0 2750ms=0 2800ms=0 2850ms=0 2900ms=0 2950ms=0 30
00ms=0 3050ms=0 3100ms=0 3150ms=0 3200ms=0 3250ms=0 3300ms=0 3350ms=0 3400ms=0 3450ms=0 3500ms=0 3550ms=0 3600ms=0 3650ms=0 3700ms=0 3750ms=0 3800ms=0 3850ms=0 3900ms=0 3950ms=0 4000ms=0 4050ms=0 4100ms=0 4150ms=0 4200ms=0 4250ms=0 4300ms=0 4350ms=0 4400ms=0 4450ms=0 4500ms=0 4550ms=0 4600ms=0 4650ms=0 4700ms
=0 4750ms=0 4800ms=0 4850ms=0 4900ms=0 4950ms=0
Caches:
Current memory usage / total memory usage (bytes):
  TextureCache         14547924 / 49766400
  Layers total          0 (numLayers = 0)
  RenderBufferCache           0 /  4147200
  GradientCache               0 /  1048576
  PathCache                   0 /  8294400
  TessellationCache        4128 /  1048576
  TextDropShadowCache         0 /  4147200
  PatchCache                576 /   131072
  FontRenderer A8        479995 /  1478656
    A8   texture 0       479995 /  1478656
  FontRenderer RGBA           0 /        0
  FontRenderer total     479995 /  1478656
Other:
  FboCache                    0 /        0
Total memory usage:
  16031284 bytes, 15.29 MB

......

使用下面的命令

>adb shell dumpsys gfxinfo com.包名 framestats

Applications Graphics Acceleration Info:
Uptime: 3082762703 Realtime: 7260115919

** Graphics info for pid 26484 [com.yunlian.warehouse_test] **

Stats since: 3076198602841311ns
Total frames rendered: 11282
Janky frames: 194 (1.72%)
50th percentile: 5ms
90th percentile: 10ms
95th percentile: 12ms
99th percentile: 24ms
Number Missed Vsync: 70
Number High input latency: 0
Number Slow UI thread: 154
Number Slow bitmap uploads: 15
Number Slow issue draw commands: 19
HISTOGRAM: 5ms=9076 6ms=149 7ms=195 8ms=405 9ms=328 10ms=342 11ms=206 12ms=119 13ms=114 14ms=80 15ms=48 16ms=31 17ms=12 18ms=18 19ms=4 20ms=14 21ms=15 22ms=6 23ms=5 24ms=7 25ms=8 26ms=5 27ms=6 28ms=4 29ms=2 30ms=3 31ms=0 32ms=8 34ms=5 36ms=3 38ms=5 40ms=1 42ms=4 44ms=4 46ms=4 48ms=6 53ms=4 57ms=5 61ms=6 65ms=
4 69ms=0 73ms=1 77ms=0 81ms=4 85ms=0 89ms=1 93ms=1 97ms=2 101ms=1 105ms=1 109ms=1 113ms=0 117ms=1 121ms=0 125ms=2 129ms=0 133ms=1 150ms=2 200ms=1 250ms=1 300ms=1 350ms=0 400ms=0 450ms=0 500ms=0 550ms=0 600ms=0 650ms=0 700ms=0 750ms=0 800ms=0 850ms=0 900ms=0 950ms=0 1000ms=0 1050ms=0 1100ms=0 1150ms=0 1200ms=0
 1250ms=0 1300ms=0 1350ms=0 1400ms=0 1450ms=0 1500ms=0 1550ms=0 1600ms=0 1650ms=0 1700ms=0 1750ms=0 1800ms=0 1850ms=0 1900ms=0 1950ms=0 2000ms=0 2050ms=0 2100ms=0 2150ms=0 2200ms=0 2250ms=0 2300ms=0 2350ms=0 2400ms=0 2450ms=0 2500ms=0 2550ms=0 2600ms=0 2650ms=0 2700ms=0 2750ms=0 2800ms=0 2850ms=0 2900ms=0 295
0ms=0 3000ms=0 3050ms=0 3100ms=0 3150ms=0 3200ms=0 3250ms=0 3300ms=0 3350ms=0 3400ms=0 3450ms=0 3500ms=0 3550ms=0 3600ms=0 3650ms=0 3700ms=0 3750ms=0 3800ms=0 3850ms=0 3900ms=0 3950ms=0 4000ms=0 4050ms=0 4100ms=0 4150ms=0 4200ms=0 4250ms=0 4300ms=0 4350ms=0 4400ms=0 4450ms=0 4500ms=0 4550ms=0 4600ms=0 4650ms=
0 4700ms=0 4750ms=0 4800ms=0 4850ms=0 4900ms=0 4950ms=0
Caches:
Current memory usage / total memory usage (bytes):
  TextureCache         19596024 / 49766400
  Layers total          0 (numLayers = 0)
  RenderBufferCache           0 /  4147200
  GradientCache               0 /  1048576
  PathCache                   0 /  8294400
  TessellationCache        4128 /  1048576
  TextDropShadowCache         0 /  4147200
  PatchCache                576 /   131072
  FontRenderer A8        479995 /  1478656
    A8   texture 0       479995 /  1478656
  FontRenderer RGBA           0 /        0
  FontRenderer total     479995 /  1478656
Other:
  FboCache                    0 /        0
Total memory usage:
  21079384 bytes, 20.10 MB

• FLAGS

FLAGS列为’0’的行可以通过从FRAME_COMPLETED列中减去INTENDED_VSYNC列计算其总帧时间。
如果非零，则该行应该被忽略，因为该帧的预期布局和绘制时间超过16ms，为异常帧。

• INTENDED_VSYNC
  帧的的预期起点。如果此值与VSYNC不同，是由于 UI 线程中的工作使其无法及时响应垂直同步信号所造成的。

• VSYNC
  花费在vsync监听器和帧绘制的时间（Choreographer frame回调，动画，View.getDrawingTime（）等）
  要了解有关VSYNC的更多信息以及它如何影响应用程序，请查看 Understanding VSYNC视频。

• OLDEST_INPUT_EVENT
  输入队列中最旧输入事件的时间戳，如果没有输入事件，则输入Long.MAX_VALUE。此值主要用于平台工作，对应用程序开发人员的用处有限。

• NEWEST_INPUT_EVENT
  输入队列中最新输入事件的时间戳，如果帧没有输入事件，则为0。此值主要用于平台工作，对应用程序开发人员的用处有限。
  然而，通过查看（FRAME_COMPLETED - NEWEST_INPUT_EVENT），可以大致了解应用程序添加的延迟时间。

• HANDLE_INPUT_START
  将输入事件分派给应用程序的时间戳。通过查看这段时间和ANIMATION_START之间的时间，可以测量应用程序处理输入事件的时间。
  如果这个数字很高（> 2ms），这表明程序花费了非常长的时间来处理输入事件，例如View.onTouchEvent（），也就是说此工作需要优化，或者分发到不同的线程。请注意，某些情况下这是可以接受的，例如发起新活动或类似活动的点击事件，并且此数字很大。

• ANIMATION_START
  运行Choreographer注册动画的时间戳。通过查看这段时间和PERFORM_TRANVERSALS_START之间的时间，可以确定评估运行的所有动画器（ObjectAnimator，ViewPropertyAnimator和常用转换器）需要多长时间。
  如果此数字很高（> 2ms），请检查您的应用是否编写了自定义动画以确保它们适用于动画。
  要详细了解Choreographer，请查看For Butter or Worse 视频。

• PERFORM_TRAVERSALS_START
  PERFORM_TRAVERSALS_STAR-DRAW_START，则可以提取布局和度量阶段完成的时间。（注意，在滚动或动画期间，你会希望这应该接近于零…）要详细了解渲染管道的度量和布局阶段，请查看 Invalidations，Layouts和Performance视频

• DRAW_START
  performTraversals的绘制阶段开始的时间。这是录制任何无效视图的显示列表的起点。
  这和SYNC_START之间的时间是在树中所有无效视图上调用View.draw（）所花费的时间。
  有关绘图模型的更多信息，请参阅硬件加速 或 失效，布局和性能视频

• SYNC_QUEUED
  同步请求发送到RenderThread的时间。这标志着开始同步阶段的消息被发送到RenderThread的时刻。如果此时间和SYNC_START之间的时间很长（> 0.1ms左右），则意味着RenderThread忙于处理不同的帧。在内部，这被用来区分帧做了太多的工作，超过了16ms的预算，由于前一帧超过了16ms的预算，帧被停止了。

• SYNC_START
  绘图的同步阶段开始的时间。
  如果此时间与ISSUE_DRAW_COMMANDS_START之间的时间很长（> 0.4ms左右），则通常表示有许多新的位图必须上传到GPU。
  要了解有关同步阶段的更多信息，请查看 Profile GPU Rendering视频

• ISSUE_DRAW_COMMANDS_START
  硬件渲染器开始向GPU发出绘图命令的时间。
  这段时间和FRAME_COMPLETED之间的时间间隔显示了应用程序正在生产多少GPU。像这样出现太多透支或低效率渲染效果的问题。

• SWAP_BUFFERS
  eglSwapBuffers被调用的时间。

• FRAME_COMPLETED
  帧的完整时间。花在这个帧上的总时间可以通过FRAME_COMPLETED - INTENDED_VSYNC来计算。

• GPU Profile 工具能够很好地帮助你找到渲染相关的问题，但是要修复这些问题就不是那 么简单了。需要结合另一个耗时工具和代码来具体分析，找到性能的瓶颈，并进行优化。在 GPU Profile Render 发现有问题的页面后，可以通过另外一个工具 Hierarchy Viewer 来查看页 面的布局层次和每个 View 所花的时间。