4、AB系统与恢复策略：A/B分区的概念、无缝更新机制、回滚失败时如何切换到Recovery
好，咱们进入第四章。这一章聊的是AB系统，说白了就是「双保险」机制。我最早接触AB分区是在做车机项目的时候，当时客户要求系统更新不能黑屏超过两秒。嗯，那会儿我才真正体会到，AB分区不只是多一份备份那么简单。
4.1 A/B分区的核心概念
什么是AB分区？简单讲，就是把系统分成两套完整的「副本」——A槽和B槽。每个槽都包含boot、system、vendor等必要分区。你想想看，这就像飞机有两个引擎，坏了一个还能飞。
关键点：AB分区不是简单的镜像备份，而是两套独立可启动的系统环境。A槽和B槽在物理上是隔离的，各自拥有完整的系统分区表。
我习惯把AB分区比作「双活」架构。两个槽位在平时都处于可用状态，但只有一个是当前激活的（active slot）。另一个处于「待命」状态（inactive slot）。
| 概念 | 说明 |
|---|---|
| Active Slot | 当前正在运行的系统槽位 |
| Inactive Slot | 待更新的目标槽位 |
| Slot Suffix | 分区命名后缀，如 _a、_b |
| Boot Control | 引导控制块，记录槽位状态 |
4.2 无缝更新机制
无缝更新，英文叫 Seamless Update。为什么能做到「无缝」？因为更新是在后台完成的，用户完全无感知。
流程是这样的：
- 下载更新包到 Inactive Slot
- 校验完整性，确保数据没损坏
- 写入系统，覆盖 Inactive Slot 的所有分区
- 标记新槽位为可启动状态
- 重启切换到新槽位
我记得第一次调试这个流程时，踩了个坑——更新包下载到一半断电了。重启后系统发现 Inactive Slot 数据不完整，自动回滚到 Active Slot。嗯，这就是AB系统的容错能力。
个人经验：在实际项目中，我建议在写入新系统前先做一次「预校验」。把整个更新包的哈希值算好，写入前再算一遍。不一致就直接放弃，别写到一半才发现坏了。
4.3 回滚失败时的恢复策略
这里要重点讲。AB系统虽然可靠，但回滚本身也可能失败。为什么会失败？我遇到过几种情况：
- 新系统启动后崩溃，触发自动回滚
- 回滚过程中掉电，两个槽位都坏了
- Boot Control 区域被写坏，无法判断哪个槽位可用
当回滚失败时，系统必须有一个「兜底」方案——切换到 Recovery 模式。
4.3.1 切换到Recovery的触发条件
系统在以下几种情况下会主动跳转 Recovery：
- 两个槽位都标记为「不可启动」
- 连续三次启动失败
- Boot Control 校验失败
- 用户强制进入（按键组合）
警告：千万不要把 Recovery 当成常规恢复手段。它应该是最后一道防线。我见过有些团队把 Recovery 当「万能药」，结果 Recovery 分区本身也被写坏了，那就真成砖了。
4.3.2 切换流程
具体怎么切？我画了个流程图，你看一眼就明白了。
4.3.3 Recovery模式下的操作
进入 Recovery 后，系统能做哪些事？我列一下：
- 从外部存储刷写：SD卡、U盘、OTG设备
- 网络恢复：通过fastboot或adb推送镜像
- 擦除数据：清除用户数据分区，解决数据损坏问题
- 日志导出：把崩溃日志保存到外部存储，方便分析
避坑指南：我曾经遇到一个项目，Recovery 分区和 boot 分区放在同一个物理块上。结果 boot 坏了，Recovery 也读不出来。后来我强制要求：Recovery 必须放在独立的物理介质上，或者至少是独立的 Flash 块。
4.4 实际项目中的注意事项
最后聊几个实战中容易踩的坑：
- 槽位切换次数限制：有些 Flash 芯片有擦写寿命。频繁切换槽位会加速磨损。我建议加一个「切换计数器」，超过阈值就报警。
- Boot Control 的冗余：Boot Control 数据最好存三份。两份一致就采用，三份全不同就进 Recovery。
- 回滚超时：新系统启动后，给一个「观察期」。比如 5 分钟内没有崩溃，才正式确认切换成功。否则自动回滚。
重要：千万不要在 Recovery 模式下做「全量擦除」。我见过有人把 Boot Control 区域也擦掉了，结果 Recovery 重启后找不到任何槽位，彻底变砖。Recovery 只擦 userdata 和 cache，别动 boot 和 misc 分区。
嗯，AB系统这块内容不少，但核心就一句话：双槽位 + 自动回滚 + Recovery 兜底。把这三点吃透了，大部分防回滚失败的场景都能应对。