车载存储优化：文件系统选择、I/O调度与缓存策略
车载系统的存储优化，说实话，是个容易被忽视但极其关键的环节。你想想看，车机每天要读写多少数据？导航地图、多媒体缓存、系统日志、用户配置……任何一个环节的I/O瓶颈，都会直接反映在用户体验上——启动慢、卡顿、甚至黑屏。
我个人习惯把车载存储优化拆成四个维度：文件系统选型、I/O调度策略、预加载与缓存机制、性能基准测试。今天我们就一个一个来聊。
核心观点：车载存储没有银弹。F2FS和EXT4各有优劣，关键看你的使用场景。I/O调度器选错了，再好的文件系统也白搭。
一、文件系统选择：F2FS vs EXT4
先说说文件系统。Android原生从4.4开始支持F2FS，但很多车厂到现在还在用EXT4。为什么？因为EXT4太成熟了，稳定得让人放心。但F2FS在闪存上的表现，确实有它的独到之处。
我在项目中遇到过这样一个案例：某款车机使用eMMC 5.1，预装EXT4文件系统。用户反馈说「用了一年之后，开机越来越慢」。后来我们换成F2FS，同样的硬件，冷启动时间从23秒降到了16秒。嗯，差距就是这么明显。
| 对比维度 | EXT4 | F2FS |
|---|---|---|
| 碎片化处理 | 传统B-tree，碎片化严重 | 日志结构，天然抗碎片 |
| 小文件读写 | 一般，inode开销大 | 优秀，多路复用 |
| 大文件顺序读写 | 优秀 | 良好 |
| 掉电恢复 | fsck耗时较长 | 快速恢复，但复杂场景需注意 |
| 兼容性 | 极好，所有Linux发行版支持 | 需要内核支持，部分工具链不完善 |
我的建议：如果车机使用eMMC或UFS 2.1以上，且对冷启动时间敏感，优先考虑F2FS。如果使用SD卡或老旧eMMC，EXT4更稳妥。
为什么F2FS在闪存上表现更好？说白了，它知道自己在闪存上跑。F2FS的设计哲学是「把闪存当闪存用」，而不是像EXT4那样把闪存模拟成传统磁盘。它通过多路日志结构，把随机写转换成顺序写，大大减少了写放大效应。
但F2FS也不是没有坑。我曾经踩过一个雷：F2FS在极端低电量掉电场景下，如果GC（垃圾回收）正在进行，恢复时间会明显变长。所以如果你做的是电动车，电池管理策略一定要和文件系统联动。
二、I/O调度优化
文件系统选好了，接下来是I/O调度。Android默认的I/O调度器是CFQ（完全公平队列），但在车载场景下，CFQ并不总是最优解。
你想想看，车机上的I/O请求优先级差异很大：导航渲染需要高优先级，后台日志写入可以低优先级。CFQ对所有请求一视同仁，这就导致了关键I/O被非关键I/O阻塞。
我个人习惯在车载平台上使用BFQ（预算公平队列）或Kyber调度器。
- BFQ：适合多任务场景，能按进程优先级分配I/O带宽。比如把Launcher和导航的I/O优先级调高，日志和OTA下载的优先级调低。
- Kyber：适合延迟敏感场景，算法简单，CPU开销小。如果你的车机CPU资源紧张，Kyber是个好选择。
怎么切换？在init.rc里加一行就行：
# 切换到BFQ调度器
echo bfq > /sys/block/mmcblk0/queue/scheduler
# 验证当前调度器
cat /sys/block/mmcblk0/queue/scheduler
# 输出示例：[bfq] kyber none注意：切换调度器后，一定要做压力测试。有些eMMC控制器对BFQ支持不好，会出现I/O超时。我遇到过一款三星eMMC，切到BFQ后随机读写性能反而下降了15%。
除了调度器本身，还有几个参数值得调优：
- read_ahead_kb：预读大小。车载场景建议设为128KB~256KB，太小了顺序读性能差，太大了浪费内存。
- nr_requests：队列深度。默认128，如果遇到I/O拥塞，可以适当降低到64。
- iostats：建议关闭（设为0）。车载系统不需要实时I/O统计，关闭后能减少约5%的CPU开销。
三、预加载与缓存策略
这部分是我觉得最有意思的。车载系统的启动过程，说白了就是一场「I/O抢跑」。谁先读到数据，谁就赢。
我参与过的一个项目，冷启动时间从28秒优化到12秒，核心手段就是预加载。具体怎么做？
- 关键文件预读：在init进程早期，用
readahead系统调用把Launcher、SystemUI、导航地图索引等关键文件提前加载到page cache里。 - 缓存预热：系统关机时，把热数据（最近使用的应用、地图缓存）的block列表保存下来。下次开机时，直接按列表预读。
- 分层缓存：内存够用的话，用
zram做压缩缓存，把不常用的数据压缩后留在内存里，减少回刷存储的次数。
# 预读关键文件示例
echo "/data/app/com.android.launcher3-1/base.apk" > /sys/block/mmcblk0/queue/readahead_list
echo 1 > /sys/block/mmcblk0/queue/readahead_trigger避坑指南：我曾经在预加载时把整个/data分区都读了一遍，结果开机时间反而变长了。预加载不是越多越好，要精准。建议用strace或perf抓一下开机时的I/O访问模式，只预读前20%的热数据。
缓存策略方面，我推荐使用双缓存+写回策略。读缓存用LRU（最近最少使用），写缓存用Writeback。但要注意，Writeback在掉电场景下有数据丢失风险。电动车有BMS（电池管理系统），可以配合BMS的掉电通知，在掉电前强制刷缓存。
四、存储性能基准测试
说了这么多优化手段，怎么验证效果？基准测试。但车载场景的测试方法和PC不一样，不能光看跑分。
我常用的测试工具和指标：
| 工具 | 测试内容 | 关键指标 |
|---|---|---|
| fio | 随机/顺序读写、混合读写 | IOPS、延迟（P99）、带宽 |
| AndroBench | 模拟应用层I/O模式 | 随机读延迟、数据库写入速度 |
| dbench | 多客户端并发I/O | 吞吐量、响应时间分布 |
| 自定义脚本 | 模拟车载典型场景（导航、音乐、OTA） | 冷启动时间、应用启动延迟 |
我个人最看重的是P99延迟和冷启动时间。跑分再高，如果P99延迟超过200ms，用户在导航时就会感觉到卡顿。冷启动时间更是直接决定用户的第一印象。
下面是我画的一张车载存储优化知识体系图，帮你理清思路：
最后说一句，存储优化不是一锤子买卖。车机用久了，eMMC的磨损、文件系统的碎片化、缓存的冷热数据分布都会变化。我建议每半年做一次基准测试，对比历史数据，及时发现性能衰减。
嗯，今天就聊到这里。存储这块内容很多，但核心就是这四个维度。你先把文件系统和I/O调度器定下来，再慢慢调预加载和缓存，最后用基准测试验证效果。稳扎稳打，车载系统的存储性能一定能上去。