Android 功耗分析（底层篇）
近来在网上发现关于功耗分析系列的文章很少，介绍详细的更少，于是便想纪录总结一下功耗分析的相关知识，有不对的地方盼望大家多指出，互相学习。本系列分为底层篇和上层篇。大概从基础知识，测试伎俩，以及案例分析三个方面着手。
一、基础知识
底层篇紧张介绍底电流的调试与分析。起首我们要明确什么是底电流，什么是待机电流。
1.1、概念
底电流：指机器完全就寝时的最低电流。
待机电流：是指机器在待机一段时间内的平均电流，通常需要插卡举行测试。
https://i-blog.csdnimg.cn/direct/3a93ca829a894ea5ae07c63ffec8c47a.png
1.2、为什么要测试底电流
紧张目的是评估装备在最低功耗状态下的能耗表现，对于电池供电的装备（如手机、可穿戴装备、IoT 装备），底电流直接影响装备在长时间非使用场景下的待机时长。
[*]测量底电流是评估产物功耗指标是否符合计划要求的关键步骤。
[*]通过实际测量与计划目标对比，发现并解决功耗异常问题
[*]底电流测试可以帮助开发者发现硬件计划中的电流泄漏问题，例如：
[*]元器件未完全关闭。
[*]电路计划不合理导致的静态电流斲丧。
[*]通过逐步排查电路中的模块，找到并优化功耗“热门。
测量底电流的终极目的是确保装备在低功耗状态下的能耗最小化。它不光有助于排查和优化硬件计划，还能验证系统功耗计谋的有用性，并终极延伸装备的续航时间。对于任何需要长待机时间的电池驱动装备，底电流测试是不可或缺的一步。
二、底电流调试方法以及工具
这里紧张介绍高通平台的调试方法。
工具的话推荐使用Power Monitor测试电流，非常的简朴好用。
Power monitor使用说明（非常不错）.doc
2.1、起首要举行RF校准
射频QCN文件下载并举行射频校准。高通有专门的工具刷入机器里，由于QCN文件不下载射频不能正常工作，会引起漏电，继而引起底电流偏大。
2.2、清除其他因素
打开飞行模式，克制蓝牙、wifi、NFC、网络、FM等的一般影响。
关闭GPS，克制GPS对底电流的影响。
关闭自动旋转屏幕，清除sensor的影响。
关闭自动亮度，以及其他特效设置。
手动移除可以移除的所有外设以及驱动模块，例如：
lsmod
rmmod WLAN
2.3、举行待机测试
灭屏待机，连接power monitor 检察及时电流，分析机器是否进入就寝状态，可以通过串口检察kernel日志，搜索关键字suspend entry检察是否进入就寝。
https://i-blog.csdnimg.cn/direct/a71564d48155450282212047a3da7d57.png
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-0
echo 0x844 > address
echo 4 > count # cat data 00840 -- -- -- -- 0F 07 04 00
echo 0x00 0x00 0x01 0x00 > data
cat data 00840 -- -- -- -- 00 00 01 00
echo 0x00 0x00 0x01 0x80 > data
cat data 00840 -- -- -- -- 00 00 01 80 然后长按下键，会进入download。之后抓取log方法同上
如果进不了download，需要确认
CONFIG_MSM_DLOAD_MODE=y
2.6、检察rmp_stats的状态
1、检查rpm_stats是否进入vdd min大概xo/no shutdown。使用下面的命令检查
rpm lower power mode count:
adb shell mount -t debugfs none /sys/kernel/debug
adb cat /sys/kernel/debug/rpm_stats 如果vmin的count是0，则表明装备从来没有进入vdd min（系统功耗最小化状态），non-zero则说明装备进入过vdd_min。
起首需要相识一下什么XO和VDD min
XO是XTAK Oscillator 石英晶体振荡器，XO提供RF平台BB(基带频率)，WTR(射频收发器),NFC,GPS,FM所需的系统频率；XO shutdown即晶振关闭，这些传感器不工作。
VDD min指最小操作电压，即最低功耗模式。
如果XO shut down计数为零，VDD min计数不断增加，则已经进入了VDD min。
示例：
RPM Mode: xosd
count:0
time in last mode(msec):0
time since last mode(sec):794
actual last sleep(msec):0
RPM Mode:vmin
count:11
time in last mode(msec):0
time since last mode(sec):359
actual last sleep(msec):110000 大概检查以下RPM RAM转储的变量，以确定XO关闭和VDD最小化的计数
– sleep_stats --XO关闭计数（系统进入XO关闭的次数）
– sleep_stats --VDD最小化计数
注意：若系统进入VDD最小化状态，则只有VDD最小化计数会增加。VDD最小化是最低的功耗状态，包括了XO关闭。仅当系统未成功进入VDD最小化而进入XO关闭时，XO关闭计数才会增加
2、系统未进入VDD min怎么办？
如果系统未进入VDD min，则需要检查各个子系统休眠情况，通过检察子系统sleep count命令
cat /sys/power/system_sleep/stats
cat /sys/power/rpmh_stats/master_stats
能看到ADSP MPSS APSS等子系统休眠情况，如果sleep count未发生变革，则对应的子系统未进入休眠。
https://i-blog.csdnimg.cn/direct/3086220f4cb1413eb68fc389b13e42aa.png
3、xo shutdown 和Vdd min计数最小化后就一定表示系统功耗正常了么？
答案是不一定，若终端成功进入VDD最小化后，基底电流仍大于预期值，则可以得出结论，终端中存在一个或多个泄漏源计入总电流斲丧中。泄漏可能有多处泉源，例如
https://i-blog.csdnimg.cn/direct/5faebd71c6e4451fb459c42a64d22d31.png
4、可以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 log
adb logcat -v time -b events > YearMounthDayHourMinute_logcat_event.txt //event log
adb logcat -v time -b radio > YearMounthDayHourMinute_logcat_radio.txt //radio log
adb 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
起首介绍一下什么是wakelock：
他是Android 系统中的一种机制，用于控制装备的电源管理。它可以阻止装备进入休眠状态，从而确保某些任务可以或许在特定条件下完成。（关于wakelock的分类，设置过程以及用法，debug将在上层篇详细介绍。）这里只做简朴的相识。
一般可以通过待机后获取bugreport.txt来看kernel的wakelock，搜索关键字：all kernel
获取bugreport的命令如下：
adb bugreport > bugreport.txt
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.txt
adb pull /data/wakeup_sources.txt 检察pull出来的wakeup sources.txt文件，检察active_since 不为0的项，即为阻止系统休眠的。
下面是wakeup sources日志中的一些解释：
字段描述event_count被信号唤醒的次数 wakeup_count中断suspend的次数expire_count对应wakeup source超时的次数active_since上一次还活跃的时间点.时间单位跟kernel log前缀时间是一样(kernel单调递增时间)total_time对应wakeup source活跃的总时长max_time对应的wakeup source连续活跃最长的一次时间last_change上一次wakeup source变革的时间(从持锁到开释or开释到持锁)，时间单位跟kernel log前缀时间是一样(kernel单调递增时间)prevent_suspend_time对应wakeup source阻止进入autosleep的总累加时间 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 中。
[*] 作用：
通过检察该文件，可以及时相识唤醒源的运动纪录。
3.4、powertop
PowerTOP 是一个由 Intel 开发的 Linux 工具，用于诊断电量斲丧和电源管理的问题。它可以帮助用户识别和优化系统中的电量斲丧，从而延伸笔记本电脑的电池寿命。PowerTOP 不光可以作为一个诊断工具，还可以通过其交互模式启用各种电源管理设置，监控进程并展示电量斲丧特别高的应用步伐。
使用sudo apt install powertop 就可以安装了。
https://i-blog.csdnimg.cn/direct/146b5a7a87a14e3f8e822054ade0d9de.png
获取powertop log的方法：
[*] 通过USB连接手机到电脑
[*] adb shell，然后执行如下命令：
sleep 10 && /data/powertop [-r] -d -t 30 > /data/powertop.log &
[*] 拔掉USB线，等候10秒后开始功耗测试
[*] 插上USB
[*] adb pull /data/powertop.log
3.5、检查系统的alarm
可以使用命令得到android alarms 和statistics
adb dumpsys alarm > alarms.txt enable android debug message in logcat：
setprop persist.alarm.debug 1 3.6、检查kernel timer
可以使用 /proc/timer_stats 这个 sys 节点来获取内核中定时器的统计数据，通过特定的命令，用户可以或许分析定时器的举动，以优化性能或解决问题。
echo 0 > /proc/timer_stats && sleep 10 && echo 1 > /proc/timer_stats && sleep 30 && cat /proc/timer_stats > /data/timer_stats & 3.7、cpu freq log
（1）、打开cpu change log，启动调试日志命令如下
mount -t debugfs none /sys/kernel/debug
cd /sys/kernel/debug
echo -n 'file acpuclock-8x60.c +p' > dynamic_debug/control
echo -n 'file acpuclock-krait.c +p' > dynamic_debug/control （2）、用命令检察cpu 频率状态
cat /sys/devices/system/cpu/cpu0/cpufreq/stats
cat /sys/devices/system/cpu/cpu1/cpufreq/stats
cat /sys/devices/system/cpu/cpu2/cpufreq/stats
cat /sys/devices/system/cpu/cpu3/cpufreq/stats （3）、锁定cpu的频率
echo the same freq to following sys mode will lock cpu freq to the setting freq.
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 未完待续。。
参考链接：
底电流分析-CSDN博客
android 功耗（1）---android 功耗分析方法和优化 - yooooooo - 博客园
高通平台底电流调节心得 - yooooooo - 博客园
高通平台底电流调节心得_高通底电调试-CSDN博客
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]