2. Android电源管理架构：从上层到底层的功耗博弈
做功耗分析这些年，我最大的感受就是：Android的电源管理，本质上是一场「性能」与「续航」的博弈。你想想看，手机既要跑得快，又要用得久，这本身就是一对矛盾体。而Android系统从上层到内核，设计了一整套机制来平衡这个矛盾。
今天我们就来拆解这套架构。我会从上层应用层往下讲，一直深入到Linux内核。嗯，这样你就能理解，一个触摸事件、一个后台任务，到底是怎么影响手机功耗的。
2.1 PowerManager：用户空间的功耗指挥官
先说说最上层的PowerManager。这是Android Framework层提供给App的接口。说白了，App想「保持屏幕常亮」、「防止系统休眠」，都得通过它来申请。
我个人习惯把PowerManager看作一个「资源调度中心」。它不直接控制硬件，而是通过管理各种锁和状态，来协调系统何时休眠、何时唤醒。
- 管理屏幕亮度、超时时间
- 处理WakeLock的申请与释放
- 协调Doze模式、App Standby等省电策略
- 监听用户交互事件（亮屏、按键等）
举个例子，你打开视频App看电影，App会申请一个SCREEN_BRIGHT_WAKE_LOCK。这时候PowerManager就会告诉系统：「别关屏，用户在看片呢」。一旦你退出App，锁释放了，系统才能正常进入休眠。
我在项目中遇到过一个问题：某个第三方App申请了WakeLock但忘记释放，导致手机一晚上掉电30%。后来我们用dumpsys power一查，锁的持有时间长达8小时。嗯，这就是典型的「锁滥用」问题。
2.2 WakeLock：一把双刃剑
WakeLock是功耗分析中最常打交道的机制。它允许App阻止系统进入休眠状态。但用不好，就是耗电元凶。
WakeLock分为几种类型：
| 类型 | 作用 | 功耗影响 |
|---|---|---|
| PARTIAL_WAKE_LOCK | 保持CPU运行，屏幕可关闭 | 中等 |
| SCREEN_DIM_WAKE_LOCK | 保持屏幕亮（暗光） | 较高 |
| SCREEN_BRIGHT_WAKE_LOCK | 保持屏幕全亮 | 高 |
| FULL_WAKE_LOCK | 保持屏幕和键盘全亮 | 最高 |
FULL_WAKE_LOCK。其实它只需要PARTIAL_WAKE_LOCK来保持CPU运行就够了。这种过度申请，直接导致续航缩短了15%。所以，能用低功耗锁，就别用高功耗锁。
检查WakeLock的方法很简单：
adb shell dumpsys power | grep "LOCK"这条命令会列出当前所有活跃的WakeLock，以及它们的持有时间和持有者。我每次做功耗分析，第一步就是跑这个命令。
2.3 Doze模式：Android的深度睡眠
Doze模式是Android 6.0引入的省电大招。它的思路很简单：当手机长时间静止且屏幕关闭时，系统会进入一种「半休眠」状态。
在Doze模式下，系统会做以下几件事：
- 限制App访问网络（Wi-Fi和移动数据）
- 延迟后台任务和同步操作
- 合并唤醒闹钟（Alarm），减少唤醒次数
- 禁止App获取位置更新
你可能会问：「那消息推送怎么办？」嗯，Doze模式会留一个「维护窗口」（Maintenance Window）。系统会定期（比如每几分钟）退出Doze，让App处理紧急任务，然后再次进入。这个窗口很短，但足够处理推送消息了。
PARTIAL_WAKE_LOCK来绕过Doze限制。这时候就需要用dumpsys deviceidle来排查了。
2.4 App Standby：给不常用的App「断水断电」
App Standby是Doze模式的补充。它针对的是那些「用户很久没打开过的App」。系统会把这些App标记为「待机状态」，然后限制它们的后台活动。
判断标准很简单：如果某个App超过一定时间（默认是1小时）没有被用户主动打开，系统就会把它加入待机列表。
处于待机状态的App会：
- 网络访问被延迟
- 后台任务被推迟
- Alarm被合并或延迟
一旦用户重新打开这个App，它就会立即退出待机状态。这个机制很聪明——你想想看，那些装了一堆但从来不用的App，如果还让它们在后台乱跑，那不是白白耗电吗？
我曾经用adb shell dumpsys appops查看过，发现某款购物App在用户一周没打开的情况下，还在后台频繁请求位置。App Standby直接把它「关禁闭」了，功耗立刻降了下来。
2.5 Linux内核电源管理：CPUIdle与CPUFreq
说完了上层，我们往下走。Android的电源管理，最终要落到Linux内核上。这里有两个核心机制：CPUIdle和CPUFreq。
2.5.1 CPUIdle：让CPU「打盹」
CPUIdle管理的是CPU的空闲状态。当CPU没有任务可执行时，它会进入不同的空闲等级（C-State）。等级越高，功耗越低，但唤醒延迟也越大。
| C-State | 描述 | 功耗 | 唤醒延迟 |
|---|---|---|---|
| C0 | 运行状态 | 高 | 0 |
| C1 | 暂停（Halt） | 较低 | 几微秒 |
| C2 | 停止时钟 | 更低 | 几十微秒 |
| C3 | 深度睡眠 | 极低 | 几百微秒 |
说白了，CPUIdle就是让CPU在没事干的时候「打盹」。打盹越深，省电越多，但醒过来也越慢。系统会根据当前负载和唤醒需求，动态选择合适的C-State。
adb shell cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name这条命令会列出每个CPU核心支持的空闲状态。
2.5.2 CPUFreq：动态调频
CPUFreq管理的是CPU的运行频率。它根据系统负载，动态调整CPU的频率和电压。负载高时升频，负载低时降频。
常见的调频策略有：
- performance：始终最高频率，性能优先
- powersave：始终最低频率，省电优先
- ondemand：按需调频，负载高时升频
- interactive：根据用户交互行为调频（Android常用）
- schedutil：基于调度器负载调频（新内核推荐）
我个人比较推荐schedutil策略。它直接利用调度器的负载信息来做调频决策，响应更快，也更省电。我在一个项目中，把调频策略从interactive切换到schedutil后，中度使用场景的续航提升了约8%。
2.6 Suspend/Resume：系统的「睡眠与苏醒」
最后说说Suspend/Resume机制。这是系统级的休眠与唤醒流程。当用户按下电源键关屏，系统会进入Suspend状态；按下电源键亮屏，系统会Resume。
Suspend的流程大致是：
- 用户关屏，系统进入Suspend准备
- 冻结所有用户空间进程
- 暂停所有设备驱动
- CPU进入深度空闲状态
- 内存保持自刷新（Self-Refresh）
Resume的流程则相反：
- 检测到唤醒事件（如按键、来电）
- CPU从空闲状态唤醒
- 恢复设备驱动
- 解冻用户空间进程
- 系统恢复正常运行
这里有个关键点：唤醒源。哪些设备可以唤醒系统？比如电源键、RTC闹钟、USB插入、来电等。如果某个外设频繁触发唤醒，就会导致系统无法深度休眠，功耗居高不下。
adb shell dumpsys power | grep "Wakeup"可以查看最近的唤醒源。我曾经发现某款手机的Wi-Fi模块每30秒就唤醒一次系统，原因是路由器信号不稳定导致Wi-Fi频繁重连。后来调整了Wi-Fi的省电参数，问题才解决。
2.7 小结：从上层到底层的功耗链路
好了，我们来捋一捋这条链路：
- App层：通过PowerManager申请WakeLock，控制屏幕和CPU状态
- Framework层：PowerManager协调Doze模式、App Standby，管理锁的释放
- 内核层：CPUIdle管理空闲状态，CPUFreq管理运行频率，Suspend/Resume控制系统休眠
你想想看，一个简单的「关屏」操作，背后是这么多层机制在协同工作。任何一个环节出了问题，都会反映到功耗上。
做功耗分析，就是要学会从上层往下层追查。先看App有没有滥用WakeLock，再看Doze模式有没有生效，最后看内核的CPUIdle和CPUFreq配置是否合理。嗯，这套方法论，我用了好几年，屡试不爽。
下一章，我们会深入实战，教你如何用dumpsys和systrace来定位具体的功耗问题。到时候，我们拿一台真机来跑一遍流程。