如果能访问google:直接浏览器打开Battery Historianhttps://batterystats.unicode.org.cn/-------------Linux-----------参考 https://developer.android.com/studio/profile/battery-historian?hlzh_cnInstall Docker Engine on Ubuntu | Docker DocsIndex of linux/ubuntu/dists/xenial/pool/stable/amd64/三个deb都安装验证是否安装好sudo docker run hello-world运行docker run -p port_number:9999 gcr.io/android-battery-historian/stable:3.0 --port 9999然后 在 浏览器打开http://localIP:port_number比如 http://192.168.2.111:8888/开始 battery统计前 运行adb shell dumpsys batterystats --reset结束后adb shell dumpsys batterystats batterystats.txt--------------windows--------------https://www.docker.com/products/docker-desktop/Download Docker Desktop: windows amd64Docker Desktop Installer.exe用管理员身份运行打开 Docker Desktop → 右上角 齿轮Settings左侧选 Resources → Advanced找到 Disk image location磁盘镜像位置把它从 C 盘改成 D 盘windows power shell管理员身份wl --installwsl --update出现提示欢迎使用WSL, 欢迎使用Linux的Windows子系统验证wsl --statuswsl -l -vandroid10以下docker pull registry.cn-hangzhou.aliyuncs.com/xyz10/android-battery-historian:stable-3.0docker run -d -p 9999:9999 registry.cn-hangzhou.aliyuncs.com/xyz10/android-battery-historian:stable-3.0android11及以上docker pull runcare/battery-historian这一步如果有问题打开 Docker Desktop 点右上角 齿轮Settings. 左侧选 Docker Engine . 把右边 JSON 里加上 registry-mirrors如果原来有就替换成下面这些更新的源json {registry-mirrors: [https://docker.xuanyuan.me,https://docker.1ms.run,https://docker.1panel.live,https://hub.rat.dev]}docker run -d -p 9999:9999 runcare/battery-historianhttp://localhost:9999/----------设置 → 开发者选项 → 点“Bug 报告”/“Bug 报告快捷方式”会弹出三个选项互动报告Interactive report点击后才生成完整报告Full report立即生成完整版adb shell dumpsys batterystats --reset# 单独导出更精简的分析文件adb shell dumpsys batterystats batterystats.txt# 看历史每段时间的耗电、唤醒、温度、屏幕状态adb shell dumpsys batterystats --history history.txt:: 1. 先开完整唤醒历史adb shell dumpsys batterystats --enable full-wake-history:: 2. 可选重置让数据从零开始更干净adb shell dumpsys batterystats --reset:: 3. 用一段时间设备然后导出adb shell dumpsys batterystats batterystats.txtadb bugreportz/data/user_de/0/com.android.shell/files/bugreports/bugreport...注意首先查看手机底电流一般在3mA以下如果底电流不对的话查查gpio配置和kernel log需要硬件帮助看看电路图有没有不正确的如上拉下拉电阻是否有漏电。关于电流大的问题这个bugreport是最重要的首先使用battery historian来分析kernel log和main/system log也是必须的 (哪些经常打印甚至有error, kernel log里的pm wakeup)对于WiFi 最好能有air sniffer log和tcpdump对于BT最好能有air sniffer log和hci dump----logcat屏幕变化screen_offscreen_on电量变化battery_levelBatteryController: onReceive:mLevel58,mChargingfalseBatteryController: checkChargingMode batteryStatus BatteryStatus{status3,level58,plugged1,chargingStatus0,maxChargingWattage-1} maxChargingMicroAmp 0 maxChargingMicroVolt 0BatteryControllerLog: Processing BATTERY_CHANGED intent. level58 scale100KeyguardIndication: refreshBatteryInfo isChargingOrFull:false powerPluggedIn:false batteryOverheated:false batteryLevel:59KeyguardUpdateMonitorLog: handleBatteryUpdate: isNotNull: true BatteryStatus{status 2, level50, plugged2, chargingStatus0, maxChargingWattage 7500000}APP触发WIFI传输BatteryStatsImpl: noteWifiRadioApWakeupLocked:uidwakeup sourcesAbort: Pending Wakeup Sources: xxx_rx_wakelock 强调「有一堆待释放的锁」通常伴随多个唤醒源同时挂着Abort: Last active Wakeup Source: xxxx_rx_wakelock 最近一个活跃的唤醒源是 WiFi 接收锁Wakeup reason Abort: Device alarmtimer.0.auto failed to suspend: error -16: 1m 2s 4ms (24 times) realtime 系统想要进入休眠suspend但 alarmtimer 这个内核定时器子系统一直处于「忙」状态下面两个可以看出是哪个APP导致的唤醒wake_locku0a155:xxxx.WakerLockwakeupapu0a155:1. 看「所有 App 的唤醒次数」—— 搜 wakeups直接搜 wakeups会定位到 batterystats 里的这段wakeupapu0a155: wake up application 唤醒是为了哪个应用,把「内核唤醒」和「应用」关联起来的桥梁2. 看「是谁在持锁」—— 搜 wake_lock搜 wake_lock能看到哪个 UID 持了什么锁。wake_locku0a155:xxx.WakerLock3. 看「唤醒原因」—— 搜 wake_reason搜 wake_reason看底层唤醒源sdiohal_irq、rtc 等。4. 看「唤醒源统计」—— 搜 Wakeup Sources 或 WakeupInfo搜 WakeupInfo 或 Abort看内核休眠失败的具体唤醒源。5. 看「WiFi 射频开关」—— 搜 wifi_radio搜 wifi_radiowifi_radio 是开、-wifi_radio 是关。这是 WiFi 唤醒的直接证据。Wifi radio 有颜色绿 WiFi 射频被激活radio on处于可收发状态6. 看「某个具体应用」—— 搜包名能看到这个应用在整份日志里的所有出现位置广播、进程、唤醒等。wakeupsApp 唤醒次数、wifi_radioWiFi 开关、wake_lock持锁、wake_reason唤醒原因、WakeupInfo内核唤醒源u0a155:Wi-Fi network: 1.08MB received, 850.50KB sent (packets 2623 received, 4500 sent)WiFi AP wakeups: 71WiFi Rx time: 1s 613ms (0.0%)WiFi Tx time: 766ms (0.0%)Wake lock *alarm*: 33ms partial (9 times) max18 actual65 realtimeWake lock MicroMsg.WakerLock: 2m 38s 94ms partial (273 times) max1039 actual274400 realtimeTOTAL wake: 2m 38s 162ms blamed partial, 4m 34s 542ms actual partial realtimeForeground services: 16h 8m 17s 62ms realtime (1 times) (running)Fg Service for: 16h 8m 17s 62msDUMP OF SERVICE battery: 电池基本信息DUMP OF SERVICE batterystats: 电池统计主数据Battery History 电池历史事件时间线Estimated power use (mAh) 各应用耗电排行dumpsys jobscheduler → 看有没有周期任务15 分钟级的dumpsys alarm → 看有没有 15 秒级的 alarm这个更可能第 1 层设备睡了没有最关键 看 suspend / resume休眠/唤醒 的切换。关键字 suspend / resume / PM: suspend / abort• 如果 suspend 后很快又 resume说明频繁被唤醒 • 如果出现大量 abort说明想睡但被拦住第 2 层谁把设备叫醒了看 wake_reason 和 wakeup source。关键字wake_reason / Wakeup Sources / WakeupInfo / wakeupap第 3 层谁在持锁不让睡wake_lock / wakelock / suspend blocker1. 先看「唤醒统计」—— 搜 wakeups u0a155: 29 wakeups:谁的 wakeups 次数多谁就是唤醒大户。2. 看「唤醒原因分布」—— 搜 wake_reason wake_reason0:67 sdiohal_irq ← 1028次WiFi中断wake_reason0:...rtc200 ← 139次闹钟统计哪种 wake_reason 最多就知道是 WiFi、闹钟还是别的在唤醒。3. 看「持锁情况」—— 搜 Wake lock .xxxLock: 2m18s (185 times)谁持锁次数多、时间长谁就是「不让设备睡」的元凶。4. 看「前台服务」—— 搜 Foreground services Foreground services: 18h38m31s (3 times)灭屏后还常驻前台服务是耗电的重要信号。5. 看「Doze 状态」—— 搜 Doze 或 deviceidle mStateACTIVE / INACTIVE / IDLE / IDLE_MAINTENANCE设备有没有进入 Doze 深度休眠以及谁打断了 Doze。Battery Historian 里怎么看Kernel only uptime 内核被唤醒的时间越少越好Userspace wakelock 用户空间唤醒锁越少越好Jobscheduler 越少越好Doze 是否进入 Doze被谁打断 Doze 行的蓝色部分就表示「设备进入了 Doze 模式」。Wifi radio / scan WiFi 是否频繁活动 Wifi radio 有颜色绿 WiFi 射频被激活radio on处于可收发状态Wakeup reasons如果有 唤醒原因System Stats:Devices Power Estimates: 看哪个app耗电多Userspace Wakelocks: 看哪个应用wakelock时间长JobScheduler Jobs: 看哪个应用有job scheduler时间长WiFi Traffic Per App: 看哪个应用Wifi传输时间长Kernel Wakeup Reasons: 看kernel哪个中断时间长App Wakeup Alarms: app wakeup次数History Stats:WakeupReasonSummary: 看内核wake up原因哪个中断Apps Stats:Network Information:Wifi data transfersed/Wifi packets transferred/Num of Wifi radio wakeupWakelocks:Wakeup alarm info:Process info: foreground serviceACTIVE活跃↓ 灭屏 静止一段时间Doze / DEVICE_IDLE浅度休眠↓ 进一步静止Deep Doze深度休眠↓ 内核层面Suspend真正挂起CPU 停止 ← 最省电
