2、电源管理架构：Android电源管理子系统深度解析
说到Android的续航优化，咱们得先搞清楚系统是怎么管电的。我刚开始做功耗优化那会儿，上来就盯着App的代码看，结果折腾半天发现方向完全错了。后来才明白——你得先懂电源管理架构，才知道从哪儿下手。
Android的电源管理子系统，说白了就是一套「谁可以唤醒系统、谁在耗电、耗了多少」的监控体系。它主要由三个核心模块组成：PowerManager、WakeLock 和 BatteryStats。咱们一个一个拆开讲。
2.1 PowerManager：电源管理的总指挥
PowerManager是系统服务，App通过它来申请电源相关的操作。你可以把它理解成「电源管家」——App想亮屏、想保持CPU运行、想降低性能，都得通过它来申请。
我个人习惯把PowerManager的核心能力分成三类：
- 屏幕控制：亮屏、息屏、调节亮度
- 性能控制：设置CPU频率、调度策略
- 休眠控制：阻止系统休眠、唤醒系统
举个例子，你写一个导航App，需要屏幕常亮。代码里会这么写：
PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(
PowerManager.SCREEN_BRIGHT_WAKE_LOCK |
PowerManager.ACQUIRE_CAUSES_WAKEUP,
"MyApp:NavigationWakeLock");
wl.acquire();嗯，这里要注意——ACQUIRE_CAUSES_WAKEUP 这个flag，它会让屏幕立即亮起。如果你只是想让屏幕保持常亮，但不需要唤醒，就别加这个flag。我在项目中遇到过，有个同事在后台音乐播放时用了这个flag，结果手机放口袋里屏幕一直亮着，半天就没电了。
2.2 WakeLock：锁住系统不让他睡
WakeLock，直译就是「唤醒锁」。它的作用很简单——告诉系统「我现在有事，你别睡」。但问题就出在这里：很多App滥用WakeLock，导致系统一直醒着，续航自然就崩了。
WakeLock有几种类型，我整理了一张表：
| 类型 | CPU | 屏幕 | 键盘灯 | 典型场景 |
|---|---|---|---|---|
| PARTIAL_WAKE_LOCK | 保持运行 | 可关闭 | 可关闭 | 后台下载、音乐播放 |
| SCREEN_DIM_WAKE_LOCK | 保持运行 | 变暗 | 可关闭 | 视频播放、导航 |
| SCREEN_BRIGHT_WAKE_LOCK | 保持运行 | 亮屏 | 可关闭 | 需要用户交互的场景 |
| FULL_WAKE_LOCK | 保持运行 | 亮屏 | 亮灯 | 游戏、全屏应用 |
| PROXIMITY_SCREEN_OFF_WAKE_LOCK | 保持运行 | 可关闭 | 可关闭 | 通话时靠近脸部息屏 |
你想想看，如果一个App在后台下载文件，它只需要CPU保持运行就够了，屏幕完全可以关掉。但有些App偷懒，直接申请了FULL_WAKE_LOCK，这就白白浪费了屏幕的电量。
为什么会这样？说白了，很多开发者对WakeLock的理解停留在「能用就行」的层面。我建议你在开发时遵循一个原则：用最小权限的WakeLock，用最短的时间。
2.3 BatteryStats：电量消耗的记账本
BatteryStats是Android系统内置的电量统计服务。它记录了每个App、每个硬件模块的耗电情况。你可以通过 dumpsys batterystats 命令来查看。
我个人习惯在分析续航问题时，先跑一遍这个命令：
adb shell dumpsys batterystats --reset // 先重置统计
// 然后正常使用手机一段时间
adb shell dumpsys batterystats > battery.txt打开battery.txt，你会看到类似这样的信息：
Estimated power use (mAh):
Screen: 120.0
Wifi: 45.0
com.example.app: 89.0
Wake lock: 23.0
CPU: 45.0
Network: 21.0嗯，这里要注意——BatteryStats的数据是估算值，不是精确测量。但它能帮你快速定位问题。比如上面这个例子，com.example.app的WakeLock耗电占了总耗电的26%，明显有问题。
我记得有一次，一个用户反馈手机待机一晚上掉电30%。我通过BatteryStats发现，有个App的WakeLock持续了整整8小时。进一步排查发现，是它的推送服务在断网重连时，忘记释放WakeLock了。
2.4 三者如何协同工作？
讲完了三个模块，咱们来串一下它们的关系：
- App通过PowerManager申请WakeLock，告诉系统「我需要保持运行」。
- 系统根据WakeLock的类型和数量，决定是否进入休眠状态。
- BatteryStats记录整个过程，包括谁申请了WakeLock、申请了多久、消耗了多少电量。
说白了，PowerManager是「开关」，WakeLock是「锁」，BatteryStats是「账本」。你优化续航，就是要减少不必要的「锁」，同时通过「账本」找到那些乱上锁的App。
我建议你在做系统优化时，重点关注以下几点：
- WakeLock的超时机制：申请WakeLock时，尽量设置超时时间，防止忘记释放。
- BatteryStats的定期分析：每周跑一次dumpsys，看看有没有异常的WakeLock持有者。
- PowerManager的API调用规范：团队内部统一使用封装好的工具类，避免直接操作PowerManager。
好了，这一章的内容就到这里。电源管理架构是续航优化的基础，你只有理解了这三个模块是怎么配合的，才能在后面对症下药。下一章，咱们聊聊具体的优化手段——怎么从代码层面减少不必要的功耗。