13、车载电源管理：CarPowerManager、电源策略、休眠唤醒、低功耗模式
车载电源管理，说白了就是让车机系统“该睡睡，该醒醒”。
我刚开始接触 Android Automotive 时，觉得电源管理不就是个休眠唤醒吗？后来在实车项目上被坑过几次，才明白这里面的门道有多深。你想想看，车机不像手机，手机没电了可以随时充，车机要是电源策略没做好，可能导致电瓶亏电、黑屏死机，甚至影响行车安全。
这一章，我就把车载电源管理的核心知识点掰开揉碎了讲给你听。
13.1 车载电源状态机：从 ON 到 OFF 的完整链路
车载电源管理的基础，是一套清晰的状态机。Android Automotive 定义了几个关键电源状态：
- ON：全功能运行，屏幕亮，所有服务可用。
- SHUTDOWN：系统正常关机，保存数据，关闭硬件。
- SLEEP：浅度休眠，CPU 暂停，内存保持，可快速唤醒。
- DEEP_SLEEP：深度休眠，大部分硬件断电，仅保留唤醒源。
- BATTERY_SAVER：低电量模式，限制后台活动，降低功耗。
这些状态之间的切换，不是随意的。系统会根据车辆点火信号、用户操作、定时器、网络事件等触发条件，走一条固定的路径。
核心要点：电源状态切换必须保证数据一致性。我在项目中遇到过，SLEEP 状态下没来得及保存日志，导致下次启动时日志文件损坏。后来我们强制在进入 SLEEP 前做一次 flush。
下面这张图，是我自己整理的电源状态流转图，你看一眼就明白了：
13.2 CarPowerManager：电源管理的“遥控器”
CarPowerManager 是 Android Automotive 提供给上层应用的电源管理 API。它不像系统服务那样直接操作硬件，而是通过一组接口，让应用感知和响应电源状态变化。
我个人习惯把 CarPowerManager 比作“遥控器”——你不需要知道电视内部怎么工作的，按一下开关就行。
13.2.1 核心接口
| 接口 | 说明 | 使用场景 |
|---|---|---|
getPowerState() |
获取当前电源状态 | 应用启动时判断是否处于低功耗模式 |
addPowerStateListener() |
注册电源状态监听 | 需要根据电源状态调整行为的应用 |
requestWakeUp() |
请求唤醒系统 | 导航、电话等需要立即响应的场景 |
setPowerPolicy() |
设置电源策略 | 系统服务调整功耗模式 |
小提示：addPowerStateListener 的回调是在主线程执行的。如果你在回调里做耗时操作，记得切到子线程。我曾经见过一个音乐应用，在电源状态回调里直接写数据库，导致界面卡顿了好几秒。
13.2.2 代码示例：监听电源状态
// 获取 CarPowerManager 实例
CarPowerManager powerManager = new CarPowerManager(car);
// 注册电源状态监听
powerManager.addPowerStateListener(new CarPowerManager.PowerStateListener() {
@Override
public void onPowerStateChanged(int state) {
switch (state) {
case CarPowerManager.STATE_ON:
// 全功能运行
Log.d("PowerDemo", "系统已唤醒，进入正常模式");
break;
case CarPowerManager.STATE_SLEEP:
// 浅度休眠，保存状态
Log.d("PowerDemo", "系统即将休眠，保存当前状态");
saveAppState();
break;
case CarPowerManager.STATE_DEEP_SLEEP:
// 深度休眠，释放资源
Log.d("PowerDemo", "深度休眠，释放非必要资源");
releaseResources();
break;
case CarPowerManager.STATE_BATTERY_SAVER:
// 低电量模式，降低功耗
Log.d("PowerDemo", "低电量模式，降低刷新率");
reduceRefreshRate();
break;
}
}
});13.3 电源策略：谁来决定什么时候睡？
电源策略，就是一套规则集。它告诉系统：什么时候可以睡，什么时候必须醒，醒了之后能干什么。
Android Automotive 的电源策略是分层设计的：
- 系统级策略：由 CarService 管理，定义全局的电源状态转换规则。
- 应用级策略：由各个应用自己决定，比如导航应用可以阻止系统休眠。
- 硬件级策略：由 HAL 层实现，控制具体的硬件电源。
这里有个关键点：应用级策略不能覆盖系统级策略。比如，即使导航应用请求不休眠，如果系统检测到电瓶电压过低，还是会强制进入休眠。
注意：不要滥用 requestWakeUp()。每次唤醒都会消耗电量。我曾经在项目中看到某个第三方应用每 5 秒请求一次唤醒，导致车机在休眠状态下电量消耗异常。后来我们加了一个白名单机制，只有系统应用才能调用这个接口。
13.4 休眠与唤醒：从按下熄火到再次启动
休眠唤醒的流程，是车载电源管理中最容易出问题的环节。我把它拆成三个阶段来讲：
13.4.1 休眠阶段
- 触发条件：ACC OFF、用户长按电源键、定时休眠。
- 通知应用：CarPowerManager 广播 STATE_SLEEP 或 STATE_DEEP_SLEEP。
- 保存状态：应用保存当前数据，释放资源。
- 冻结进程：系统冻结非必要进程，停止后台活动。
- 关闭硬件：屏幕、Wi-Fi、蓝牙等外设断电。
- 进入休眠：CPU 进入低功耗模式，等待唤醒源。
嗯，这里要注意：休眠阶段的超时时间很关键。如果应用在收到通知后迟迟不响应，系统会强制进入休眠。我建议你在应用里设置一个 2 秒的保存超时，超时后直接放弃。
13.4.2 唤醒阶段
- 唤醒源触发：ACC ON、CAN 总线信号、定时器、网络数据。
- 硬件上电：CPU、内存、外设依次上电。
- 恢复进程：系统恢复冻结的进程。
- 通知应用：CarPowerManager 广播 STATE_ON。
- 恢复状态：应用恢复之前保存的数据。
唤醒阶段最容易踩的坑是“唤醒风暴”——多个唤醒源同时触发，导致系统反复唤醒。我曾经在调试时遇到过，GPS 模块和蓝牙模块同时唤醒，系统在 1 秒内被唤醒了 3 次，功耗反而比正常运行时还高。
13.5 低功耗模式：省电与功能的平衡
低功耗模式（BATTERY_SAVER）不是简单的“关掉所有功能”。它需要在不影响核心功能的前提下，尽可能降低功耗。
我总结了几条低功耗模式下的策略：
- 降低屏幕亮度：屏幕是耗电大户，降低到 30% 以下。
- 关闭动画：窗口动画、过渡动画全部禁用。
- 限制后台活动：非前台应用暂停网络请求、位置更新。
- 降低刷新率：从 60Hz 降到 30Hz 甚至 15Hz。
- 关闭非必要服务：语音助手、在线音乐等后台服务暂停。
核心原则：低功耗模式下，安全相关功能（如倒车影像、碰撞预警）必须保持可用。我在项目中遇到过，低功耗模式下倒车影像延迟了 500ms，差点导致事故。从那以后，我们给安全功能加了一个“免休眠”标签。
13.6 实战避坑指南
最后，分享几个我在项目中踩过的坑：
- 不要依赖电源状态回调的时序：不同 Android 版本的回调顺序可能不同。我建议你在应用启动时主动查询一次电源状态，而不是只依赖回调。
- 休眠前一定要 flush 数据：文件系统在休眠时可能被冻结，未 flush 的数据会丢失。我习惯在 onPowerStateChanged 里调用 fsync。
- 唤醒后不要立即做大量计算：CPU 刚从休眠中恢复，频率还没上来。如果一唤醒就做大量计算，可能导致系统卡顿。我建议加一个 500ms 的延迟。
- 测试要覆盖边界情况：比如在休眠过程中突然 ACC ON，或者在低电量模式下请求唤醒。这些边界情况最容易出 bug。
车载电源管理，说难不难，说简单也不简单。核心就是理解状态机、用好 CarPowerManager、做好策略平衡。你只要把这一章的内容吃透了，大部分电源相关的问题都能应对。
个人经验：我建议你在开发阶段就接入电源管理 API，不要等到最后再适配。早期适配可以提前发现很多问题，比如某个服务在休眠时没有释放 wakelock，导致系统无法进入深度休眠。这种问题越早发现，改起来越轻松。
公众号:蓝海资料掘金营，微信deep3321