存储架构总览：Android Automotive 存储分层、AOSP vs 车厂定制、存储子系统概览
大家好，我是你们的老朋友。今天咱们正式开讲《Android Automotive 存储管理策略实战》的第一章。说实话，车载存储这块水挺深的。我这些年踩过的坑，比你们见过的车载屏幕还多。咱们先从最基础的架构说起，把整个存储系统拆开揉碎了看。
一、Android Automotive 存储分层
先问大家一个问题：一辆智能汽车里，数据到底存在哪？
嗯，这个问题看似简单，但答案并不单一。Android Automotive 的存储，不是一块硬盘那么简单。它是一套分层体系。我个人习惯把它分成四层来看：
- 物理存储层：就是板子上的 eMMC、UFS 或者 NVMe 芯片。车规级芯片和消费级不一样，温度范围、寿命要求都更苛刻。我在项目中遇到过某供应商用了消费级 eMMC，结果夏天暴晒后直接掉盘，那叫一个惨。
- 块设备层：Linux 内核里的 block layer。负责把物理存储抽象成 /dev/block/ 下的设备节点。这里有个关键点——I/O 调度器。车载场景下，我建议用
mq-deadline而不是cfq，因为 deadline 对延迟更友好。 - 文件系统层：ext4、f2fs 这些。AOSP 默认用 ext4，但车厂定制时往往会换成 f2fs。为什么？因为 f2fs 对闪存更友好，随机写入性能好不少。我记得有一次做 OTA 升级测试，ext4 下写入速度只有 f2fs 的 60%，后来全换了。
- Android 框架层：这就是我们开发者最常接触的层面了。包括
StorageManager、Environment这些 API，还有vold（volume daemon）守护进程。说白了，上层应用看到的/sdcard、/data都是这层在管理。
核心要点：这四层环环相扣。上层出问题，往往根子在底层。比如应用报“存储空间不足”，可能是文件系统碎片化严重，也可能是物理块坏了。别只盯着上层日志看。
二、AOSP vs 车厂定制
AOSP 是 Google 的原始代码，但车厂拿过去，基本都会大改。为什么？因为车载场景太特殊了。
咱们对比一下：
| 维度 | AOSP 默认 | 车厂定制 |
|---|---|---|
| 分区方案 | system、data、cache 三大分区 | 增加 oem、vendor、misc、persist 等分区 |
| 存储策略 | 通用型，考虑手机场景 | 针对车载优化，比如日志循环、黑匣子数据保护 |
| 加密方式 | FBE（基于文件的加密） | 很多车厂改用 FDE（全盘加密）+ 硬件密钥 |
| OTA 升级 | A/B 系统更新（Seamless Update） | 定制升级策略，比如增量升级、回滚保护 |
这里我要特别说一下分区方案。AOSP 默认的 /data 分区是用户数据区，但在车上，这个分区会存很多关键数据——导航地图、用户账户、驾驶习惯等。车厂往往会把它拆成多个子分区：
/data：常规应用数据/persist：持久化数据，即使恢复出厂设置也不清/blackbox：黑匣子数据，用于事故分析/log：日志分区，循环写入
我曾经见过一个车厂，把 /persist 分区放在独立物理芯片上，就是为了防止主存储坏了导致车辆无法启动。嗯，这种设计虽然成本高，但安全冗余确实好。
避坑指南：如果你在车厂做定制，千万别直接拿 AOSP 的分区表就用。一定要和硬件团队确认 eMMC 的寿命、坏块管理策略。我曾经因为没确认，结果量产车跑了半年，日志分区写爆了，导致系统频繁重启。
三、存储子系统概览
存储子系统，说白了就是 Android 里所有跟存储打交道的模块的总和。咱们从上到下捋一遍：
3.1 应用层
应用通过 ContentProvider、FileProvider、MediaStore 等 API 访问存储。这里有个坑——车载应用经常需要直接读写 /sdcard 以外的路径，比如 /oem 分区。这时候就需要 android.permission.INSTALL_PACKAGES 或者系统签名权限。
3.2 框架层
StorageManagerService 是核心。它管理着所有卷（volume）的挂载、卸载、格式化。车厂定制时，往往会在这里加一些钩子（hook），比如在挂载 /data 之前先检查文件系统完整性。
3.3 原生层
vold 守护进程，这是存储管理的“大管家”。它负责处理磁盘分区、加密、文件系统检查。我记得有一次调试一个 bug，发现 vold 在挂载 /data 时卡住了，原因是 fsck 检查 ext4 文件系统花了 30 秒。后来我们改成了 f2fs，检查时间降到了 3 秒。
3.4 内核层
这里包括文件系统驱动（ext4、f2fs、sdcardfs）、块设备驱动、I/O 调度器。车载场景下，我特别推荐关注 sdcardfs。它是 Android 特有的文件系统，用于模拟 /sdcard 的权限模型。如果它出问题，应用可能无法读写外部存储。
警告：千万不要在内核层随意修改 I/O 调度器参数。车载存储的 I/O 模式很特殊——大量小文件随机写入（日志、缓存），加上偶尔的大文件顺序写入（地图更新）。调错参数会导致系统卡顿甚至 ANR。我建议用 iostat 和 blktrace 先跑一周数据，再决定优化方向。
四、实战经验总结
讲了这么多，我给大家总结几条实在的：
- 分层思维：遇到存储问题，先定位是哪一层。应用层报错？框架层日志？还是内核层
dmesg？别一上来就怀疑硬件。 - 定制要谨慎：AOSP 的存储设计虽然通用，但经过了大量测试。车厂定制时，每改一处都要做充分的压力测试。我曾经因为改了一个
fstab参数，导致 OTA 升级后/data分区无法挂载，差点造成召回。 - 监控不能少：车载存储一定要有监控机制。比如
SMART信息采集、文件系统碎片率、写入放大因子等。这些数据能帮你提前发现隐患。
好了，第一章就到这里。存储架构是基础，后面我们会深入每个子系统的细节。下一章咱们聊聊分区方案和文件系统选择，那才是真正考验车厂功底的地方。
记住一句话：车载存储，稳定第一，性能第二。别为了跑分好看，把可靠性丢了。