5、电源管理策略：车载环境下的电源状态机（睡眠、唤醒、深度休眠）、电源策略定制
各位好，今天我们来聊聊车载 Android 系统里一个特别“要命”的话题——电源管理。
说实话，做手机电源管理已经够头疼了，但到了车上，难度直接翻倍。为什么？因为手机没电了最多关机，车机要是电源策略没写好，轻则电瓶亏电打不着火，重则系统睡死过去，导航、倒车影像全挂掉。我当年第一次接触 Automotive 项目时，就踩过这个坑。
好，我们直接进入正题。
5.1 车载电源状态机：不只是“睡”和“醒”
手机上的电源状态很简单：亮屏、灭屏、待机、关机。但在车上，事情复杂得多。
你想想看，车有 ACC（附件通电）、ON（全车通电）、OFF（断电）三种物理状态。再加上引擎启动瞬间的电压跌落、停车后的延时供电、防盗系统的常电需求……Android 标准的电源模型根本不够用。
所以，Android Automotive 定义了一套自己的电源状态机。我习惯把它理解为四个核心状态：
- 唤醒（Awake）：屏幕亮着，系统全速运行，用户正在交互。
- 浅度睡眠（Light Doze）：屏幕灭了，但 CPU 还在跑，网络可能还连着。用于短时间停车等人。
- 深度睡眠（Deep Sleep）：CPU 挂起，内存自刷新，大部分外设断电。这是最常见的停车状态。
- 深度休眠（Hibernation / Shutdown）：系统完全断电，下次启动需要冷启动。用于长时间停放。
嗯，这里要注意：深度休眠和关机还不完全一样。关机是用户主动行为，深度休眠是系统策略触发的。我见过有些车厂直接把深度休眠做成“假关机”，启动速度比真关机快不少。
核心要点：车载电源管理的本质，是在“用户体验”和“功耗”之间找平衡。你让系统睡得太死，用户上车要等 10 秒才能看到导航；你让系统一直醒着，第二天电瓶就亏电了。
下面这张图是我自己整理的电源状态流转关系，你可以对照着看：
5.2 电源策略定制：每个车厂都有自己的“脾气”
Android Automotive 的电源管理框架是高度可定制的。说白了，Google 只给了你一个骨架，肉要你自己长。
我记得第一次给某车厂做电源适配时，对方要求“停车后 30 秒内必须进入深度睡眠，但蓝牙要保持连接，因为用户可能用手机开车门”。你看，这就是典型的车载矛盾——既要省电，又要保持连接。
5.2.1 核心定制点：WakeLock 策略
Android 的 WakeLock 机制在车上需要重新审视。手机上，一个 App 持锁不释放最多就是费电；但在车上，持锁可能导致系统无法进入深度睡眠，进而让电瓶持续放电。
我建议的做法是：
- 对第三方 App 的 WakeLock 做超时强制释放（比如 5 分钟）
- 系统服务持锁必须声明“车载用途”，否则直接忽略
- 在深度睡眠入口处做一次“锁持有者审计”，打印出所有持锁的进程
调试技巧：用 adb shell dumpsys power 查看当前 WakeLock 列表。如果发现某个 App 一直持着 PARTIAL_WAKE_LOCK，那基本就是它阻止了系统休眠。
5.2.2 定制电源策略的代码入口
电源策略的定制主要在 frameworks/base/services/core/java/com/android/server/power/PowerManagerService.java 里。但我不建议直接改这个文件——每次 OTA 升级都会覆盖掉。
更好的做法是：通过 Power HAL 和 Vehicle HAL 来定制。
举个例子，下面是一个简化的电源策略配置，定义在 device.mk 中：
# 车载电源策略配置
PRODUCT_PROPERTY_OVERRIDES += \
ro.power.sleep_timeout_ms=30000 \
ro.power.deep_sleep_timeout_ms=120000 \
ro.power.hibernation_timeout_ms=3600000 \
ro.power.wakeup_sources=power_button,acc_on,door_unlock,can_wake这些属性分别控制：
sleep_timeout_ms：从唤醒到浅度睡眠的超时deep_sleep_timeout_ms：从浅度睡眠到深度睡眠的超时hibernation_timeout_ms：从深度睡眠到深度休眠的超时wakeup_sources：允许唤醒系统的硬件事件列表
注意：wakeup_sources 这个属性非常关键。如果你漏掉了某个唤醒源（比如 CAN 总线唤醒），那车机可能永远无法被唤醒。我曾经就因为漏配了“车门解锁”这个唤醒源，导致用户上车后屏幕还是黑的，被客户追着骂了一周。
5.3 深度休眠：最容易被忽视的“坑”
深度休眠（Hibernation）在手机平台上几乎不用，但在车上却是刚需。为什么？因为车可能要停一周、一个月，甚至更久。
深度休眠的实现方式有两种：
| 方案 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| Suspend-to-RAM (S3) | CPU 挂起，内存保持供电 | 唤醒速度快（< 1秒） | 仍有漏电（~5mA） |
| Suspend-to-Disk (S4) | 内存内容写入存储，完全断电 | 零功耗 | 唤醒慢（3~5秒） |
我个人更倾向于混合策略：短时间停车用 S3，长时间停放用 S4。但这里有个问题——你怎么知道用户要停多久？
嗯，我见过一个比较聪明的做法：通过 CAN 总线读取车辆的门锁状态和驻车时间。如果车门锁了且驻车超过 4 小时，就自动从 S3 降级到 S4。这个逻辑在 VehicleHAL 里实现，不涉及上层 App 修改。
5.4 避坑指南：我踩过的那些电源管理的坑
最后，分享几个我亲身经历过的教训：
- 坑一：唤醒风暴。某个传感器在车辆震动时频繁触发唤醒，导致系统刚睡下就被叫醒，一晚上把电瓶耗光了。解决方案是在 HAL 层加去抖逻辑，连续触发 3 次以上才真正唤醒。
- 坑二：休眠后 USB 漏电。系统休眠了，但 USB 口还在供电，导致外接设备持续耗电。这个需要在设备树（DTS）里把 USB 的电源域配置为休眠断电。
- 坑三：RTC 唤醒冲突。系统设置了 RTC 定时唤醒做 OTA 检查，但用户刚好在那个时间点开车，结果系统被 RTC 唤醒后又立刻被 ACC 唤醒，状态机乱掉了。后来我加了一个“唤醒源优先级”的判断，RTC 唤醒如果检测到 ACC 有效，就直接跳过。
总结一句话：车载电源管理没有银弹。每个车厂的硬件设计、用户习惯、法规要求都不一样。你唯一能做的，就是把状态机设计得足够灵活，把调试工具做得足够好用。
好，关于电源管理策略就聊到这里。记住，下次你在车上等红灯时，车机屏幕虽然灭了，但背后那套电源状态机正在精密地运转着。嗯，这就是工程师的浪漫吧。