拓冰网站定制 
10.1 自动化功耗测试脚本手动测功耗说实话一次两次还行迭代个几十次你肯定崩溃。我习惯写一个 shell 脚本把整个流程串起来。先看一个最基础的脚本框架#!/bin/bash # 自动化功耗采集脚本 - 基础版 DEVICE_SERIALyour_device_serial OUTPUT_DIR./power_data TIMESTAMP$(date %Y%m%d_%H%M%S) # 创建输出目录 mkdir -p $OUTPUT_DIR # 1. 清除旧数据 adb -s $DEVICE_SERIAL shell dumpsys batterystats --reset # 2. 启动待测场景 echo 启动待测场景... adb -s $DEVICE_SERIAL shell am start -W com.example.app/.MainActivity # 3. 等待场景稳定我一般等5秒 sleep 5 # 4. 开始采集 echo 开始采集功耗数据... for i in {1..10}; do adb -s $DEVICE_SERIAL shell dumpsys power $OUTPUT_DIR/power_${TIMESTAMP}_${i}.txt sleep 2 done # 5. 采集电池统计 adb -s $DEVICE_SERIAL shell dumpsys batterystats $OUTPUT_DIR/battery_${TIMESTAMP}.txt echo 采集完成数据保存在 $OUTPUT_DIR这个脚本干了五件事重置数据、启动应用、等待稳定、循环采集、保存结果。每次采集前先执行adb shell dumpsys batterystats --reset不然你会拿到一堆历史数据根本分不清哪些是当前场景的。10.2 adb shell dumpsys power 深度解析adb shell dumpsys power会输出一大堆东西。我帮你拆解一下核心字段字段含义重点关注mWakefulness设备唤醒状态Asleep 表示休眠Awake 表示唤醒mScreenOn屏幕是否点亮true 时功耗会高很多mWakeLocks当前持有的唤醒锁这里经常有异常持锁的情况mDisplayPowerState显示电源状态ON/OFF/DOZE 三种状态mBatteryLevel当前电量百分比用于计算功耗变化为什么会关注 mWakeLocks我在项目里遇到过某个第三方 SDK 在后台持了一个 PARTIAL_WAKE_LOCK导致设备无法进入深度休眠。一晚上掉电 30%用户直接炸了。避坑指南我曾经因为没注意 mWakefulness 字段采集了一堆假数据。设备其实已经休眠了但我以为还在跑测试场景。采集前先检查 mWakefulness 是不是预期的状态。10.3 功耗数据格式化与存储原始数据是文本没法直接分析。我一般会写个 Python 脚本做格式化import re import json from datetime import datetime def parse_power_dump(raw_text): 解析 dumpsys power 输出 result {} # 提取唤醒状态 wake_match re.search(rmWakefulness(\w), raw_text) if wake_match: result[wakefulness] wake_match.group(1) # 提取屏幕状态 screen_match re.search(rmScreenOn(\w), raw_text) if screen_match: result[screen_on] screen_match.group(1) true # 提取唤醒锁 locks re.findall(rLock\{(.?)\}, raw_text) result[wake_locks] locks # 提取电量 battery_match re.search(rmBatteryLevel(\d), raw_text) if battery_match: result[battery_level] int(battery_match.group(1)) # 添加时间戳 result[timestamp] datetime.now().isoformat() return result # 使用示例 with open(power_20240101_120000_1.txt, r) as f: raw f.read() parsed parse_power_dump(raw) print(json.dumps(parsed, indent2, ensure_asciiFalse))格式化之后的数据长这样{ wakefulness: Awake, screen_on: true, wake_locks: [ PARTIAL_WAKE_LOCK:com.example.app ], battery_level: 85, timestamp: 2024-01-01T12:00:05 }我习惯存成 JSON 格式方便后续做趋势分析。你想想看如果你有 100 次测试的数据用 JSON 存起来写个脚本就能画出功耗曲线图多直观。存储建议按日期建文件夹比如power_data/2024/01/01/文件名包含场景标识比如video_playback_001.json每个 JSON 文件包含元数据设备型号、系统版本、测试场景10.4 完整的数据采集流程把上面这些串起来就是一个完整的自动化流程#!/bin/bash # 完整版自动化采集脚本 SCENE$1 # 场景名称比如 video_playback DURATION$2 # 采集时长单位秒 OUTPUT_BASE./power_data/$(date %Y/%m/%d) mkdir -p $OUTPUT_BASE echo 开始采集: $SCENE # 重置电池统计 adb shell dumpsys batterystats --reset # 启动场景 adb shell am start -W com.example.app/.$SCENE sleep 3 # 循环采集 END$((SECONDS DURATION)) while [ $SECONDS -lt $END ]; do TIMESTAMP$(date %H%M%S) adb shell dumpsys power $OUTPUT_BASE/${SCENE}_${TIMESTAMP}.txt # 顺便采集电池详情 adb shell dumpsys batterystats $OUTPUT_BASE/${SCENE}_battery_${TIMESTAMP}.txt sleep 2 done echo 采集完成 echo 数据保存在: $OUTPUT_BASE使用方式./collect_power.sh video_playback 60这条命令会采集 60 秒的视频播放功耗数据每 2 秒一次快照。我个人觉得这个频率比较合适太快了数据冗余太慢了抓不到关键变化。小技巧采集完成后用adb shell dumpsys batterystats --reset再清一次数据避免影响下一次测试。我吃过这个亏两次测试的数据混在一起排查了半天。10.5 知识体系总览下面这张图帮你理清本章的核心逻辑 10、功耗数据采集：自动化测试脚本与数据格式化
10.1 自动化功耗测试脚本手动测功耗说实话一次两次还行迭代个几十次你肯定崩溃。我习惯写一个 shell 脚本把整个流程串起来。先看一个最基础的脚本框架#!/bin/bash # 自动化功耗采集脚本 - 基础版 DEVICE_SERIALyour_device_serial OUTPUT_DIR./power_data TIMESTAMP$(date %Y%m%d_%H%M%S) # 创建输出目录 mkdir -p $OUTPUT_DIR # 1. 清除旧数据 adb -s $DEVICE_SERIAL shell dumpsys batterystats --reset # 2. 启动待测场景 echo 启动待测场景... adb -s $DEVICE_SERIAL shell am start -W com.example.app/.MainActivity # 3. 等待场景稳定我一般等5秒 sleep 5 # 4. 开始采集 echo 开始采集功耗数据... for i in {1..10}; do adb -s $DEVICE_SERIAL shell dumpsys power $OUTPUT_DIR/power_${TIMESTAMP}_${i}.txt sleep 2 done # 5. 采集电池统计 adb -s $DEVICE_SERIAL shell dumpsys batterystats $OUTPUT_DIR/battery_${TIMESTAMP}.txt echo 采集完成数据保存在 $OUTPUT_DIR这个脚本干了五件事重置数据、启动应用、等待稳定、循环采集、保存结果。每次采集前先执行adb shell dumpsys batterystats --reset不然你会拿到一堆历史数据根本分不清哪些是当前场景的。10.2 adb shell dumpsys power 深度解析adb shell dumpsys power会输出一大堆东西。我帮你拆解一下核心字段字段含义重点关注mWakefulness设备唤醒状态Asleep 表示休眠Awake 表示唤醒mScreenOn屏幕是否点亮true 时功耗会高很多mWakeLocks当前持有的唤醒锁这里经常有异常持锁的情况mDisplayPowerState显示电源状态ON/OFF/DOZE 三种状态mBatteryLevel当前电量百分比用于计算功耗变化为什么会关注 mWakeLocks我在项目里遇到过某个第三方 SDK 在后台持了一个 PARTIAL_WAKE_LOCK导致设备无法进入深度休眠。一晚上掉电 30%用户直接炸了。避坑指南我曾经因为没注意 mWakefulness 字段采集了一堆假数据。设备其实已经休眠了但我以为还在跑测试场景。采集前先检查 mWakefulness 是不是预期的状态。10.3 功耗数据格式化与存储原始数据是文本没法直接分析。我一般会写个 Python 脚本做格式化import re import json from datetime import datetime def parse_power_dump(raw_text): 解析 dumpsys power 输出 result {} # 提取唤醒状态 wake_match re.search(rmWakefulness(\w), raw_text) if wake_match: result[wakefulness] wake_match.group(1) # 提取屏幕状态 screen_match re.search(rmScreenOn(\w), raw_text) if screen_match: result[screen_on] screen_match.group(1) true # 提取唤醒锁 locks re.findall(rLock\{(.?)\}, raw_text) result[wake_locks] locks # 提取电量 battery_match re.search(rmBatteryLevel(\d), raw_text) if battery_match: result[battery_level] int(battery_match.group(1)) # 添加时间戳 result[timestamp] datetime.now().isoformat() return result # 使用示例 with open(power_20240101_120000_1.txt, r) as f: raw f.read() parsed parse_power_dump(raw) print(json.dumps(parsed, indent2, ensure_asciiFalse))格式化之后的数据长这样{ wakefulness: Awake, screen_on: true, wake_locks: [ PARTIAL_WAKE_LOCK:com.example.app ], battery_level: 85, timestamp: 2024-01-01T12:00:05 }我习惯存成 JSON 格式方便后续做趋势分析。你想想看如果你有 100 次测试的数据用 JSON 存起来写个脚本就能画出功耗曲线图多直观。存储建议按日期建文件夹比如power_data/2024/01/01/文件名包含场景标识比如video_playback_001.json每个 JSON 文件包含元数据设备型号、系统版本、测试场景10.4 完整的数据采集流程把上面这些串起来就是一个完整的自动化流程#!/bin/bash # 完整版自动化采集脚本 SCENE$1 # 场景名称比如 video_playback DURATION$2 # 采集时长单位秒 OUTPUT_BASE./power_data/$(date %Y/%m/%d) mkdir -p $OUTPUT_BASE echo 开始采集: $SCENE # 重置电池统计 adb shell dumpsys batterystats --reset # 启动场景 adb shell am start -W com.example.app/.$SCENE sleep 3 # 循环采集 END$((SECONDS DURATION)) while [ $SECONDS -lt $END ]; do TIMESTAMP$(date %H%M%S) adb shell dumpsys power $OUTPUT_BASE/${SCENE}_${TIMESTAMP}.txt # 顺便采集电池详情 adb shell dumpsys batterystats $OUTPUT_BASE/${SCENE}_battery_${TIMESTAMP}.txt sleep 2 done echo 采集完成 echo 数据保存在: $OUTPUT_BASE使用方式./collect_power.sh video_playback 60这条命令会采集 60 秒的视频播放功耗数据每 2 秒一次快照。我个人觉得这个频率比较合适太快了数据冗余太慢了抓不到关键变化。小技巧采集完成后用adb shell dumpsys batterystats --reset再清一次数据避免影响下一次测试。我吃过这个亏两次测试的数据混在一起排查了半天。10.5 知识体系总览下面这张图帮你理清本章的核心逻辑