专项测试实战 | 如何测试 App 流畅度（基于 FPS 和丢帧率）
本文为霍格沃兹测试学院学员学习笔记，进阶学习文末加群。
FPS 和丢帧率可以在一定程度上作为 APP 流畅度的一项衡量标准，本文介绍利用 adb shell dumpsys gfxinfo 命令获取软件渲染加载过程的数据，进行计算从而获取测试结果。
前置业务知识
在此之前，需要先了解屏幕展示绘制过程及 Android 的 VSync 机制
VSync 全称是 Vertical Synchronization（垂直同步），在 Android 4.1 中引入 Android 系统（同时引入的一个概念是 Triple Buffering）。
学计算机的经常听到 Buffer 的概念（生活中也碰到过很多），起到的都是一个类似的作用。用来协调两个不同速度的东西工作。
举个实例，假设显示内容和绘制使用的是用一块内存，那可能会出现下面的问题。显示有截断的异常（图中的Tear Point #1和Tear Point #2）。
为什么会这样呢？因为 CPU/GPU 处理和屏幕展示的速度不一样但是却使用的是同一块内存。
怎么解决呢？可以将 CPU/GPU 处理和屏幕展示分开，CPU/GPU 在后台处理，处理完一帧的数据以后才交给屏幕展示(这样可能导致另外的问题是，如果 CPU/GPU 处理很慢，那么屏幕可能会一直展示某一帧的数据，下面主要分析这个问题的处理)。
绘制过程中的两个概念
手机屏幕刷新率是固定的，FPS 则是一直变化的，怎么才能保证能够运行流畅呢？从几个例子来看吧。
先解释图片代表的意思：最下面黑线代表的是时间，黄色代表屏幕展示，绿色代表 GPU 处理，蓝色代表 CPU 处理。Jank 代表的是重复展示上一帧的异常。下面会从屏幕展示的每一帧开始分析：
没有引入 VSync 机制
上图是没有引入VSync 机制的处理流程。
引入 VSync 机制
VSync 可以简单的认为是一种定时中断，系统在每次需要绘制的时候都会发送VSync Pulse 信号，CPU/GPU 收到信号后马上处理绘制。
正常情况
在4.1以后引入VSync 机制。
在 FPS < 手机屏幕刷新率的情况下，一切运行完美。
Double Buffering 异常情况
VSync 机制下 Double Buffering 时 FPS > 手机屏幕刷新率的情况。
Triple Buffering 异常情况
Triple Buffering 的引入。
获取数据并计算结果
1.运行命令"adb -s " + deviceName + " shell dumpsys gfxinfo " + packageName 获取基础数据，我们会获得很多数据，这里截取需要进行分析的部分：
注：如果运行完命令发现无上图中的4个参数，则很可能是手机的“GPU呈现模式分析”未打开；
在手机的开发者选项中，找到“GPU呈现模式分析”，选择“在adb shell dumpsys gfxinfo中”，如果是华为或荣耀的手机，则选择“在屏幕上显示为线型图”：
2.如上图信息表示了每一帧在安卓系统中的四个阶段：
说明
Android 定义了流畅度的数据标准，以 60FPS 为标准（FPS 为每秒绘制的帧数），帧数过小就会出现卡顿感。
每一帧在安卓系统中分4个阶段,4个阶段的总和超过16.67（1秒60帧,算下来平均1帧的间隔就约是16.67ms）就认为丢帧。
这个定义在 Android6.0 以前是一定的,但是现在已经没有固定的标准了，因为目前安卓系统有3层缓存机制,加上硬件上的进步,即使超过16.67,也不一定会出现卡顿感。所以这个数据在测试时作为一种对比和相对衡量标准，也可根据需求自定义标准。
计算结果
通过以上数据，就可以获取到每一帧的时间、总帧数；从而就可以计算出 jank 数、vsync 数，进而就可以得到最终的 FPS 和丢帧率数据。
当然，手工计算无疑效率低，出错率大，所以这里的计算过程最好还是以脚本形式，让代码帮我们去计算，具体代码计算原理与专项自动化过程后续探讨。
