Camera功耗问题在项目后期几乎是必查项。预览功耗高、拍照功耗超标、后台待机掉电快……这篇问题把高通平台功耗排查的全链路思路整理出来，希望对大家日常排查问题有帮助，建议收藏，备用。
一、功耗排查前置准备
在开始Camera侧排查之前，先和BSP功耗团队一起做整机的功耗拆解：
- 测量整机功耗 — 用功耗拆解板分别测量Sensor、CPU、CX、DDR、Panel各模块的功耗
- 确认FPS达标 — 和性能团队确认FPS是否达标，不达标时CPU调度策略会拉高频率
- 检查GPU/MDP时钟 — 和Display/Graphics团队确认GPU/MDP时钟是否合理
- 准备Driver Only版本
确认是Camera侧问题后，进入下面的Camera专项检查清单。
二、Camera侧排查清单
2.1 日志负载检查
很多人不知道，Camera HAL的日志本身会消耗可观的CPU功耗。先量化日志的影响：
# 测量10秒的日志文件大小
adb logcat -v time > log_10s.txt
# 检查文件大小，超过500KB说明日志量过大
# 关闭多余日志
# camxsettings.xml中设置：
overrideLogLevels=0x00
systemLogEnable=FALSE
# 对比关闭日志前后的功耗
adb shell stop logd
# 测量功耗电流，对比差异⚠️ 注意：overrideLogLevels和systemLogEnable只能控制Camx核心日志。CHI Node的日志需要单独在CHI代码里关闭，别漏了。
2.2 Stream和Buffer检查
多余的Stream和过大的Buffer是功耗杀手：
# 开启内存统计
logInfoMask=32
enableMemoryStats=TRUE
# 运行memprofile脚本分析Buffer
python get_memory_stats.py preview preview camera_log.txt检查重点：
- Stream数量
- Buffer格式 — 是否使用了UBWC压缩格式（直接影响DDR带宽和功耗）
- max_buffers
- usage参数
2.3 3A负载检查
3A算法（AEC/AWB/AF）的统计信息处理会消耗CPU。如果怀疑3A负载高：
# 临时关闭各统计处理，测量功耗变化
# camxsettings.xml:
DisableAWBStatsProcessing=TRUE
disableAFStatsProcessing=TRUE
disablePDAF=TRUE
# 逐个关闭后测量功耗差异
# 可定位是哪个3A模块在吃功耗三、CPU指令级分析
3.1 Systrace分析
# 开启Systrace相关配置
traceGroupsEnable=0x10080
systemLogEnable=FALSE
overrideLogLevels=0x00
# 抓取systrace
# 在Systrace中检查Camera HAL线程的运行时间
# 理想状态：Camera HAL任务只在Node Process中运行且有trace tag如果发现长时间运行但没有trace tag的任务，说明有异常行为——可能是某个线程在做不该做的事。
3.2 Simpleperf指令采样
用simpleperf精确统计CPU指令数，这是定位热点函数的关键：
# 获取camera provider的PID
adb shell ps -e | grep camera.provider
# 统计指令数（10秒采样）
adb shell "/system/bin/simpleperf stat -p <PID> -o /data/misc/perf_stat.txt --duration 10 -e instructions"
adb pull /data/misc/perf_stat.txt
# 函数级性能分析
adb shell "/system/bin/simpleperf record -p <PID> -g -e instructions -o /data/misc/perf.data --duration 10 -c 1000000"
adb shell "/system/bin/simpleperf report -i /data/misc/perf.data > /data/misc/report.txt"
adb shell "/system/bin/simpleperf report -i /data/misc/perf.data -g --full-callgraph > /data/misc/report_callgraph.txt"
adb pull /data/misc/report.txt
adb pull /data/misc/report_callgraph.txt3.3 生成火焰图
# 克隆FlameGraph工具
git clone https://github.com/brendangregg/FlameGraph.git
# 转换perf.data为火焰图
python report_sample.py perf.data > out.perf
FlameGraph/stackcollapse-perf.pl out.perf > out.folded
FlameGraph/flamegraph.pl out.folded > flame.svg
# 在浏览器打开flame.svg火焰图能直观展示CPU时间花在哪了。把客户设备的火焰图和基线对比，热点函数一目了然。
3.4 Page Fault分析
Page Fault过多通常意味着频繁的map/unmap/alloc操作：
# 采样page-fault事件
adb shell "/system/bin/simpleperf record -p <PID> -g -e page-faults -o /data/misc/perf.data --duration 10"
# 分析page-fault调用栈
# 如果采样数异常高，用火焰图定位是哪个函数在做频繁内存映射四、Sensor驱动与Pipeline检查
4.1 Sensor分辨率与驱动配置
Sensor XML中的以下参数直接影响IFE时钟和功耗：
| |
|---|
| |
| |
| |
| |
| minHorizontalBlanking / minVerticalBlanking | |
4.2 Pipeline设计审查
客户定制的Pipeline设计是功耗异常的常见原因：
- 去掉不必要的HW Node — 比如Snapshot流不需要的HW Node会增加额外功耗
- 先用默认Pipeline测基线 — 在排查定制Pipeline之前，先用高通推荐的默认Pipeline/usecase测一遍
- 逐个移除CHI Node — SAT/EIS/美颜等CHI Node，逐个移除来拆解功耗
- 检查EIS Frame Delay — Frame Delay和EIS Margin可以适当减小来降低功耗
- 检查OIS采样率
4.3 时钟频率Dump
# Dump所有Camera子设备的时钟
adb shell "find /d/clk/cam_cc* -iname clk_measure -exec grep -ni '^[1-9]' /dev/null {} \;" | more
# 对照DTSI检查时钟级别是否合理4.4 功耗日志检查
# 开启Power相关日志
# CamxLogGroupPower对应的Mask值
# 可以查看IFE/IPE Node的Clock/BW计算过程
# 确认BW/Clock投票是否合理
# 在日志中搜索Power相关日志
grep -i "power\|clock\|bandwidth\|bw" camera_log.txt五、功耗排查速查表
| | |
|---|
| | |
| | |
| | |
| simpleperf -e page-faults | |
| | framerate、outputPixelClock |
| | |
| | |
六、实战建议
💡 功耗排查黄金法则
- 先测基线，再查差异 — 用默认配置测出基线功耗，再逐步加定制内容看增量
- 日志是第一功耗杀手 — 排查功耗前先关日志，可能省掉10-20%的CPU负载
- UBWC格式是免费午餐 — 所有YUV Buffer都应该用UBWC，直接降低DDR带宽
- CHI Node逐个拆 — SAT/EIS/美颜每个都是功耗大户，逐个移除测量
- 对比基线火焰图
— END —
觉得有帮助？点个「在看」转发给同事吧 👇
更多Camera开发实战内容
欢迎加入知识星球「小驰成长圈」
120+ Camera工程师 · 340+ 实战内容 · 已运营1565天
微信扫码 · 加入星球
评论 (0)