Camera功耗问题在项目后期几乎是必查项。预览功耗高、拍照功耗超标、后台待机掉电快……这篇问题把高通平台功耗排查的全链路思路整理出来希望对大家日常排查问题有帮助建议收藏备用。一、功耗排查前置准备在开始Camera侧排查之前先和BSP功耗团队一起做整机的功耗拆解测量整机功耗— 用功耗拆解板分别测量Sensor、CPU、CX、DDR、Panel各模块的功耗确认FPS达标— 和性能团队确认FPS是否达标不达标时CPU调度策略会拉高频率检查GPU/MDP时钟— 和Display/Graphics团队确认GPU/MDP时钟是否合理准备Driver Only版本— 用纯驱动版本不含CHI定制对标基线功耗确认是Camera侧问题后进入下面的Camera专项检查清单。二、Camera侧排查清单2.1 日志负载检查很多人不知道Camera HAL的日志本身会消耗可观的CPU功耗。先量化日志的影响# 测量10秒的日志文件大小adb logcat -v time log_10s.txt# 检查文件大小超过500KB说明日志量过大# 关闭多余日志# camxsettings.xml中设置overrideLogLevels0x00systemLogEnableFALSE# 对比关闭日志前后的功耗adb shell stop logd# 测量功耗电流对比差异⚠️ 注意overrideLogLevels和systemLogEnable只能控制Camx核心日志。CHI Node的日志需要单独在CHI代码里关闭别漏了。2.2 Stream和Buffer检查多余的Stream和过大的Buffer是功耗杀手# 开启内存统计logInfoMask32enableMemoryStatsTRUE# 运行memprofile脚本分析Bufferpython get_memory_stats.py preview preview camera_log.txt检查重点Stream数量— App是否申请了不必要的StreamBuffer格式— 是否使用了UBWC压缩格式直接影响DDR带宽和功耗max_buffers— Buffer池大小是否合理usage参数— Stream的usage flag是否正确2.3 3A负载检查3A算法AEC/AWB/AF的统计信息处理会消耗CPU。如果怀疑3A负载高# 临时关闭各统计处理测量功耗变化# camxsettings.xml:DisableAWBStatsProcessingTRUEdisableAFStatsProcessingTRUEdisablePDAFTRUE# 逐个关闭后测量功耗差异# 可定位是哪个3A模块在吃功耗三、CPU指令级分析3.1 Systrace分析# 开启Systrace相关配置traceGroupsEnable0x10080systemLogEnableFALSEoverrideLogLevels0x00# 抓取systrace# 在Systrace中检查Camera HAL线程的运行时间# 理想状态Camera HAL任务只在Node Process中运行且有trace tag如果发现长时间运行但没有trace tag的任务说明有异常行为——可能是某个线程在做不该做的事。3.2 Simpleperf指令采样用simpleperf精确统计CPU指令数这是定位热点函数的关键# 获取camera provider的PIDadb shell ps -e | grep camera.provider# 统计指令数10秒采样adb shell /system/bin/simpleperf stat -p PID -o /data/misc/perf_stat.txt --duration 10 -e instructionsadb 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 1000000adb shell /system/bin/simpleperf report -i /data/misc/perf.data /data/misc/report.txtadb shell /system/bin/simpleperf report -i /data/misc/perf.data -g --full-callgraph /data/misc/report_callgraph.txtadb pull /data/misc/report.txtadb 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.perfFlameGraph/stackcollapse-perf.pl out.perf out.foldedFlameGraph/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时钟和功耗参数影响framerate直接影响IFE时钟频率lineLengthPixelClock行像素时钟影响IFE时钟选择frameLengthLines帧长行数影响FPS和功耗outputPixelClock输出像素时钟配置错误会导致PHY/CSID错误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采样率— 采样率过高会带来大量中断和CPU负载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五、功耗排查速查表排查方向工具/方法关键指标日志负载adb logcat测文件大小10秒日志 500KB 过高Buffer/Streammemprofile脚本多余Stream、非UBWC格式CPU负载simpleperf 火焰图指令数、热点函数Page Faultsimpleperf -e page-faults采样数过高 频繁映射Sensor配置Sensor XML检查framerate、outputPixelClockPipeline设计默认Pipeline对比多余HW Node、CHI Node负载时钟频率clk_measure dump对照DTSI确认级别六、实战建议 功耗排查黄金法则先测基线再查差异— 用默认配置测出基线功耗再逐步加定制内容看增量日志是第一功耗杀手— 排查功耗前先关日志可能省掉10-20%的CPU负载UBWC格式是免费午餐— 所有YUV Buffer都应该用UBWC直接降低DDR带宽CHI Node逐个拆— SAT/EIS/美颜每个都是功耗大户逐个移除测量对比基线火焰图— 和参考设备的火焰图对比热点差异一目了然— END —觉得有帮助点个「在看」转发给同事吧 更多Camera开发实战内容欢迎加入知识星球「小驰成长圈」120 Camera工程师 · 340 实战内容 · 已运营1565天微信扫码 · 加入星球 Camera功耗排查全攻略 | 建议收藏备用
Camera功耗问题在项目后期几乎是必查项。预览功耗高、拍照功耗超标、后台待机掉电快……这篇问题把高通平台功耗排查的全链路思路整理出来希望对大家日常排查问题有帮助建议收藏备用。一、功耗排查前置准备在开始Camera侧排查之前先和BSP功耗团队一起做整机的功耗拆解测量整机功耗— 用功耗拆解板分别测量Sensor、CPU、CX、DDR、Panel各模块的功耗确认FPS达标— 和性能团队确认FPS是否达标不达标时CPU调度策略会拉高频率检查GPU/MDP时钟— 和Display/Graphics团队确认GPU/MDP时钟是否合理准备Driver Only版本— 用纯驱动版本不含CHI定制对标基线功耗确认是Camera侧问题后进入下面的Camera专项检查清单。二、Camera侧排查清单2.1 日志负载检查很多人不知道Camera HAL的日志本身会消耗可观的CPU功耗。先量化日志的影响# 测量10秒的日志文件大小adb logcat -v time log_10s.txt# 检查文件大小超过500KB说明日志量过大# 关闭多余日志# camxsettings.xml中设置overrideLogLevels0x00systemLogEnableFALSE# 对比关闭日志前后的功耗adb shell stop logd# 测量功耗电流对比差异⚠️ 注意overrideLogLevels和systemLogEnable只能控制Camx核心日志。CHI Node的日志需要单独在CHI代码里关闭别漏了。2.2 Stream和Buffer检查多余的Stream和过大的Buffer是功耗杀手# 开启内存统计logInfoMask32enableMemoryStatsTRUE# 运行memprofile脚本分析Bufferpython get_memory_stats.py preview preview camera_log.txt检查重点Stream数量— App是否申请了不必要的StreamBuffer格式— 是否使用了UBWC压缩格式直接影响DDR带宽和功耗max_buffers— Buffer池大小是否合理usage参数— Stream的usage flag是否正确2.3 3A负载检查3A算法AEC/AWB/AF的统计信息处理会消耗CPU。如果怀疑3A负载高# 临时关闭各统计处理测量功耗变化# camxsettings.xml:DisableAWBStatsProcessingTRUEdisableAFStatsProcessingTRUEdisablePDAFTRUE# 逐个关闭后测量功耗差异# 可定位是哪个3A模块在吃功耗三、CPU指令级分析3.1 Systrace分析# 开启Systrace相关配置traceGroupsEnable0x10080systemLogEnableFALSEoverrideLogLevels0x00# 抓取systrace# 在Systrace中检查Camera HAL线程的运行时间# 理想状态Camera HAL任务只在Node Process中运行且有trace tag如果发现长时间运行但没有trace tag的任务说明有异常行为——可能是某个线程在做不该做的事。3.2 Simpleperf指令采样用simpleperf精确统计CPU指令数这是定位热点函数的关键# 获取camera provider的PIDadb shell ps -e | grep camera.provider# 统计指令数10秒采样adb shell /system/bin/simpleperf stat -p PID -o /data/misc/perf_stat.txt --duration 10 -e instructionsadb 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 1000000adb shell /system/bin/simpleperf report -i /data/misc/perf.data /data/misc/report.txtadb shell /system/bin/simpleperf report -i /data/misc/perf.data -g --full-callgraph /data/misc/report_callgraph.txtadb pull /data/misc/report.txtadb 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.perfFlameGraph/stackcollapse-perf.pl out.perf out.foldedFlameGraph/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时钟和功耗参数影响framerate直接影响IFE时钟频率lineLengthPixelClock行像素时钟影响IFE时钟选择frameLengthLines帧长行数影响FPS和功耗outputPixelClock输出像素时钟配置错误会导致PHY/CSID错误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采样率— 采样率过高会带来大量中断和CPU负载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五、功耗排查速查表排查方向工具/方法关键指标日志负载adb logcat测文件大小10秒日志 500KB 过高Buffer/Streammemprofile脚本多余Stream、非UBWC格式CPU负载simpleperf 火焰图指令数、热点函数Page Faultsimpleperf -e page-faults采样数过高 频繁映射Sensor配置Sensor XML检查framerate、outputPixelClockPipeline设计默认Pipeline对比多余HW Node、CHI Node负载时钟频率clk_measure dump对照DTSI确认级别六、实战建议 功耗排查黄金法则先测基线再查差异— 用默认配置测出基线功耗再逐步加定制内容看增量日志是第一功耗杀手— 排查功耗前先关日志可能省掉10-20%的CPU负载UBWC格式是免费午餐— 所有YUV Buffer都应该用UBWC直接降低DDR带宽CHI Node逐个拆— SAT/EIS/美颜每个都是功耗大户逐个移除测量对比基线火焰图— 和参考设备的火焰图对比热点差异一目了然— END —觉得有帮助点个「在看」转发给同事吧 更多Camera开发实战内容欢迎加入知识星球「小驰成长圈」120 Camera工程师 · 340 实战内容 · 已运营1565天微信扫码 · 加入星球