Android流畅度之帧率

背景：app改版，人为感受卡顿，需要客观数据支撑观点。故，搜索各种性能指标，并理解之。（这是一篇摘要文......）

首先，明确人为感受的性能不好属于下面哪种：

1. 响应时间，界面跳转后响应时间；

2. 流畅度，界面操作时或动画展示的效果；

而流畅度的衡量指标又有几种：

1. 帧率fps（Frames Per Second，每秒钟填充图像的帧率）

2. 丢帧SF（Skipped frame）

3. 流畅度SM（SMoothness）（腾讯分享）

其中得到最广泛使用的还是帧率。以下详细说明之

 

回顾本源：Android如何绘制UI？

参考：显示性能指标、性能评测调优

说实话，这里看的不甚懂，主要理解了垂直同步机制。

每隔1个VSync间隔，Android会发起一次中断，GPU/CPU就会处理新一帧的数据，处理每帧数据的时间必定为VSync间隔的整数倍；即使GPU/CPU可处理的帧数更多最终也会保持和Android显示系统一致；而如果GPU/CPU可处理的帧数少于60，则会出现掉帧的情况，即人为感知每帧图像之间的不连贯。

基于此种情况，还出现了三缓存，注意下图中的C，在空闲时先处理了C，在之后的某个时间放到屏幕上。

补充关于双缓存与surface关系参考：Android UI呈现

• 双缓冲在图像处理上非常重要，它的工作原理是：先把需要呈现的所有元素都画
• 在一张图上（第一层），再把这张图整个投放到屏幕上去（第二层）。
• surface就相当于第一层，所有元素都要先在Surface上画，每个window对应一个Surface
• surface处理也存在MVC三层结构：
• 
• SurfaceFlinger：Android系统的一个服务，用来生成Surface，管理帧缓冲区，实际做的事儿就是：把不同z坐标的Window按顺序排放，将所有的window合成一张图，也就是一帧

帧率值在什么范围可认定为流畅？

理想状态每秒展示60帧时人眼感受不到卡顿，1000ms/60帧，即每帧绘制时间不应超过16.67ms。

帧率如何计算？

搜索相关文章，帧率的计算大致分为以下两种。

• adb shell dumpsys gfxinfo <PACKAGE_NAME> 参考：Testing Display Performance
• adb shell dumpsys SurfaceFlinger --latency <window_activity> 参考：Android性能测试之fps获取

 二者的区别是什么？

参考：FPS计算方法比较

这是需要重点了解的功能，部门原已采用gfxinfo获取相关数据，但网搜到后期数据处理多是基于SurfaceFlinger 的数据。导致研究发现数据处理方法对不上，实则忽略了二者的区别。

gfxinfo：

• 记录最近128帧的绘制时间，每帧不同阶段（网搜大部分文章只有3个阶段，实则在Android系统升级过程，已增加，详见官网）的时间相加，不超过16.67ms就是流畅的；
• 若停止不动，app内部也没有刷新处理屏幕的需求，会输出0，有时未开始滑动会直接没有数据输出；
• 以上导致了如果app内部也没有刷新处理屏幕的需求，很流畅，但由于实际每秒处理的帧数不多，fps的值可能也会很少；

SurfaceFlinger：

• 实际记录127帧数据，第一行标明VSync间隔，一般为16666666/1000/1000 = 16.67ms(毫秒)；
• 保持不动，会一直输出上一帧的数据；
• 最终帧率的计算为期间帧数/时间，int(round((frame_count-1)/ seconds))，详情参考：Android性能测试之fps获取

FPS是否能充分衡量app的流畅度？

 算出FPS了，这个单纯的数据能够代表流畅度么？关于这点，很多资料中也有质疑。由于Android自带adb测试性能命令，输出一个阶段的帧绘制耗时，多次测试获得多个曲线，不能简单求均值获得概括数据。有资料是建议使用 掉帧率 来衡量。

利用 处理帧数 / （处理帧数 + 额外的垂直同步脉冲） * 60 计算，其中处理帧数常为128

实测补充说明：

• 前提需要打开设置中的GPU绘制选项
• 记录过程冷启动（杀进程），则之前的数据丢失
• 获取数据不难，后期如何理解数据，利用这些数据，建立数学模型是比较重要的。

附录：实际获得的gfxinfo数据：其实后五项的数据意义还不太清晰，求指教，为什么求和之后不等于janky frames