4. 自动回滚机制：Bootloader检测，回滚触发条件，回滚执行流程
自动回滚，说白了就是系统给自己留的一条后路。升级失败了怎么办？总不能变砖吧。AB分区设计的精髓就在这里——Bootloader在启动时做检测，发现不对劲就自动切回旧分区。我参与过的几个项目里，这套机制救过无数次场。
4.1 Bootloader的检测逻辑
系统上电后，Bootloader是第一段运行的代码。它不会直接启动系统，而是先做一套「体检」。我习惯把这套检测分成三个层次：
- 分区状态检查：读取每个分区的
slot-suffix和boot-success标记 - 完整性校验：验证分区头部、哈希值、签名是否匹配
- 启动计数检查：判断当前分区是否已经尝试启动过，次数是否超限
核心原则：Bootloader只信任它自己写进去的标记。任何标记异常，都视为「升级失败」。
嗯，这里要注意一点——Bootloader本身不能升级自己（至少不能通过AB机制升级）。它必须是系统里最稳定、最不容易出问题的部分。我曾经见过一个方案，Bootloader试图通过OTA更新自己，结果中途断电，整机直接变砖。教训深刻。
4.2 回滚触发条件
不是所有异常都会触发回滚。系统得区分「能救的」和「救不了的」。我整理了一张触发条件表，你一看就明白：
| 触发条件 | 检测时机 | 严重程度 | 处理方式 |
|---|---|---|---|
分区标记为 unbootable |
Bootloader启动时 | 致命 | 立即回滚 |
| 连续启动失败超过阈值（如3次） | 每次启动计数+1 | 严重 | 达到阈值后回滚 |
| 内核panic或init崩溃 | 内核启动阶段 | 严重 | 触发重启并计数 |
| 用户空间关键服务未启动 | init进程超时检测 | 中等 | 触发重启并计数 |
| 升级过程中断电 | 下次启动时分区不完整 | 致命 | 立即回滚 |
| 哈希校验失败 | Bootloader校验阶段 | 致命 | 立即回滚 |
你想想看，为什么要有「连续启动失败计数」这个机制？因为有些故障是偶发的——比如某个外设初始化偶尔超时。如果一遇到就回滚，用户可能刚升级完就被迫退回旧版本，体验很差。我个人习惯把阈值设在3次，既给了系统「自愈」的机会，又不会让用户等太久。
避坑指南：我曾经遇到过一个问题——某个外设驱动在特定硬件版本上总是初始化失败，导致系统反复重启、反复计数、最终回滚。后来发现是驱动兼容性问题。所以，回滚机制不能替代充分的兼容性测试。
4.3 回滚执行流程
回滚不是简单地把旧分区内容复制过来。它是一套严谨的状态机转换过程。我画了一张流程图，帮你理清整个链路：
流程看起来不复杂，但每个环节都有细节。我拆开来讲：
4.3.1 切换Slot
Bootloader修改当前激活的slot索引。比如从 slot_a 切到 slot_b。这个操作是原子性的——要么成功，要么不写。我见过一些方案用双备份的slot索引，防止写一半断电导致两个分区都不可用。
4.3.2 重置启动计数
旧分区的启动计数要清零。为什么？因为旧分区之前可能也失败过。不清零的话，切过去又触发回滚，就成死循环了。我个人习惯在重置计数时顺便把 boot-success 标记也清掉，让旧分区以「全新」的状态启动。
4.3.3 重启进入旧系统
Bootloader执行软重启，CPU重新开始执行。这次加载的是旧分区。如果旧分区也启动失败怎么办？嗯，那就真的需要进入恢复模式了。这种情况我在项目中只遇到过一次——两个分区都被破坏了，最后只能通过fastboot线刷救砖。
经验之谈：回滚流程中，日志记录非常重要。我建议在Bootloader阶段就把回滚原因写入持久化存储（比如misc分区）。这样用户反馈问题时，你能快速定位是哪个环节出了岔子。
4.4 回滚后的状态管理
回滚完成后，系统进入一个「降级运行」的状态。这时候有几个事情需要处理：
- 通知上层应用：系统服务应该能感知到当前处于回滚状态，可以弹窗提示用户
- 禁止再次升级：至少在一段时间内，不要再尝试升级同一个版本。我习惯加一个冷却期，比如24小时内不接收同一版本的OTA推送
- 保留失败现场：新分区的日志、crash dump不要删，方便后续分析
你想想看，如果回滚后用户又收到同样的升级包，系统又升级、又失败、又回滚……这不就成了「升级循环」了吗？我确实见过这样的案例，最后用户只能刷机解决。所以，回滚后的状态管理不是小事。
避坑指南：我曾经遇到一个项目，回滚后没有清理新分区的「升级中」标记。结果下次启动时，Bootloader认为升级还没完成，又尝试继续升级……直接死循环。从那以后，我要求所有回滚操作必须把目标分区的状态重置为「未升级」。