一、Camera调试与测试全景图
做Camera系统这么多年，我最大的体会就是：调试和测试占了整个开发周期的一半以上。你想想看，硬件千差万别，传感器型号五花八门，ISP参数调来调去，不出问题才怪。
所以这一章，我打算把Camera调试与测试的看家本领都掏出来。从CTS/ITS认证测试，到CameraTrace、Systrace这些性能分析工具，再到常见问题的定位思路和Log分析技巧，咱们一条一条捋清楚。
核心观点：调试不是瞎试，测试不是走过场。掌握系统化的方法，才能从“调参侠”进化成“Camera专家”。
二、CTS/ITS测试——Camera的“高考”
2.1 CTS测试到底测什么
CTS，全称Compatibility Test Suite。说白了，就是Google给Android设备设的“高考分数线”。你的Camera如果不通过CTS，那GMS（Google Mobile Services）就别想了。
我个人习惯把CTS Camera相关的测试项分成三类：
- 基础功能测试：打开/关闭Camera、预览、拍照、录像这些基本操作能不能正常跑。
- 参数验证测试：比如AE（自动曝光）、AWB（自动白平衡）、AF（自动对焦）的收敛速度和精度。
- 稳定性测试：反复打开关闭Camera，长时间录像，看会不会崩溃或者内存泄漏。
小技巧：跑CTS之前，先手动把Camera的基本功能过一遍。我曾经遇到过CTS跑了一晚上，结果第二天发现是预览画面是黑的——白白浪费8个小时。
2.2 ITS测试——图像质量的“照妖镜”
ITS（Image Test Suite）比CTS更狠。它不关心你的功能能不能用，它只关心你拍出来的照片好不好看。
ITS测试需要特定的测试环境：
- 标准光源箱（D65、A光源、TL84等）
- 测试chart（ISO 12233分辨率卡、ColorChecker色卡、灰阶卡等）
- 固定的拍摄距离和角度
ITS主要测这些指标：
| 测试项 | 描述 | 常见问题 |
|---|---|---|
| 分辨率 | MTF（调制传递函数）曲线 | 边缘模糊、细节丢失 |
| 色彩还原 | ColorChecker各色块的ΔE | 偏色、饱和度异常 |
| 噪点 | 亮度噪点和色度噪点 | 暗光下噪点过多 |
| 动态范围 | 高光到阴影的细节保留 | 高光过曝或暗部死黑 |
| 畸变 | 镜头几何畸变 | 画面桶形/枕形畸变 |
注意：ITS测试对环境光极其敏感。有一次我调了一周的3A参数，结果ITS一直不过，最后发现是光源箱的灯管老化了。换了个灯管，一次通过。
三、CameraTrace——给Camera“把脉”
3.1 CameraTrace是什么
CameraTrace是Android原生提供的一个性能追踪工具。它会在Camera HAL、Framework、App层的关键路径上埋下trace点，记录每一帧从Sensor曝光到最终显示的全链路耗时。
说白了，它就是Camera系统的“心电图”。哪一段慢了，哪一段卡了，一目了然。
3.2 怎么用CameraTrace
启用CameraTrace很简单：
// 开启CameraTrace
adb shell setprop persist.camera.trace.enable 1
adb shell setprop persist.camera.trace.mask 0xFF
// 重启Camera服务
adb shell killall cameraserver
// 抓取trace
adb shell atrace --async_start -c -b 40960 camera hal
// ... 操作Camera ...
adb shell atrace --async_dump > /data/local/tmp/camera_trace.txt
我的习惯：我会把trace mask设成0xFF，把所有层级的trace都打开。虽然数据量大一点，但排查问题的时候信息更全。等找到问题点，再缩小范围。
3.3 读懂CameraTrace的关键指标
拿到trace文件后，我一般先看这几个时间戳：
- Sensor Exposure Start → End：曝光时间。如果太长，说明暗光下帧率上不去。
- ISP Processing：ISP处理时间。这里容易出问题，比如降噪算法太耗时。
- HAL → Framework：数据从HAL层传到Framework层的延迟。如果这里卡顿，多半是Binder传输的问题。
- App Display：从Framework到App显示的时间。这里慢的话，用户会感觉预览卡顿。
正常来说，30fps的预览，每一帧的总耗时不能超过33ms。超过这个数，画面就会掉帧。
四、Systrace——系统级的“显微镜”
4.1 Systrace和CameraTrace的区别
CameraTrace是Camera专用的，Systrace是系统级的。CameraTrace告诉你Camera内部哪一段慢了，Systrace告诉你为什么慢——是不是CPU被别的进程抢了？是不是GPU渲染不过来？是不是Binder线程池满了？
我一般这样搭配使用：先用CameraTrace定位到问题模块，再用Systrace分析系统层面的原因。
4.2 Systrace实战案例
有一次，我遇到一个诡异的问题：Camera预览偶尔卡顿，但抓CameraTrace看，每一帧的处理时间都正常。这就奇怪了。
打开Systrace一看，发现问题了：
// 抓取Systrace
adb shell atrace --async_start -c -b 81920 sched freq idle gfx input view webview wm am camera hal
// 操作Camera复现问题
adb shell atrace --async_dump > /data/local/tmp/systrace.txt
在Systrace里，我看到Camera预览线程每隔几秒就会被一个叫“media.codec”的线程抢占CPU。原来是有个后台视频转码任务在抢资源。杀掉那个进程，Camera预览立马流畅了。
经验之谈：很多Camera性能问题，根源不在Camera本身，而在系统资源竞争。Systrace就是帮你找到那个“抢资源的家伙”。
五、常见问题定位与Log分析技巧
5.1 常见问题分类
做Camera调试这些年，我遇到最多的问题就这几类：
- 打不开Camera：多半是HAL服务挂了，或者权限没给对。
- 预览黑屏：Sensor没初始化成功，或者ISP pipeline没起来。
- 拍照闪退：内存不足，或者某个回调没处理好。
- 录像卡顿：编码器跟不上，或者帧率不匹配。
- 对焦不准：AF算法参数没调好，或者马达驱动有问题。
5.2 Log分析三板斧
我总结了一套Log分析的“三板斧”，分享给你：
- 第一板斧：抓关键Log标签
// Camera相关的主要Log标签 adb logcat -s CameraService adb logcat -s CameraHal adb logcat -s Camera3Device adb logcat -s CameraMetadata adb logcat -s CameraError // 如果还不行，直接抓所有Error级别的Log adb logcat *:E - 第二板斧：看异常堆栈
找到“FATAL EXCEPTION”或者“CRASH”关键字，看堆栈里有没有我们自己的代码。如果有，十有八九是空指针或者数组越界。
- 第三板斧：对比正常Log
我习惯在设备正常的时候抓一份Log，出问题的时候再抓一份。用diff工具对比，看哪里不一样。这个方法特别管用，尤其是那些“偶发”的问题。
避坑指南：我曾经花了一整天去追一个“Camera打开失败”的问题，Log里报的是“Camera service disconnected”。我一直在查HAL层代码，最后发现是系统空间不足，cameraserver被LMK（Low Memory Killer）给杀了。所以，看Log的时候别只盯着Camera相关的标签，系统级的Log也要扫一眼。
5.3 一个完整的调试流程
最后，我分享一下我个人的调试流程，你可以参考：
- 复现问题：先确认问题能稳定复现。不能复现的问题，先别急着调。
- 抓Log：同时抓CameraTrace、Systrace和普通Log。三管齐下，信息最全。
- 初步定位：用CameraTrace看是不是Camera内部的问题。如果是，进HAL层查；如果不是，用Systrace看系统资源。
- 深入分析：根据初步定位的结果，加更多的Log或者Trace点，缩小范围。
- 修复验证：改完代码后，跑一遍CTS/ITS，确保没有引入新的问题。
嗯，这一章的内容就到这里。调试和测试是Camera开发中最磨人的部分，但也是最能积累经验的地方。多踩坑，多总结，你也能成为Camera调试的老手。
公众号:蓝海资料掘金营，微信deep3321