9、电源管理：AAOS电源状态机、休眠与唤醒策略、看门狗与系统稳定性
电源管理，说白了就是让车机该睡的时候睡，该醒的时候醒，别乱耗电，也别死机。我在做AAOS项目时，发现很多开发同学把精力都放在功能开发上，结果一测功耗，车子熄火后电瓶还在哗哗掉电。嗯，这章我们就来把这块硬骨头啃下来。
9.1 AAOS电源状态机：系统的心脏节拍
AAOS的电源管理核心是一个状态机。它不像手机那样简单粗暴地“亮屏/灭屏”，而是要考虑车辆的各种工况。
我个人习惯把AAOS的电源状态分为以下几个关键阶段：
| 状态 | 说明 | 典型场景 |
|---|---|---|
| ON | 全功能运行 | 车辆行驶中、驻车娱乐 |
| SHUTDOWN_PREPARE | 准备关机，保存数据 | 用户熄火、ACC OFF |
| SUSPEND | 深度休眠，仅保留唤醒源 | 车辆长时间停放 |
| HIBERNATE | 休眠到存储，几乎零功耗 | 极低电量保护 |
核心要点：状态切换不是瞬间完成的。每个状态之间都有超时机制和回调函数。我曾经在项目中遇到过一个问题：SHUTDOWN_PREPARE阶段有个服务没来得及关闭，导致下次开机时系统卡死。后来我强制在状态机里加了“服务关闭确认”的步骤，才彻底解决。
9.2 休眠与唤醒策略：怎么睡，怎么醒
休眠策略，说白了就是“谁可以阻止系统睡觉”。AAOS里有个叫WakeLock的机制，跟Android手机一样，但车机上更严格。
我建议你重点关注以下几点：
- Partial WakeLock：CPU不休眠，但屏幕可以关。适合后台下载地图、音乐缓存。
- Full WakeLock：屏幕和CPU都保持唤醒。适合导航、视频播放。
- 唤醒源管理：CAN总线信号、GPIO中断、RTC闹钟都可以作为唤醒源。
避坑指南：我曾经在项目里发现，某个第三方App在后台持有一个Partial WakeLock不放，导致车机熄火后一整夜都在耗电。排查了三天才找到原因。所以，我建议你在系统层加一个“WakeLock超时强制释放”的机制，比如超过30分钟自动释放。
唤醒策略也有讲究。AAOS支持多种唤醒方式：
- 远程唤醒：通过手机App远程启动空调、预热电池。
- 本地唤醒：用户开门、按启动按钮、插充电枪。
- 定时唤醒：比如每天早上6点自动唤醒，更新天气和路况。
你想想看，如果唤醒逻辑没写好，可能会出现“一开门，系统还没准备好，中控黑屏10秒钟”的尴尬情况。嗯，这里要注意：唤醒后的初始化顺序很重要。我一般先唤醒电源管理芯片，再唤醒SoC，最后才点亮屏幕。
9.3 看门狗与系统稳定性：别让车机死给你看
看门狗（Watchdog）是车机稳定性的最后一道防线。说白了，就是一个“定时炸弹”：如果系统在规定时间内没有“喂狗”，看门狗就会强制重启系统。
AAOS里通常有两种看门狗：
- 硬件看门狗：独立于SoC的芯片，即使CPU死机也能触发复位。
- 软件看门狗：在系统服务层实现，监控关键进程是否卡死。
警告：千万不要把看门狗的喂狗操作放在一个简单的定时器里！我曾经见过一个项目，开发同学把喂狗放在一个高优先级线程里，结果系统服务全卡死了，但喂狗线程还在跑，看门狗永远不触发。这等于形同虚设。
正确的做法是：喂狗操作必须由多个关键服务共同确认。比如，只有SurfaceFlinger、AudioFlinger、CarService都正常响应时，才允许喂狗。任何一个服务卡死，看门狗就应该超时复位。
我个人的经验是，看门狗的超时时间设置也有讲究：
| 场景 | 推荐超时时间 | 说明 |
|---|---|---|
| 正常行驶 | 5秒 | 系统响应必须快，死机超过5秒就重启 |
| 休眠状态 | 30秒 | 休眠时允许更长的响应时间 |
| OTA升级 | 120秒 | 升级过程中系统负载高，需要放宽 |
9.4 电源管理架构图
下面这张图是我根据实际项目经验总结的AAOS电源管理核心流程。你可以看到，从用户操作到最终状态切换，中间经过了多层校验和回调。
关键总结：电源管理不是孤立的模块。它跟CAN总线、系统服务、硬件驱动都紧密相关。我建议你在开发初期就定义好状态机的所有边界情况，比如“休眠过程中收到唤醒信号怎么办”、“看门狗复位后如何快速恢复”。这些细节决定了车机在真实场景下的稳定性。
好了，这章的内容就到这里。电源管理这块，说白了就是“让系统在正确的时间做正确的事”。多花点时间在状态机的边界条件和看门狗的喂狗逻辑上，你的车机稳定性会提升一大截。