第1章电源管理概述

课程目录第1章电源管理概述

一、电源管理概述：Android电源管理架构、Suspend-to-RAM与Suspend-to-Idle模式、电源管理关键组件

各位同学，咱们今天正式进入Android电源管理的世界。说实话，这个领域我刚开始接触的时候也觉得挺玄乎的——手机明明关机了，闹钟还能响；屏幕黑了，WiFi还能下载。这背后到底是谁在干活？今天我们就把它彻底讲透。

1.1 Android电源管理架构：三层分工

Android的电源管理，说白了就是一套「谁该醒、谁该睡、什么时候睡」的调度系统。我个人习惯把它理解成三层架构，每一层各司其职。

核心分层：

Kernel层（内核）：最底层的「守夜人」。负责CPU空闲管理、Suspend/Resume流程、以及最关键的Wakeup源检测。
HAL层（硬件抽象层）：中间的「翻译官」。把内核的电源事件翻译给上层Framework听，比如充电状态、屏幕状态。
Framework层（框架层）：顶层的「指挥官」。管理WakeLock、Doze模式、App Standby等策略。

你想想看，这三层缺一不可。内核不知道上层策略，就会乱睡；Framework不知道硬件状态，就会乱指挥。我在项目中遇到过好几次这样的问题——App申请了WakeLock，但Framework没及时释放，结果手机一晚上掉电20%。嗯，这种坑踩过一次就记住了。

1.2 Suspend-to-RAM vs Suspend-to-Idle

这两个概念，很多工程师容易搞混。我简单给你捋一捋。

特性	Suspend-to-RAM (STR)	Suspend-to-Idle (STI)
CPU状态	完全断电（除了唤醒逻辑）	进入最浅idle状态
内存状态	自刷新保留	正常供电
唤醒延迟	较高（几十ms到几百ms）	极低（us级别）
典型场景	手机合盖、长时间待机	播放音乐、低功耗后台
功耗节省	极高	中等

为什么会这样？STR是把整个系统挂起到内存，CPU几乎完全断电，只留一个唤醒控制器在监听。而STI只是让CPU进入最浅的idle状态，随时可以响应中断。说白了，STR是「深度睡眠」，STI是「打盹」。

我记得有一次调试一个蓝牙耳机的兼容性问题，耳机断开后手机死活不进STR，一查发现是蓝牙控制器一直持有某个唤醒源。当时我就在想——嗯，这要是STI模式，根本不会出这个问题，因为CPU根本没完全断电。

我的建议：如果你的设备对唤醒延迟敏感（比如可穿戴设备），优先考虑STI。如果是手机这种需要极致待机的设备，STR是必选项。但要注意——STR模式下，所有外设驱动必须正确实现suspend/resume回调，否则会出现「睡死」现象。

1.3 电源管理关键组件详解

咱们一个一个来看。这三个组件，你搞懂了，电源管理就算入门了。

1.3.1 Kernel层：真正的「守夜人」

内核里负责电源管理的核心模块叫PM core。它维护着一个全局的suspend流程，大致是这样的：

// 简化的suspend流程伪代码
pm_suspend() {
    // 1. 冻结用户空间进程
    freeze_processes();
    
    // 2. 通知驱动准备suspend
    suspend_prepare();
    
    // 3. 依次suspend所有设备
    dpm_suspend();
    
    // 4. 进入目标睡眠状态
    suspend_enter(state);
    
    // 5. 醒来后反向恢复
    dpm_resume();
    thaw_processes();
}

这里有个关键点——Wakeup源。内核里用struct wakeup_source来管理所有能唤醒系统的硬件事件。比如电源键、USB插入、RTC闹钟等。每个wakeup source都有一个计数器，系统在suspend前会检查这个计数器：如果大于0，说明有事件正在处理，就不允许睡眠。

避坑指南：我曾经遇到过一个case——某个外设驱动在suspend时没有正确释放wakeup source，导致系统永远无法进入深度睡眠。排查了三天，最后发现是驱动里少调了一句__pm_relax()。所以写驱动时，务必成对使用__pm_stay_awake()和__pm_relax()。

1.3.2 HAL层：承上启下的「翻译官」

HAL层主要提供两个接口：IPower HAL和ISuspendControl HAL。前者负责查询电池状态、充电状态；后者负责控制系统的suspend/resume。

说白了，Framework想知道「现在能不能睡？」——它不会直接问内核，而是通过HAL去问。HAL再调用内核的/sys/power/state接口。这样做的好处是：不同厂商的硬件差异被HAL屏蔽了。

举个例子，某厂商的快充芯片在充电时不允许系统进入STR，这个逻辑就写在HAL里。Framework根本不需要知道具体芯片型号。

1.3.3 Framework层：策略制定的「指挥官」

Framework层最核心的就是PowerManagerService。它管理着所有WakeLock的申请和释放。WakeLock分两种：

Partial WakeLock：只阻止CPU睡眠，屏幕可以关。典型场景：后台音乐播放。
Full WakeLock：阻止CPU和屏幕都睡眠。典型场景：视频通话。

你可能会问：那App乱申请WakeLock怎么办？Framework有超时机制——如果一个WakeLock持有超过一定时间（默认6分钟），系统会强制释放。但说实话，这个机制只能防君子不能防小人。有些流氓App会反复申请，导致手机一直处于浅睡眠。

关键点总结：

Kernel管「能不能睡」——检查wakeup source
HAL管「怎么睡」——翻译硬件差异
Framework管「该不该睡」——WakeLock策略

1.4 知识体系结构图

下面这张图，是我自己画的一个整体架构图。你把它存下来，后面每一章都会用到。

这张图里，从上到下是控制流，从下到上是事件流。你仔细看——Framework发指令给HAL，HAL再调内核；反过来，内核检测到Wakeup事件，通过HAL上报给Framework。这就是完整的闭环。

一个小技巧：调试电源问题时，我习惯先看「卡在哪一层」。如果系统无法睡眠，先查内核的/sys/power/wakeup_count，看有没有活跃的wakeup source。如果睡眠后无故唤醒，查Framework的WakeLock日志。如果硬件行为异常，查HAL的dump信息。这样分层排查，效率最高。

好了，第一章的内容就到这里。电源管理这个领域，入门不难，但深入需要大量实践。后面我们会逐一拆解Wakeup源、WakeLock、Doze模式等核心机制。你先把今天这张架构图刻在脑子里，后面的内容都会围绕它展开。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

一、电源管理概述：Android电源管理架构、Suspend-to-RAM与Suspend-to-Idle模式、电源管理关键组件

1.1 Android电源管理架构：三层分工

1.2 Suspend-to-RAM vs Suspend-to-Idle

1.3 电源管理关键组件详解

1.3.1 Kernel层：真正的「守夜人」

1.3.2 HAL层：承上启下的「翻译官」

1.3.3 Framework层：策略制定的「指挥官」

1.4 知识体系结构图