shell 脚本通过 dumpsys SurfaceFlinger --latency 数据计算 FPS 和评价流畅度。

目录

前言：

开篇前述：

一、设计初衷

二、设定预期倒推查找解决方案

设计实现部分

一、确定数据来源原因（dumpsys SurfaceFlinger --latency）

二、根据需求确定计算规则

三、代码实现

四、监控数据可视化交互结果设计

---

前言：

在 Android App 的持续集成测试中，流畅度是一个非常重要的指标，它表示应用程序的运行流畅程度。流畅度的评价通常可以通过监控应用程序的 CPU、内存、GPU 等资源的使用情况来进行评价。 

开篇前述：

由于采购机械臂测试性能用例和屏幕实际帧率变化，最终工具方案实现后搁置，拿出来” 晒晒 “。

一、设计初衷

1、面临用户和公司内领导试用中反馈的卡顿问题，思考如何能有效量化评估？
2、如何在尝试复现卡顿的过程中持续监控 FPS 和丢帧情况？

二、设定预期倒推查找解决方案

1、无 root 权限限制，可直接采集数据计算 FPS、丢帧率、最大单帧间隔。
2、控制脚本影响，不要使监控脚本成为 “负担”。
3、数据获取灵活，即可控制台实时输出数据，也可以后台长时间监控。
4、设计评价得分标准，可按：百分比 * 用例单项评分量化每条用例，从而计算总分使用。

设计实现部分

参考了网上现有的 FPS 计算方式原理，绕来绕去也没有满足自己的预期需求，索性自己从数据源出发自己设计脚本计算逻辑处理。参考如下​
用第三方库 (surface_stats_collector.py) 获取 AndroidFPS 过程分析 (用第三方库 (surface_stats_collector.py) 获取 AndroidFPS 过程分析 · TesterHome)
如何准确评测 Android 应用的流畅度？ (http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=75&extra=page%3D1)

一、确定数据来源原因（dumpsys SurfaceFlinger --latency）

1、可以清零重新记录，避免如何分清哪些数据是上次的。（dumpsys SurfaceFlinger --latency-clear）
2、按 window 获取数据，可以配合手工操作逐一获取每个 case 的流畅度。
3、历史记录 127 行数据，按 60 帧算可记录 2.12S 数据，从而不用频繁获取。（最终考虑设定 1.6S 间隔刷新数据。）

二、根据需求确定计算规则

1、有刷新则计算帧率，无刷新则不输出数据。
原因：
（1）要做成监控指定窗口流畅度的功能，所以要控制无意义数据。
（2）配合手工操作，静置状态不输出，操作停止后直接刷新数据，从而使数据和操作对应。
2、间隔 500ms 以上则判定为操作延迟，每到间隔 500ms 情况发生重新计算帧率。
原因：
（1）一般做 monkey 压力测试设置的是 500ms 间隔
（2）一般用户操作频率间隔是大于 500ms 情况
3、每次采样数据大于等于 1 帧则计算 FPS，丢帧率，最大帧间隔。
原因：帧数/总耗时=帧率，所以无论有多少帧都可以直接计算
4、设定流畅度评价规则：
（1）满足 KPI 帧率则达成一半需求，占比 50%
（2）小于 KPI 单帧耗时比例评价画面变化是否稳定，占比 40%
（3）单帧渲染峰值代表瞬时卡顿最大影响，占比 10%
5、代码实现过程中遇到一坑：SurfaceFlinger 中同一帧存在间隔复用情况，即相同一行数据间隔几帧出现两次。（通过监控微信红包点击后的弹出框的帧率发现的。）
补充规则：发生两帧同步时间做差小于第一行帧刷新周期，则总时间 + 帧刷新周期，上一帧数据=前一帧同步时间 + 帧刷新周期，总帧数 +1

三、代码实现

#!/system/bin/sh

show_help() {
echo "
Usage: sh fps.sh [ -t target_FPS ] [ -w monitor_window ] [ -k KPI ] [ -f csv_path ] [ -h ]

Show: FU(s) LU(s) Date FPS Frames jank MFS(ms) OKT SS(%)

    FU(s): Uptime of the first frame.
    LU(s): Uptime of the last frame.
    Date: The date and time of LU.