Camera稳定性

Camera稳定性排查

• [Qcom HAL](#Qcom HAL)
• • 一、Kernel日志排查
  • • [1.1 三个关键搜索关键字](#1.1 三个关键搜索关键字)
    • [1.2 典型丢帧日志长什么样](#1.2 典型丢帧日志长什么样)
  • 二、Logcat日志排查
  • • [2.1 搜索丢帧信号](#2.1 搜索丢帧信号)
    • [2.2 CameraService crash](#2.2 CameraService crash)
  • 三、性能问题排查
  • • [3.1 SO库Crash分析](#3.1 SO库Crash分析)
    • [3.2 高通官方6条优化建议](#3.2 高通官方6条优化建议)
  • 四、排查问题流程
  • 五、实用调试命令
  • • [5.1 查看CPU使用情况](#5.1 查看CPU使用情况)
    • [5.2 查看Camera进程状态](#5.2 查看Camera进程状态)
• [MTK HAL](#MTK HAL)
• [Camera APP](#Camera APP)
• CameraService
• 三方算法

Qcom HAL

一、Kernel日志排查

1.1 三个关键搜索关键字

在kernel日志中搜索以下关键字：

grep -E "workg delay|skip frame|Failed to notify BOOT_TS " kernel.log

含义：

workg delay ：工作线程延迟

skip frame ：丢帧

Failed to notify BOOT_TS：帧时间戳通知失败

1.2 典型丢帧日志长什么样

CAM_INFO: CAM-CRM: _cam_req_mgr_find_dev_name:237 Skip Frame : req: 588 not ready on link ...

CAM_WARN: CAM-CRM: cam_v4l2_event_queue_notify_error: 280 Failed to notify BOOT_TS Sess ...

含义：

Skip Frame ：表示某个request的帧还没准备好，被跳过了。

Failed to notify BOOT_TS ：表示帧的时间戳没有正确通知到上层。

出现这些日志说明当前系统处于高负荷状态，驱动层已经开始丢帧。

踩坑：Skip Frame 偶尔出现一两次是正常的（系统调度波动），但如果在短时间内大量出现，就是系统扛不住了。我遇到过堡机测试跑到第18小时突然开始疯狂Skip Frame，根因是内存泄漏导致可用内存不足。

二、Logcat日志排查

2.1 搜索丢帧信号

main_log过滤关键字：frameMessage:requestId=0

CSLMessageHandler() frameMessage:requestId=0

含义：

requestId=0表示没有 request 被应用到当前的 frameCount，这帧将被 skip。

踩坑：如果出现大量的 frameMessage:requestId=0，极大可能是驱动已经出现丢帧。这时需要抓kernel日志进一步确认根因------通常Kernel日志里能找到对应的 Skip Frame 记录。

2.2 CameraService crash

logcat | grep -E "cameraService|camerahalserver|tombstone"

关注以下信息：

• camerahalserver：进程是否被kill或重启
• 是否有 tombstone：文件生成（表示native crash）
• Crash的backtrace信息

三、性能问题排查

3.1 SO库Crash分析

在堡机测试中，经常遇到由于系统性能问题导致Camera HAL层触发signal abort，然后出现so库crash。

• 典型场景

1. 系统CPU被其他进程占用过高
2. 内存不足导致OOM
3. IPC通信超时
4. 使用库超时

3.2 高通官方6条优化建议

高通针对此类性能问题给出的优化建议，按优先级排列：

1. 增大CAM_REQ_MGR_EVENT_MAX的值

   // 文件路径：kernel/*/techpack/camera/drivers/cam_req_mgr/cam_req_mgr_dev.c
   #define CAM_REQ_MGR_EVENT_MAX 30  // 原始值，建议根据实际情况增大

   这个值控制 Request Manager 的事件队列大小。增大后可以缓存更多事件，减少丢帧概率。

2. 使用Perf Build

   use perf build

   编译Camera HAL时使用perf版本，关闭debug日志和断言，减少开销。

3. 提升CPU频率

   boost CPU frequency

   通过修改CPU governor策略或设置最小频率来提升CPU性能。在堡机测试场景下特别有效。

4. 移除自定义Node

   remove customized node

   排查是否有不必要的自定义Node在pipeline中占用资源。

5. 优化第三方算法

   improve 3rd party algo

   第三方算法（如美颜、HDR）是常见的性能瓶颈，需要与算法厂商协同优化。如果算法超时，看一下此环境温度、cpu频率。

6. 降低Sensor帧率/分辨率/时钟

   decrease sensor fps/res/opclk

   在性能瓶颈无法解决时，可以适当降低sensor的帧率或分辨率来减轻系统负担。这是最后的手段。

四、排查问题流程

Step 1: 确认问题类型
  └── Crash? 丢帧? 卡顿? 黑屏?

Step 2: 抓取日志
  ├── adb logcat -b all > logcat.txt
  ├── adb shell dmesg > kernel.txt
  └── adb shell dumpsys media.camera > camera_dump.txt

Step 3: Kernel日志排查
  └── grep "skip frame|workg delay|BOOT_TS"

Step 4: Logcat日志排查
  └── grep "frameMessage:requestId=0|tombstone|crash"
  └── 温度、内存、cpu频率、cpu大小核

Step 5: 确认系统状态
  ├── top -m 10（查看CPU占用TOP进程）
  ├── dumpsys meminfo（查看内存状态）
  └── cat /sys/devices/system/cpu/cpu*/online（查看CPU核状态）

Step 6: 针对性优化
  ├── 丢帧 → 增大CAM_REQ_MGR_EVENT_MAX
  ├── Crash → 分析tombstone backtrace
  └── 性能 → boost CPU / 降低fps / 优化算法

经验总结：90%的稳定性问题都能在前4步定位到。如果前4步都没找到根因，大概率是第三方算法的问题------这时候需要找算法厂商一起分析。

五、实用调试命令

5.1 查看CPU使用情况

adb shell cat /sys/devices/system/cpu/cpu*/online（查看CPU核在线状态）

adb shell cat /sys/devices/system/cpu/cpu*/cpuinfo_cur_freq（查看CPU频率）

adb shell top -m 10（查看进程CPU占用）

5.2 查看Camera进程状态

adb shell dumpsys media.camera > camera.txt（Camera全景信息）

adb shell dumpsys meminfo | grep camera（内存信息）

MTK HAL

Camera APP

CameraService

三方算法