相机性能基准测试：四大维度全面解析
做相机性能优化，最怕什么？
怕你改了一堆代码，自我感觉良好，结果一跑测试，延迟反而高了。或者功耗降了，但帧率掉成幻灯片。
所以，基准测试不是可选项，是必选项。今天我就把这四类测试掰开揉碎了讲清楚。
一、Camera ITS 测试：合规性的底线
Camera ITS，全称是 Camera Image Test Suite。这是 Google 官方推出的测试套件，专门用来验证相机 HAL 和框架是否符合 CTS 要求。
说白了，这就是一道门槛。你过不了 ITS，手机就别想上市。
ITS 测试覆盖哪些内容？
- 图像质量：色彩还原、噪点、动态范围
- 传感器特性：灵敏度、曝光时间准确性
- 3A 稳定性：AE、AF、AWB 的收敛速度
- 多帧合成：HDR、夜景模式的帧对齐
我记得有一次，某款新平台的 ITS 测试死活过不了。查了三天，最后发现是 sensor 的增益映射表写错了。嗯，这种坑，踩过一次就记住了。
我的习惯：每次改完 HAL 层代码，先跑一遍 ITS 的 subset。别等全部改完再跑，否则问题堆在一起，定位成本翻倍。
三、延迟基准测试：用 OpenCamera 抓痛点
延迟，是用户最直接的感知。你按下快门，半秒后才听到咔嚓声，用户直接卸载 App。
OpenCamera 是个开源工具，我特别喜欢用它来做延迟测试。为什么？因为它能精确控制每一帧的请求和回调时间。
延迟测试主要看三个指标：
- 快门延迟：从按下按钮到 sensor 开始曝光的时间
- 处理延迟：从 RAW 数据到输出 JPEG 的时间
- 显示延迟：从 JPEG 生成到屏幕显示的时间
我曾经在一个项目里发现，处理延迟占了总延迟的 70%。后来定位到是 JPEG 编码器用了软件方案，换成硬件编码器后，延迟直接砍半。
注意：OpenCamera 的延迟数据受 CPU 频率影响很大。测试前务必锁频，否则数据波动会让你怀疑人生。
三、功耗基准测试：PC Mark 的实战价值
功耗优化，是相机团队和硬件团队吵架最多的地方。你想想看，相机一开，CPU、ISP、DSP、GPU 全在跑，功耗能不高吗？
PC Mark 的 Work 2.0 电池测试，是我最常用的工具。它模拟真实用户场景，包括拍照、录像、浏览图片等。
| 测试场景 | 典型功耗（mW） | 优化目标 |
|---|---|---|
| 预览模式（30fps） | 350-500 | ≤400 |
| 拍照（单帧） | 800-1200 | ≤900 |
| 录像（1080p 30fps） | 600-900 | ≤700 |
| HDR 多帧合成 | 1200-1800 | ≤1400 |
我个人习惯，在跑 PC Mark 之前，先用 perf 工具抓一下各个模块的占用率。如果 ISP 占用率超过 60%，那功耗大概率下不来。
避坑指南：我曾经遇到过，PC Mark 跑出来的功耗数据比实际低 20%。后来发现是测试时屏幕亮度被系统自动调低了。所以，测试前一定要固定屏幕亮度、关闭自动调节。
四、帧率稳定性测试：别让用户感觉到卡顿
帧率稳定性，比平均帧率更重要。你平均 30fps，但每 10 帧里掉 2 帧到 15fps，用户照样觉得卡。
我常用的方法是，用 dumpsys 或者 systrace 抓取每一帧的到达时间，然后计算帧间隔的抖动。
帧率稳定性指标：
- 平均帧率：≥ 目标帧率的 95%
- 帧间隔标准差：≤ 5ms
- 掉帧率：掉帧数 / 总帧数 ≤ 1%
为什么会掉帧？最常见的原因是 CPU 频率切换。你想想看，系统为了省电，把 CPU 降频了，结果相机线程没抢到时间片，帧就丢了。
我解决这个问题的方法，是在相机启动时，通过 setThreadPriority 把关键线程的优先级提到最高，同时用 cpufreq 锁定最低频率。
核心思路：帧率稳定性，本质上是资源调度问题。你给相机线程足够的 CPU 时间，它就不会掉帧。
知识体系总览
下面这张图，把这四类测试的关系梳理清楚了。你可以把它当作一个检查清单，每次做性能优化时，对着跑一遍。
这四类测试，不是做完一次就完事了。每改一次代码，每调一次参数，都应该跑一遍。尤其是 ITS 和帧率测试，最容易在优化功耗时被破坏。
好了，这一章的内容就到这里。下一章，我会深入讲延迟分析的具体工具和方法，包括怎么用 systrace 抓取每一帧的时间戳。
公众号:蓝海资料掘金营，微信deep3321