第18章摄像头调试

课程目录第18章摄像头调试

18、摄像头调试：Camera HAL、ISP调试、帧率问题、预览延迟

摄像头调试，说实话，是Android系统调试里最让人头疼的模块之一。为什么？因为它涉及硬件、驱动、HAL层、框架层，甚至还有应用层的渲染链路。任何一个环节出问题，你看到的可能就是黑屏、卡顿、或者画面撕裂。

我个人习惯把摄像头调试分成三个层次：底层通路（Sensor + ISP）、中间层（Camera HAL + 3A算法）、上层表现（预览帧率 + 延迟）。今天我们就顺着这条线，把常见问题捋一遍。

Camera HAL是硬件和Framework之间的桥梁。说白了，Framework要拍照，它得告诉HAL：“给我一帧数据”。HAL再去驱动Sensor，拿到原始数据，做完处理，再扔回给Framework。

我在项目中遇到过最典型的问题：HAL层死锁。现象是打开相机后，预览画面卡住不动，但log里没有任何崩溃信息。查了半天，发现是HAL里某个buffer queue满了，而consumer线程又在等另一个锁，形成了循环等待。

  调试HAL层的关键点：
  检查 camera_service 的log，看是否有 waitForNextFrame 超时
使用 adb shell dumpsys media.camera 查看HAL状态
关注 processCaptureRequest 的返回时间，超过33ms就说明有问题

嗯，这里要注意：HAL层还有一个常见的坑——metadata传递错误。比如你明明设置了30fps，但HAL返回的 ANDROID_CONTROL_AE_TARGET_FPS_RANGE 却是15-30。这时候预览帧率就会忽高忽低。

ISP（图像信号处理器）负责把Sensor的原始RAW数据，变成我们能看的YUV或JPEG。它做的事情包括：去噪、坏点校正、白平衡、色彩校正、Gamma校正等等。

你想想看，如果ISP参数没调好，画面会是什么样？偏色、噪点多、暗部细节丢失。我调试ISP时，最常用的工具是 Chrome 的 chrome://inspect 配合 dump 出来的RAW图，在PC上用工具逐帧分析。

我的调试习惯：

我曾经遇到过一个奇葩问题：预览画面偏绿，但拍照出来的照片颜色正常。查了三天，最后发现是ISP的 预览通路和拍照通路用了不同的色彩矩阵。预览通路用的是 color_correction_gains 默认值，而拍照通路用了校准值。这种问题，光看log是看不出来的，必须dump帧对比。

帧率问题，说白了就是“数据流不够快”。一个典型的30fps预览，每帧的处理时间不能超过33ms。如果超过，帧率就会掉。

我一般从这几个方向排查：

注意： 不要只看应用层的帧率。有时候应用层显示30fps，但实际画面是重复的——这叫“伪帧”。真正的帧率要看 BufferQueue 的dequeue和queue时间。

举个例子，我在调试某款手机的前置摄像头时，预览帧率只有12fps。查了一圈，发现是HAL里对每一帧都做了 JPEG编码。预览通路根本不需要JPEG，只需要YUV。去掉这个多余的编码后，帧率直接回到30fps。

预览延迟，也叫“取景延迟”或“快门延迟”。它和帧率是两回事。帧率低是画面卡顿，延迟高是你转动手机时，画面跟不上你的动作。

延迟的构成大致是：

我曾经遇到一个案例：用户反馈自拍时，手机移动后画面要等半秒才跟上。用 adb shell dumpsys gfxinfo 一看，发现 GPU渲染时间 高达80ms。原因是预览分辨率设置成了4K，而GPU处理4K的YUV数据非常吃力。把预览分辨率降到1080p后，延迟降到了30ms以内。

快速定位延迟的步骤：

下面这张图，是我自己总结的摄像头调试知识体系。你可以把它当作一个检查清单，遇到问题时，按图索骥。

这张图把摄像头调试分成了三个核心模块，外加底部的工具集。你遇到问题时，先定位是哪个模块的问题，再选对应的工具去查。我个人觉得，调试摄像头最忌讳的就是“乱试”——改一个参数，看效果，不行再改。一定要有系统的方法论。

好了，关于摄像头调试，今天就聊这么多。记住：先看log，再dump帧，最后改代码。这个顺序能帮你省下至少一半的调试时间。