app流畅度测试方法,帧率实时测试工具 _专项测试实战

文章插图
本文为霍格沃兹测试学院学员学习笔记，进阶学习文末加群。
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 机制。

文章插图
VSync机制的绘制
在 FPS Double Buffering 异常情况VSync 机制下 Double Buffering 时 FPS > 手机屏幕刷新率的情况。

文章插图
VSync机制出现double buffering
Display 展示第A 帧数据，CPU/GPU 收到 VSync Pulse 信号马上处理B 帧的数据，但是由于计算太多，导致没有在一个 VSync 间隔内处理完。
由于第B 帧数据没有处理好，Display 继续展示第A 帧数据(此时屏幕显示是异常的) 。由于系统中只存在一块内存给 CPU/GPU 处理绘制，所以在这个 VSync 间隔内cpu 不处理任何事。