当前位置：首页 > news >正文

Android 功耗分析（底层篇）

news 2025/7/9 6:20:42

最近在网上发现关于功耗分析系列的文章很少，介绍详细的更少，于是便想记录总结一下功耗分析的相关知识，有不对的地方希望大家多指出，互相学习。本系列分为底层篇和上层篇。

大概从基础知识，测试手法，以及案例分析三个方面着手。

一、基础知识

底层篇主要介绍底电流的调试与分析。首先我们要明确什么是底电流，什么是待机电流。

1.1、概念

底电流：指机器完全睡眠时的最低电流。

待机电流：是指机器在待机一段时间内的平均电流，通常需要插卡进行测试。

1.2、为什么要测试底电流

主要目的是评估设备在最低功耗状态下的能耗表现，对于电池供电的设备（如手机、可穿戴设备、IoT 设备），底电流直接影响设备在长时间非使用场景下的待机时长。

测量底电流是评估产品功耗指标是否符合设计要求的关键步骤。
通过实际测量与设计目标对比，发现并解决功耗异常问题
底电流测试可以帮助开发者发现硬件设计中的电流泄漏问题，例如：
- 元器件未完全关闭。
- 电路设计不合理导致的静态电流消耗。
通过逐步排查电路中的模块，找到并优化功耗“热点。

测量底电流的最终目的是确保设备在低功耗状态下的能耗最小化。它不仅有助于排查和优化硬件设计，还能验证系统功耗策略的有效性，并最终延长设备的续航时间。对于任何需要长待机时间的电池驱动设备，底电流测试是不可或缺的一步。

二、底电流调试方法

这里主要介绍高通平台的调试方法。

2.1、首先要进行RF校准

射频QCN文件下载并进行射频校准。高通有专门的工具刷入机器里，因为QCN文件不下载射频不能正常工作，会引起漏电，继而引起底电流偏大。

2.2、排除其他因素

打开飞行模式，避免蓝牙、wifi、NFC、网络、FM等的一般影响。

关闭GPS，避免GPS对底电流的影响。

关闭自动旋转屏幕，排除sensor的影响。

关闭自动亮度，以及其他特效设置。

手动移除可以移除的所有外设以及驱动模块，例如：

lsmod

rmmod WLAN

2.3、进行待机测试

灭屏待机，连接power monitor 查看实时电流，分析机器是否进入睡眠状态，可以通过串口查看kernel日志，搜索关键字suspend entry查看是否进入睡眠。

2.4、分析kernel日志

kernel没有进入睡眠则查看是哪个模块引起的并有针对性分析相应模块。如果进入休眠电流还大，需要分析各个模块的clock有没有关闭。

2.5、抓取rpm dump日志进行分析

方法如下：

（1）ps_hold接地

在休眠状态下，接ps_hold到地少于200mS，机器会进入紧急下载状态，插入USB，QPST会自动得到memory dump，然后上传以下几个文件：

CODERAM.bin

MSGRAM.bin

DATARAM.bin

以及RPM_AAAAANAZR.elf（必须与机器的编译时间一致匹配的elf）

（2）改reset为download key

发这些命令改reset为download key:

 cd /sys/kernel/debug/spmi/spmi-0echo 0x844 > addressecho 4 > count # cat data 00840 -- -- -- -- 0F 07 04 00echo 0x00 0x00 0x01 0x00 > datacat data 00840 -- -- -- -- 00 00 01 00echo 0x00 0x00 0x01 0x80 > datacat data 00840 -- -- -- -- 00 00 01 80

然后长按下键，会进入download。之后抓取log方法同上

如果进不了download，需要确认

CONFIG_MSM_DLOAD_MODE=y

2.6、查看rmp_stats的状态

检查rpm_stats是否进入vdd min或者xo/no shutdown。使用下面的命令检查rpm lower power mode count:

adb shell mount -t debugfs none /sys/kernel/debugadb cat /sys/kernel/debug/rpm_stats

如果vmin的count是0，则表明设备从来没有进入vdd min；non-zero则说明设备进入过vdd_min。

示例：

RPM Mode: xosdcount:0time in last mode(msec):0time since last mode(sec):794actual last sleep(msec):0RPM Mode:vmincount:11time in last mode(msec):0time since last mode(sec):359actual last sleep(msec):110000

可以dump出来完整详细的gpio/clk/pmic信息，排除休眠时候的状态异常。

2.7、查看modem是否休眠

可以通过检测TCXO引脚的状态来确定modem端是否休眠，在modem端tlmm_bsp.c文件下比对各个GPIO有无设置错误继而引起漏电。另外，sleep_target.c文件也值得分析。

三、待机电流优化

3.1、adb命令抓取日志

在优化前，我们需要通过日志来确定导致功耗偏高的原因。可以通过一些adb命令进行排查。

adb logcat -v time > YearMounthDayHourMinute_logcat.txt //main logadb logcat -v time -b events > YearMounthDayHourMinute_logcat_event.txt //event logadb logcat -v time -b radio > YearMounthDayHourMinute_logcat_radio.txt //radio logadb shell dmesg > YearMounthDayHourMinute_dmesg.txt //kernel log

抓取对应的日志

adb shell mount -t debugfs none /sys/kernel/debug

