29、Camera 测试与调试：Camera CTS测试、Camera ITS测试、dumpsys camera命令、logcat过滤与分析
做Camera开发，有一件事我特别有感触：写代码只占30%，剩下70%的时间都在测试和调试。你想想看，相机涉及到硬件、驱动、HAL、框架、应用五个层级，任何一个环节出问题，表现都是“拍照黑屏”或者“预览卡顿”。
所以这一章，我把压箱底的调试三板斧拿出来聊聊。CTS测试、ITS测试、dumpsys、logcat过滤，这四个工具用好了，能帮你省掉至少一半的排查时间。
一、Camera CTS测试：兼容性的底线
CTS，全称Compatibility Test Suite。说白了，就是Google用来检查你的设备有没有“偷工减料”的测试集。我见过不少厂商，功能做得很花哨，结果CTS一跑，挂了上百条——那不好意思，Google认证就别想了。
1.1 CTS测试的核心模块
Camera相关的CTS测试主要集中在以下几个模块：
| 模块名 | 测试内容 | 常见失败原因 |
|---|---|---|
| android.hardware.camera2.cts | Camera2 API的完整功能验证 | HAL层未实现某些Capability |
| android.hardware.camera.cts | Camera1 API的兼容性测试 | 参数配置与CTS预期不符 |
| android.hardware.camera2.cts.ExtendedCameraCharacteristicsTest | Camera特性声明一致性 | Static metadata与实际能力不匹配 |
我个人习惯，每次修改HAL层代码后，先跑一遍Camera CTS的subset。别等全部集成完再跑，那时候问题堆在一起，定位起来特别痛苦。
1.2 如何执行CTS测试
# 运行全部Camera CTS测试
run cts -m CtsCameraTestCases
# 运行单个测试类
run cts -m CtsCameraTestCases -t android.hardware.camera2.cts.CameraDeviceTest
# 运行单个测试方法
run cts -m CtsCameraTestCases -t android.hardware.camera2.cts.CameraDeviceTest#testCameraDeviceCreate二、Camera ITS测试：图像质量的照妖镜
CTS测的是功能，ITS测的是画质。ITS全称Image Test Suite，它用专业的测试图卡（比如ColorChecker、SFR测试卡）来评估相机的成像质量。
我记得有一次，某个项目预览画面看起来还行，但ITS一跑，色彩还原度那一项直接挂了。后来查出来是3A算法里的AWB（自动白平衡）参数配错了。如果没有ITS，这种问题靠人眼看，根本发现不了。
2.1 ITS测试的关键指标
- 色彩精度：用ColorChecker图卡，计算实际颜色与标准颜色的Delta E值
- 锐度/解析力：用SFR（Spatial Frequency Response）图卡，测量MTF50值
- 噪点水平：在暗光环境下拍摄均匀灰卡，计算信噪比
- 畸变与色差：用棋盘格图卡，检测镜头的光学缺陷
- 动态范围：用高对比度场景，测量可分辨的亮度级数
2.2 ITS测试环境搭建
ITS对测试环境要求很苛刻。你需要：
- 标准D65光源（色温6500K），照度控制在500-1000 lux
- 测试图卡必须平整放置，与相机光轴垂直
- 相机到图卡的距离，根据图卡尺寸计算，确保图卡占画面80%以上
三、dumpsys camera命令：HAL层的听诊器
CTS和ITS是自动化测试，但日常调试中，我最常用的其实是dumpsys camera。这个命令能让你直接看到Camera框架内部的状态，比打log高效得多。
3.1 常用dumpsys命令
# 查看所有Camera设备信息
adb shell dumpsys camera
# 查看特定Camera ID的详细信息
adb shell dumpsys camera -D 0
# 查看Camera服务的内存使用
adb shell dumpsys meminfo cameraserver
# 查看Camera HAL的实时状态
adb shell dumpsys camera -S3.2 关键输出解读
dumpsys的输出信息量很大，我重点看这几个字段：
| 字段 | 含义 | 调试价值 |
|---|---|---|
| Number of cameras | 系统检测到的Camera数量 | 如果数量不对，说明HAL层枚举有问题 |
| Camera ID 0 status | Camera设备的状态（OPEN/CLOSE/ERROR） | 如果一直卡在OPEN状态，检查HAL的open接口 |
| Active streams | 当前活跃的数据流（预览/拍照/录像） | 流数量不对，可能是Stream配置冲突 |
| Request queue depth | 待处理的Request队列深度 | 队列持续增长，说明HAL处理速度跟不上 |
四、logcat过滤与分析：日志里的线索
最后说说logcat。很多人觉得logcat就是看看报错信息，其实不然。用好logcat，你能还原出整个Camera请求的生命周期。
4.1 高效过滤技巧
# 只看Camera框架层的日志
adb logcat -s CameraFramework
# 同时看Camera服务和HAL层日志
adb logcat -s CameraService:V CameraHAL:V
# 过滤出包含error/warning的日志
adb logcat -s *:E
# 按时间戳过滤（只看最近5秒的日志）
adb logcat -t 5 -s CameraFramework4.2 关键日志节点
一个典型的Camera capture请求，在logcat里会留下这些痕迹：
# 应用层创建CaptureRequest
CameraFramework: createCaptureRequest for camera 0, template PREVIEW
# 框架层将Request发送到HAL
CameraService: submitRequestList, requestId=123, numRequests=1
# HAL层开始处理
CameraHAL: processCaptureRequest, requestId=123, settings changed
# HAL层返回结果
CameraHAL: notify, requestId=123, result OK
# 框架层将结果回调给应用
CameraFramework: onCaptureCompleted, requestId=123, timestamp=987654321如果某个环节缺失了，问题就出在那里。比如HAL层没有返回notify，那肯定是HAL的processCaptureRequest实现有问题。
4.3 常见问题与log特征
| 问题现象 | logcat特征 | 排查方向 |
|---|---|---|
| 预览黑屏 | 没有收到onCaptureCompleted回调 | 检查HAL的processCaptureRequest是否返回 |
| 拍照卡顿 | Request queue depth持续增长 | HAL处理速度慢，检查ISP pipeline配置 |
| 闪退 | 出现FATAL EXCEPTION或SIGSEGV | HAL层内存越界或空指针 |
| 参数不生效 | settings changed为false | 应用层设置的参数没有被HAL识别 |
五、知识体系总览
下面这张图，是我对Camera测试与调试体系的总结。你可以把它当作一个检查清单，遇到问题时对照着排查。
说实话，Camera调试没有银弹。CTS能帮你守住兼容性底线，ITS能量化画质问题，dumpsys让你看到HAL内部状态，logcat则串联起整个请求的生命周期。这四个工具配合使用，大部分问题都能在半小时内定位到根因。
嗯，这一章的内容就到这里。调试工具是死的，但思路是活的。多跑、多看、多总结，慢慢你也会形成自己的调试节奏。
公众号:蓝海资料掘金营，微信deep3321