专项测试实战 | 如何测试 App 流畅度(基于 FPS 和丢帧率)?

举报
霍格沃兹测试开发学社 发表于 2022/05/15 17:40:55 2022/05/15
【摘要】 FPS 和丢帧率可以在一定程度上作为 APP 流畅度的一项衡量标准,本文介绍利用 adb shell dumpsys gfxinfo 命令获取软件渲染加载过程的数据,进行计算从而获取测试结果。在此之前,需要先了解屏幕展示绘制过程及 Android 的 VSync 机制VSync 全称是 Vertical Synchronization(垂直同步),在 Android 4.1 中引入 Andr...


FPS 和丢帧率可以在一定程度上作为 APP 流畅度的一项衡量标准,本文介绍利用 adb shell dumpsys gfxinfo 命令获取软件渲染加载过程的数据,进行计算从而获取测试结果。
在此之前,需要先了解屏幕展示绘制过程及 Android 的 VSync 机制
VSync 全称是 Vertical Synchronization(垂直同步),在 Android 4.1 中引入 Android 系统(同时引入的一个概念是 Triple Buffering)。
学计算机的经常听到 Buffer 的概念(生活中也碰到过很多),起到的都是一个类似的作用。用来协调两个不同速度的东西工作。
为什么会这样呢?因为 CPU/GPU 处理和屏幕展示的速度不一样但是却使用的是同一块内存。
怎么解决呢?可以将 CPU/GPU 处理和屏幕展示分开,CPU/GPU 在后台处理,处理完一帧的数据以后才交给屏幕展示(这样可能导致另外的问题是,如果 CPU/GPU 处理很慢,那么屏幕可能会一直展示某一帧的数据,下面主要分析这个问题的处理)。

  • 手机屏幕刷新率:手机硬件每秒刷新屏幕的次数,单位 HZ。一般是一个固定值,例如 60HZ。
  • FPS:画面每秒传输帧数,通俗来讲就是指动画或视频的画面数。单位 HZ。
    手机屏幕刷新率是固定的,FPS 则是一直变化的,怎么才能保证能够运行流畅呢?从几个例子来看吧。
    先解释图片代表的意思:最下面黑线代表的是时间,黄色代表屏幕展示,绿色代表 GPU 处理,蓝色代表 CPU 处理。Jank 代表的是重复展示上一帧的异常。下面会从屏幕展示的每一帧开始分析:

上图是没有引入VSync 机制的处理流程。

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

在 FPS < 手机屏幕刷新率的情况下,一切运行完美。
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 的引入。
  • Display 展示第A 帧数据,CPU/GPU 收到VSync Pulse 信号马上处理B 帧的数据,但是由于计算太多,导致没有在一个VSync 间隔内处理完。
    由于第B 帧数据没有准备好,Display 继续展示第A 帧数据(此时屏幕显示是异常的)。此时虽然B 被gpu 在使用,但是cpu 可以处理Buffer C(因为有3个缓冲)。
  • Display 展示第B 帧数据,gpu 继续处理上一步骤的C,cpu 则处理A。
    后续过程出错的情况被降低了…
    1.运行命令"adb -s " + deviceName + " shell dumpsys gfxinfo " + packageName 获取基础数据,我们会获得很多数据,这里截取需要进行分析的部分:
    注:如果运行完命令发现无上图中的4个参数,则很可能是手机的“GPU呈现模式分析”未打开;
    2.如上图信息表示了每一帧在安卓系统中的四个阶段:
  • 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 和丢帧率数据。
    当然,手工计算无疑效率低,出错率大,所以这里的计算过程最好还是以脚本形式,让代码帮我们去计算,具体代码计算原理与专项自动化过程后续探讨。

原文链接
哈喽,喜欢这篇文章的话烦请点个赞哦!万分感谢~(^▽^)PS:有问题可以联系我们哦~v ceshiren001
获取更多技术文章分享: https://qrcode.ceba.ceshiren.com/link?name=article&project_id=qrcode&from=hwyun&timestamp=1652607606
)

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。