覆盖：堡机测试/压力测试场景 | Kernel+Logcat双维度 | 6条高通优化建议
堡机测试跑三天两夜，Camera突然crash了。日志几万行，从哪开始看？
稳定性问题是最让人头疼的——复现概率随机，有时候跑一晚上没事，有时候半小时就崩。而且crash日志动辄几万行，grep关键字都搜不到重点。
这篇文章整理了一套系统化的排查方法，从Kernel和Logcat两个维度入手，帮你快速定位问题根因。
一、Kernel日志排查
1.1 三个关键搜索关键字
在kernel日志中搜索以下关键字：
关键字含义
1.2 典型丢帧日志长什么样
解读
• Skip Frame 表示某个request的帧还没准备好，被跳过了
• Failed to notify BOOT_TS 表示帧的时间戳没有正确通知到上层
• 出现这些日志说明当前系统处于高负荷状态，驱动层已经开始丢帧
踩坑提醒：Skip Frame偶尔出现一两次是正常的（系统调度波动），但如果在短时间内大量出现，就是系统扛不住了。我遇到过堡机测试跑到第18小时突然开始疯狂Skip Frame，根因是内存泄漏导致可用内存不足。
二、Logcat日志排查
2.1 搜索丢帧信号
关键字：frameMessage:requestId=0
含义：requestId=0 表示没有request被应用到当前的frameCount，这帧将被skip。
实战经验：如果出现大量的 frameMessage:requestId=0，极大可能是驱动已经出现丢帧。这时需要抓kernel日志进一步确认根因——通常Kernel日志里能找到对应的 Skip Frame 记录。
2.2 搜索Camera Service异常
关注以下信息
• camerahalserver 进程是否被kill或重启
• 是否有 tombstone 文件生成（表示native crash）
• Crash的backtrace信息
三、性能问题排查
3.1 SO库Crash分析
在堡机测试中，经常遇到由于系统性能问题导致Camera HAL层触发signal abort，然后出现so库crash。
典型场景
1. 系统CPU被其他进程占用过高
2. 内存不足导致OOM
3. IPC通信超时
3.2 高通官方6条优化建议
高通针对此类性能问题给出的优化建议，按优先级排列：
① 增大CAM_REQ_MGR_EVENT_MAX的值
这个值控制Request Manager的事件队列大小。增大后可以缓存更多事件，减少丢帧概率。
② 使用Perf Build
编译Camera HAL时使用perf版本，关闭debug日志和断言，减少开销。
③ 提升CPU频率
通过修改CPU governor策略或设置最小频率来提升CPU性能。在堡机测试场景下特别有效。
④ 移除自定义Node
排查是否有不必要的自定义Node在pipeline中占用资源。
⑤ 优化第三方算法
第三方算法（如美颜、HDR）是常见的性能瓶颈，需要与算法厂商协同优化。
⑥ 降低Sensor帧率/分辨率/时钟
在性能瓶颈无法解决时，可以适当降低sensor的帧率或分辨率来减轻系统负担。这是最后的手段。
四、排查决策树
把整个排查流程画成决策树，拿到问题照着走就行：
经验总结：90%的稳定性问题都能在前4步定位到。如果前4步都没找到根因，大概率是第三方算法的问题——这时候需要找算法厂商一起分析。
五、实用调试命令
5.1 查看CPU使用情况
• 查看CPU核在线状态：
• 查看CPU频率：
• 查看进程CPU占用：
5.2 查看Camera进程状态
• Camera全景信息：
• 内存信息：
速查表
稳定性排查的核心是分层定位——先Kernel再Logcat，先确认现象再找根因。遇到问题不要慌，按决策树一步一步走，90%的问题都能在前4步定位到。
如果你在稳定性测试中遇到具体问题，欢迎在评论区留言交流。
---------------------------------------- ---- ---- ----------------------------------
"一站式Android Camera学习平台"： www.camerahub.cn
正式上线了，可以点击阅读原文直接访问。
更多Camera开发实战内容
欢迎加入知识星球「小驰成长圈」
120+ Camera工程师 · 340+ 实战内容 · 已运营1565天
微信扫码 · 加入星
评论 (0)