24、自动化测试框架：UiAutomator、Espresso、GameBench、自定义帧率采集工具
说到图形性能优化，很多人第一反应是「改代码、调参数」。但说实话，没有一套靠谱的自动化测试体系，你改完代码根本不知道是变好了还是变差了。我见过太多团队，优化完自我感觉良好，结果一上线用户反馈更卡了——就是因为缺少持续的性能监控手段。
这一章，我把工作中最常用的几个自动化测试工具串起来讲。它们各有侧重，但组合起来能覆盖从UI交互到帧率采集的完整链路。
UiAutomator：系统级UI操作的瑞士军刀
UiAutomator是Google官方提供的跨应用UI测试框架。它不依赖应用源码，直接通过AccessibilityService来操作界面元素。说白了，就是模拟人的操作——点击、滑动、长按、输入文本。
我个人习惯用UiAutomator做两种事情：
- 多应用联动的场景测试：比如从微信分享图片到相册，再回到微信查看结果
- 系统设置项的自动化：比如切换深色模式、调整屏幕刷新率、开启性能模式
为什么强调这个？因为很多性能问题只有在特定系统状态下才会复现。你想想看，如果每次手动去设置里翻半天，那效率太低了。
核心用法示例
// 打开开发者选项中的"显示刷新率"
UiDevice device = UiDevice.getInstance();
device.findObject(By.text("开发者选项")).click();
device.findObject(By.text("显示刷新率")).click();
// 验证帧率显示是否开启
UiObject2 fpsToggle = device.findObject(By.res("android:id/switch_widget"));
assertTrue(fpsToggle.isChecked());我的经验：UiAutomator在Android 10以上版本对Compose的支持不太好。如果遇到元素定位失败，试试用By.desc()代替By.text()，因为Compose的contentDescription更稳定。
Espresso：应用内的精准打击
Espresso和UiAutomator最大的区别是——它运行在应用进程内。这意味着它能直接访问Activity、Fragment、View对象，做断言时更精确。
我一般在以下场景用Espresso：
- 单个页面的UI交互验证：比如列表滑动、按钮点击后的状态变化
- 性能基准测试：配合IdlingResource等待异步任务完成，然后测量渲染耗时
这里有个坑，我曾经踩过：
避坑指南：Espresso默认在主线程执行操作，如果你的页面有大量动画或异步加载，一定要实现IdlingResource接口。否则测试会一直等待超时，或者出现「No activities in stage RESUMED」的错误。
// 自定义IdlingResource示例
public class RecyclerViewIdlingResource implements IdlingResource {
private final RecyclerView recyclerView;
private ResourceCallback callback;
public RecyclerViewIdlingResource(RecyclerView recyclerView) {
this.recyclerView = recyclerView;
}
@Override
public boolean isIdleNow() {
boolean idle = recyclerView.getScrollState() == RecyclerView.SCROLL_STATE_IDLE;
if (idle && callback != null) {
callback.onTransitionToIdle();
}
return idle;
}
// ... 其他方法实现
}GameBench：专业级性能分析利器
GameBench不是Google官方的，但它在游戏和图形密集型应用领域几乎是标配。它通过adb连接设备，实时采集帧率、CPU/GPU占用、温度、功耗等数据。
我为什么推荐它？因为它能给出一个综合评分——Stability Index（稳定性指数）。这个指标衡量的是帧率波动情况，比单纯看平均帧率更有价值。
| 指标 | 说明 | 我的建议阈值 |
|---|---|---|
| 平均帧率 | 整个测试周期的FPS均值 | ≥55（60Hz屏幕） |
| 帧率波动 | 相邻帧之间的时间差标准差 | ≤3ms |
| Stability Index | 帧率落在目标范围内的比例 | ≥95% |
| GPU渲染时间 | 每帧GPU处理耗时 | ≤12ms |
使用方式：GameBench通过adb连接设备后，在PC端启动录制。它会生成一个HTML报告，包含帧率曲线、CPU/GPU时间线、温度变化图。我个人习惯把报告归档到CI流水线中，每次构建后自动对比。
自定义帧率采集工具：掌握底层数据
商业工具再好，也有局限性。比如GameBench需要付费授权，而且采集频率固定为每秒一次。如果你需要更细粒度的数据——比如每帧的精确时间戳——就得自己动手了。
我写过一套基于Choreographer的帧率采集工具，核心思路是注册FrameCallback，记录每一帧的回调时间。
public class FpsCollector {
private final Choreographer choreographer;
private final List<Long> frameTimes = new ArrayList<>();
private boolean isCollecting = false;
private final Choreographer.FrameCallback callback = new Choreographer.FrameCallback() {
@Override
public void doFrame(long frameTimeNanos) {
frameTimes.add(frameTimeNanos);
if (isCollecting) {
choreographer.postFrameCallback(this);
}
}
};
public void start() {
isCollecting = true;
choreographer.postFrameCallback(callback);
}
public void stop() {
isCollecting = false;
}
public double getAverageFps() {
if (frameTimes.size() < 2) return 0;
long first = frameTimes.get(0);
long last = frameTimes.get(frameTimes.size() - 1);
long durationMs = (last - first) / 1_000_000;
return (frameTimes.size() - 1) * 1000.0 / durationMs;
}
}注意：Choreographer的回调是在UI线程执行的。如果你的UI线程被阻塞，回调会延迟，导致采集到的帧率偏低——但这恰恰是我们想捕捉的问题。我曾经用这个工具抓到一个第三方SDK在主线程做I/O操作的bug，帧率直接从60掉到20。
知识体系总览
下面这张图概括了本章的核心内容。你可以看到四个工具分别覆盖了不同的测试维度：
如何组合使用？
在实际项目中，我通常这样搭配：
- CI流水线阶段：用Espresso跑核心页面的UI测试，同时通过自定义帧率采集工具记录帧率。如果平均帧率低于50或出现连续丢帧，构建失败。
- 回归测试阶段：用UiAutomator模拟用户操作路径（比如从首页到详情页再返回），同时用GameBench录制整个过程的性能数据。
- 问题定位阶段：当GameBench报告显示某个场景帧率异常时，用自定义工具采集更细粒度的数据，配合Systrace定位具体卡顿点。
关键点：自动化测试不是为了替代人工，而是把「每次都要手动验证」变成「每次构建自动验证」。我见过一个团队，把帧率阈值写进CI后，三个月内拦截了7次性能回退——这在以前根本不可能发现。
嗯，工具就介绍到这里。记住一点：没有银弹。UiAutomator、Espresso、GameBench、自定义工具各有适用场景，关键是根据你的项目特点选择合适的组合。我个人的建议是——先跑通一个最简单的帧率采集脚本，再逐步叠加其他工具。别一开始就想搞大而全的框架，容易把自己绕进去。