vlambda博客
学习文章列表

流畅视觉：行云流水，一气呵成；

非流畅视觉：“卡顿”、“抖动”、“迟钝感”；

而对开发者来说，FPS通常作为衡量应用是否流畅的标准。

一、FPS是什么？

FPS即Frames per Second（每秒显示的帧数），用于测量显示帧数的度量。帧数为0说明页面处于静止，只要页面动起来，这个帧数就会有变化，然后再趋于静止，页面滚动起来帧数整体呈现“非对称”抛物线走势。接下来看一张图直观感受一下：

通过上图我们能看出FPS值的大小对画面流畅度的影响，每一帧都是静止的图像，快速连续地显示帧便形成了运动的假象，因此高帧率可以得到更流畅、更逼真的动画。

二、何为帧延迟？卡顿如何造成的？

帧延迟的高低可以通过帧时间（Frame Time）来判定。我们参考显示器的60Hz刷新率进行计算，它意味着每秒刷新60帧，每帧大约用时16.7毫秒。画面中每帧生成时间如果与16.7毫秒很接近，那么全程画面的帧数就很稳定，更接近理想的60帧每秒。

计算公式：1000ms / 60 frames ≈ 16.67 ms/frames

如果每帧生成时间高于16.7毫秒，也就意味着渲染这一场景所花费的时间比其他帧更多，造成画面跟不上，进而带来显示卡顿。

举一个简单的例子，我们看到的早期动画片其实就是用一张张手绘图片连贯翻页制作而成的。当一张张独立图片切换速度足够快时，我们的眼睛就会以为这是连续的动作。反之，当图片切换速度不够快时，就会被人眼看出破绽，相应的视觉体验就是卡顿。

三、如何进行应用帧率测试

测试需求

• 通过技术手段量化程序卡顿程度，过程数据可视化

• 多平台机型适配，方案不能依赖root

• 不能有Android的API版本限制（因为需要兼容多个系统版本）

• 监控流程可自动化执行

• 过程需要连续可靠

获取FPS的可行性方案

在查阅了很多的资料，也学习了同行前辈们的各种记录后，我根据自己需要将可行性方案的范围缩小到三种。

• 方案一
  通过 [设置]->[开发者选项]->[GPU呈现模式分析] ->[在屏幕上显示为条形图] 进行直观的取样，截图如下：
  

设置完成后的效果是这样的：

屏幕下方的柱形图会持续刷新，最上方会有一根绿色的线，代表的是16ms的阈值，超过这个界限表示当前帧绘制的时间出现了延迟，及卡顿现象，后面会详细介绍原因。横坐标表示时间的持续，每一根柱形图表示当前帧的绘制时间。因此我们在使用的过程中，下面的柱形图会一直的刷新，单位是ms。各位看官是否有注意到每一帧的柱形图颜色不一样呢（注：不同手机的颜色不一样，仅限安卓4.0以上版本参考）？下图是官网提供的比较典型的GPU渲染卡顿的例子：

绘制过程中的不同颜色具有不同的含义，详细解释请移步>> 官网 查看更多。

那么是不是说我只需要打开界面去数一下超过绿色阈值的柱状图有多少就可以观察我们应用的流畅度了？然而并没有，因为这个方式获取到的渲染时间只是UI主线程上的绘制行为，目前我所接手的项目，采用的方式是捕捉相机的数据然后放到GPU中去进行绘制，有单独的绘制线程，单独的视图，所以这个方案并不适合我手上的项目。

• 方案二

1.保证手机与PC连接是正常的

2.打开手机“设置”→“开发者选项”（没有开发者选项就点击“关于手机”“版本号”连续点击就会出现开发者选项了）。找到监控一栏点击“GPU更显模式分析”→勾选上“dab shell dumpsys gfxinfo”

3.在PC上win+R进入运行，输入cmd，回车。把手机停放在被测软件上

在命令行中输入adb shell "dumpsys window|grep mCurrentFocus之后会显示app的名字，只记住从com开始到“/”结束的名字就行了

4.打开被测app进行滑动页面，结束后在，命令行中输入adb shell dumpsys gfxinfo app的包名 >FPS.txt 回车，页面无任何提示则为成功

5.打开“计算机”C:\Users\admin\fps.txt,

打开fps.txt文件，移动到显示很多数字的地方（如下图）可以把这些数据复制到Excel表中，绘制成图标方便观察

Draw:      表示在Java中创建显示列表部分中，OnDraw()方法占用的时间。

Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长

Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间。

Draw + Process + Execute = 完整显示一帧 ，这个时间要小于16ms才能保存每秒60帧。

从图中看出，这个APP的流畅度还是不错的，帧率控制在了16ms左右，超过的话就需要对APP进一步的优化了。

7月份福利课来袭，心动就关注一下吧~