如何测试 App 流畅度（基于 FPS 和丢帧率）？

lsekfe

　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 处理很慢，那么屏幕可能会一直展示某一帧的数据，下面主要分析这个问题的处理)。
　　绘制过程中的两个概念。
　　· 手机屏幕刷新率：手机硬件每秒刷新屏幕的次数，单位 HZ。一般是一个固定值，例如 60HZ。
　　· FPS：画面每秒传输帧数，通俗来讲就是指动画或视频的画面数。单位 HZ。
　　手机屏幕刷新率是固定的，FPS 则是一直变化的，怎么才能保证能够运行流畅呢？从几个例子来看吧。
　　先解释图片代表的意思：最下面黑线代表的是时间，黄色代表屏幕展示，绿色代表 GPU 处理，蓝色代表 CPU 处理。Jank 代表的是重复展示上一帧的异常。下面会从屏幕展示的每一帧开始分析：
　　没有引入 VSync 机制

上图是没有引入VSync 机制的处理流程。
　　Display 展示第0帧数据，这时 CPU/GPU 会去处理第1帧的数据。
　　Display 展示第1帧数据(此时屏幕显示是正常的)，这时 CPU/GPU 可能处理其他任务导致很晚才去处理绘制。
　　因为 CPU/GPU 没处理好第2帧的数据，所以 Display 还是展示第1帧数据(此时屏幕显示是异常的)，CPU/GPU 处理完第2帧没有处理完的数据然后继续处理第3帧的数据。
　　…
　　上图中一个很明显的问题是，只要一次 CPU/GPU 处理出现异常就可能导致后面的一系列的处理出现异常。
　　引入 VSync 机制
　　VSync 可以简单的认为是一种定时中断，系统在每次需要绘制的时候都会发送VSync Pulse 信号，CPU/GPU 收到信号后马上处理绘制。
　　正常情况
　　在4.1以后引入VSync 机制。

　在 FPS < 手机屏幕刷新率的情况下，一切运行完美。
　　Double Buffering 异常情况
　　VSync 机制下 Double Buffering 时 FPS > 手机屏幕刷新率的情况。

Display 展示第A 帧数据，CPU/GPU 收到 VSync Pulse 信号马上处理B 帧的数据，但是由于计算太多，导致没有在一个 VSync 间隔内处理完。
　　由于第B 帧数据没有处理好，Display 继续展示第A 帧数据(此时屏幕显示是异常的)。由于系统中只存在一块内存给 CPU/GPU 处理绘制，所以在这个 VSync 间隔内cpu 不处理任何事。
　　Display 展示第 B 帧数据，CPU/GPU 收到 VSync Pulse 信号马上处理即将展示A 帧的数据，由于计算太多，导致没有在一个 VSync 间隔内处理完。
　　需要展示的A 帧数据没有处理好，Display 继续展示第 B 帧数据(此时屏幕显示是异常的)。由于系统中只存在一块内存给 CPU/GPU 处理绘制，所以在这个 VSync 间隔内 CPU 不处理任何事。
　　…
　　上图中一个很明显的问题是，只要出现一次Jank 就会影响下一次的VSync(cpu 不能工作)。
　　Triple Buffering 异常情况
　　Triple Buffering 的引入。

Display 展示第A 帧数据，CPU/GPU 收到VSync Pulse 信号马上处理B 帧的数据，但是由于计算太多，导致没有在一个VSync 间隔内处理完。
　　由于第B 帧数据没有准备好，Display 继续展示第A 帧数据(此时屏幕显示是异常的)。此时虽然B 被gpu 在使用，但是cpu 可以处理Buffer C(因为有3个缓冲)。
　　Display 展示第B 帧数据，gpu 继续处理上一步骤的C，cpu 则处理A。
　　后续过程出错的情况被降低了…
　　获取数据并计算结果
　　运行命令"adb -s " + deviceName + " shell dumpsys gfxinfo " + packageName 获取基础数据，我们会获得很多数据，这里截取需要进行分析的部分：

　注：如果运行完命令发现无上图中的4个参数，则很可能是手机的“GPU呈现模式分析”未打开；
　　在手机的开发者选项中，找到“GPU呈现模式分析”，选择“在adb shell dumpsys gfxinfo中”，如果是华为或荣耀的手机，则选择“在屏幕上显示为线型图”：

如上图信息表示了每一帧在安卓系统中的四个阶段：
　　· Draw:表示在Java中创建显示列表部分中，OnDraw()方法占用的时间
　　· Prepare:准备时间
　　· Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长
　　· Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间，其实是实际显示帧数据的后台缓存区与前台缓冲区交换后并将前台缓冲区的内容显示到屏幕上的时间
　　将上面的四个时间加起来就是绘制一帧所需要的时间，如果超过了16.67就表示掉帧了。
　　说明
　　Android 定义了流畅度的数据标准，以 60FPS 为标准(FPS 为每秒绘制的帧数),帧数过小就会出现卡顿感。
　　每一帧在安卓系统中分4个阶段,4个阶段的总和超过16.67(1秒60帧,算下来平均1帧的间隔就约是16.67ms)就认为丢帧。
　　这个定义在 Android6.0 以前是一定的,但是现在已经没有固定的标准了，因为目前安卓系统有3层缓存机制,加上硬件上的进步,即使超过16.67,也不一定会出现卡顿感。所以这个数据在测试时作为一种对比和相对衡量标准，也可根据需求自定义标准。
　　计算结果
　　通过以上数据，就可以获取到每一帧的时间、总帧数；从而就可以计算出 jank 数、vsync 数，进而就可以得到最终的 FPS 和丢帧率数据。
　　当然，手工计算无疑效率低，出错率大，所以这里的计算过程最好还是以脚本形式，让代码帮我们去计算，具体代码计算原理与专项自动化过程后续探讨。