用于将 debugfs 文件系统挂载到 Android 设备的 /sys/kernel/debug 目录，允许开发者访问内核的调试信息、性能数据和其他调试工具

adb shell "echo 8 > /proc/sys/kernel/printk"

将内核的日志级别设置为 8，使得内核输出最详细的调试信息

除了上述的方法，我们也可以使用如下命令来打开指定文件的kernel log（以qpnp-adc-tm.c和qpnp-adc-common.c为例）：

adb shell "echo 'file qpnp-adc-tm.c +p' > /sys/kernel/debug/dynamic_debug/control"adb shell "echo 'file qpnp-adc-common.c +p' > /sys/kernel/debug/dynamic_debug/control"

我们也可以为指定的函数开启log

以qpnpint_handle_irq为例：

adb shell "echo 'func qpnpint_handle_irq +p' > /sys/kernel/debug/dynamic_debug/control"

3.2、Top命令

使用

adb shell 
top

在待机的时候可以通过top命令查看是否有应用一直占用cpu，如果未主动开启该应用，但是却显示一直占用cpu，那么该应用的行为就存在异常。

3.3、查看唤醒源以及wakelock持锁

在调试wakeup的时候我们可以使用一下命令开启一些debug日志的信息。

（1）调试命令

3.3.1

mount -t debugfs none /sys/kernel/debug  echo 1 > /sys/kernel/debug/clk/debug_suspend

用于启用内核中时钟管理的调试功能，主要帮助开发人员排查设备挂起/恢复过程中与时钟相关的问题，如底电流偏高、时钟未正确关闭等

3.3.2

echo 1 > /sys/module/msm_show_resume_irq/parameters/debug_mask

用于在高通平台上启用中断（IRQ）唤醒调试功能，帮助开发者分析设备从挂起状态恢复过程中与中断相关的问题。这是调试底电流偏高、功耗问题或唤醒异常的重要工具之一，但需注意对性能和存储的影响，调试完成后建议关闭该功能。

3.3.3

echo 4 > /sys/module/wakelock/parameters/debug_mask

用于在 Android 内核中启用 wakelock 模块 的高级调试功能，记录唤醒锁的获取和释放情况

3.3.4

echo 1 > /sys/module/lpm_levels/parameters/debug_mask

用于启用低功耗模式（LPM）模块的基本调试日志输出

3.3.5

echo 0x16 > /sys/module/smd/parameters/debug_mask

用于启用高通平台 SMD（共享内存驱动） 的调试日志，主要用于分析设备间通信问题和优化功耗管理

（2）wakelock

1、wakeup_sources

在待机日志中，kernel层的wakelock和userspace的wakelock都有可能阻止系统休眠，所有的wakeup_sources均保存在sys节点/sys/kernel/debug/wakeup_sources里面。（该文件记录了wake sources的详细调试信息），这个文件包含了以下的信息：

a、the total amount of time a wakeup source has prevented suspend

当系统尝试进入休眠（suspend）时，某些唤醒源（如网络、传感器、应用程序等）可能会阻止这一过程

b、the amount of time a wakelock has been active since the last activation etc. The unit of time is milliseconds

每个唤醒源通常通过 wakelock（唤醒锁）机制防止系统休眠，表示唤醒锁最近一次被激活后，持续保持活跃的时间

2、active_since

active_since的值可以用来确认wakelock是否正在阻止休眠。如果该值不是零，那么这个wakelock正在工作并且阻止休眠

3、获取wakeup_source文件

adb root
adb shell
cat /sys/kernel/debug/wakeup_sources > /data/wakeup_sources.txtadb pull /data/wakeup_sources.txt

查看pull出来的wakeup sources.txt文件，查看active_since 不为0的项，即为阻止系统休眠的。

4、power:wakeup_source_activate 和 power:wakeup_source_deactivate events

当一个wakeup_sources被acquire和relerase的时候，通过启用 power:wakeup_source_activate 和 power:wakeup_source_deactivate 事件并记录到 trace buffer，可以记录wakeup source被driver使用的频率。

下面是开启该功能的方法。

echo "power:wakeup_source_activate power:wakeup_source_deactivate" > /sys/kernel/debug/tracing/set_event

The power:wakeup_source_activate and power:wakeup_source_deactivate events are written to the trace buffer any time a wakeup source is acquired or released and it can provide information on how often a wakeup source is being used by a driver. To enable these events, you can enable following: echo "power:wakeup_source_activate power:wakeup_source_deactivate" > /sys/kernel/debug/tracing/set_event Once the above done, the traces will be present in /sys/kernel/debug/tracing/trace.

解释如下：

当唤醒源被某个驱动程序或模块 激活（acquired） 或 释放（released） 时，内核会自动生成两个事件：
- power:wakeup_source_activate：表示唤醒源被激活的事件。
- power:wakeup_source_deactivate：表示唤醒源被释放的事件。
这些事件会被记录到 trace buffer（内核调试追踪缓冲区）中，通过记录这些事件，可以统计每个唤醒源被驱动使用的频率，需要通过特定命令启用这些事件的记录功能
echo "power:wakeup_source_activate power:wakeup_source_deactivate" > /sys/kernel/debug/tracing/set_event
启用事件后，所有记录的信息都会被保存到文件 /sys/kernel/debug/tracing/trace 中。
作用：
通过查看该文件，可以实时了解唤醒源的活动记录。