1、Android电源管理概述：Android电源管理架构、Suspend-to-RAM与Suspend-to-Idle的区别、电源管理关键组件（Kernel、HAL、Framework）

好，我们直接进入正题。Android电源管理，说白了就是怎么让手机在不干活的时候省电，干活的时候又能快速响应。我做了这么多年底层驱动，见过太多因为电源管理没做好导致手机发热、待机掉电快的案例。这一章，我们先搭个框架，把整个电源管理体系的脉络理清楚。

1.1 Android电源管理架构

Android的电源管理架构，从上到下分三层：Framework层、HAL层、Kernel层。这三层各司其职，又紧密配合。

我习惯把整个架构想象成一个「接力棒」的传递过程：

• Framework层：负责策略决策。比如屏幕暗了多久才休眠？哪些App可以持有唤醒锁？这些逻辑都在Java层跑。
• HAL层：负责硬件抽象。它把Framework的指令翻译成Kernel能懂的命令。说白了，就是中间翻译官。
• Kernel层：负责具体执行。挂起CPU、关闭外设时钟、保存寄存器状态……这些脏活累活都是它干。

嗯，这里要注意：三层之间不是简单的单向调用。Framework会通过Binder通知HAL，HAL再通过ioctl或sysfs操作Kernel。反过来，Kernel的唤醒事件也会通过HAL上报给Framework。

1.2 Suspend-to-RAM与Suspend-to-Idle的区别

这两个概念，很多工程师容易搞混。我当年刚接触时也踩过坑，以为它们差不多。其实差别很大。

特性	Suspend-to-RAM (STR)	Suspend-to-Idle (STI)
功耗等级	极低（接近关机）	较低（比空闲时略低）
唤醒延迟	高（几百毫秒到秒级）	低（几毫秒到几十毫秒）
CPU状态	完全断电（仅保留内存自刷新）	CPU仍在低功耗模式（WFI）
适用场景	长时间待机（如手机锁屏后）	短时空闲（如播放音乐时）
实现复杂度	高（需处理外设恢复）	低（内核自动管理）

为什么会这样？你想想看：STR模式下，CPU几乎完全断电，只有内存还在自刷新。这意味着所有外设都要重新初始化。我曾经在项目中遇到过一个问题——WiFi模块在STR唤醒后死活连不上，查了两天才发现是电源域没完全恢复。

而STI模式，说白了就是CPU进入WFI（Wait For Interrupt）状态，时钟频率降到最低，但内核还在跑。中断来了就能立刻响应。所以适合那些需要快速响应的场景，比如音乐播放器切歌。

1.3 电源管理关键组件：Kernel、HAL、Framework

我们逐个拆开来看。每个组件都有自己的「脾气」，摸透了才能调好。

1.3.1 Kernel层

Kernel是电源管理的「执行者」。核心机制包括：

• suspend/resume流程：内核通过pm_suspend()函数触发挂起，依次冻结进程、暂停设备、关闭中断。唤醒时反向操作。
• wakeup source：每个设备可以注册为唤醒源，比如电源键、USB插入。内核会维护一个唤醒源列表，防止误唤醒。
• CPU idle governor：决定CPU在空闲时进入哪个C-state（C1/C2/C3）。我习惯用menu governor，它在延迟和功耗之间平衡得不错。

// 一个典型的suspend流程（简化版）
static int my_suspend(struct device *dev)
{
    // 保存硬件状态
    dev->regs_saved = readl(dev->base + REG_CTRL);
    // 关闭时钟
    clk_disable(dev->clk);
    return 0;
}

static int my_resume(struct device *dev)
{
    // 恢复时钟
    clk_enable(dev->clk);
    // 恢复硬件状态
    writel(dev->regs_saved, dev->base + REG_CTRL);
    return 0;
}

1.3.2 HAL层

HAL层是「翻译官」。它把Framework的电源管理请求，转换成Kernel能理解的sysfs操作或ioctl命令。

常见的HAL模块包括：

• Power HAL：处理屏幕亮度、CPU频率调节等。
• Light HAL：控制LED指示灯。
• Suspend HAL：负责与Kernel的autosleep机制交互。

我个人习惯在HAL层加一些调试日志，比如记录每次suspend/resume的耗时。这样在性能调优时，能快速定位是哪个环节拖了后腿。

1.3.3 Framework层

Framework是「决策者」。它管理着两个核心机制：

• WakeLock：App可以申请WakeLock来阻止系统休眠。比如视频播放器在播放时持有一个PARTIAL_WAKE_LOCK。
• Doze模式：Android 6.0引入的深度休眠模式。屏幕关闭一段时间后，系统会限制App的网络和CPU访问。

嗯，这里有个常见问题：有些App滥用WakeLock，导致手机无法进入休眠。我建议在调试阶段用dumpsys power命令查看WakeLock持有情况。

// 查看当前WakeLock状态
adb shell dumpsys power | grep -i wakelock

好了，这一章我们搭好了电源管理的整体框架。下一章，我会深入Kernel的suspend/resume代码，带你看清楚每一行代码背后的硬件行为。