1. 课程导入
在移动终端、车载座舱、AI边缘设备等场景中，UFS（Universal Flash Storage）已经成为主流的嵌入式存储接口。用户感知到的“应用启动快不快”“相册滑动卡不卡”“大模型权重加载要多久”，背后往往不是CPU算力不足，而是存储接口吞吐能力没有跑满或被错误评估。UFS接口吞吐测试，正是把“存储到底能跑多快、为什么跑不到标称速度、瓶颈在哪一层”变成可测量、可复现、可优化的一门工程方法学。
很多团队在项目初期只做一次顺序读写跑分，看到接近标称带宽就认为存储子系统合格；到了整机阶段却发现随机读写IOPS远低于预期，游戏加载、数据库写入、多路视频录制频繁掉帧。问题根源在于：吞吐不是一个单一数字，而是协议层、链路层、控制器、NAND介质、主机软件栈与温度/功耗策略共同作用的结果。本课程的目标，是建立一套从“测什么”到“怎么测”再到“如何定位与优化”的完整闭环。
一、核心原理：吞吐由哪些层共同决定
UFS的吞吐链路可以抽象为一条自下而上的数据通路：NAND闪存阵列 → UFS控制器（含FTL、缓存、命令队列）→ M-PHY物理层 → UniPro链路层 → UFS传输协议层（UTP）→ 主机控制器（HCI）→ 内核块层与文件系统 → 用户态应用。任何一层出现带宽上限、延迟抖动或流控反压，都会让最终测得的吞吐低于理论值。
因此，吞吐测试必须区分三类指标：顺序带宽（MB/s）反映大块连续传输能力，随机IOPS反映小尺寸并发访问能力，访问延迟（μs/ms）反映单次请求响应时间。三者不可互相替代。例如UFS 3.1标称顺序读可达2100MB/s，但4KB随机读可能只有数万IOPS，若测试用例设计不当，就会得出错误结论。
二、方法流程：一次可信的吞吐测试如何展开
可信的吞吐测试不是“跑一个工具看结果”，而是一条标准化流程。建议按以下步骤执行：
- 明确测试目标：是验证平台是否达标，还是定位某场景瓶颈，还是做竞品对比。目标不同，用例设计完全不同。
- 固定环境变量：记录UFS型号、协议版本、HS-GEAR速率、通道数、内核版本、文件系统、CPU调频策略、温度起始值。
- 预处理设备：先做全盘顺序写使设备进入稳态，避免SLC缓存和GC带来的“虚高”结果。
- 分层测量：先裸块设备（如/dev/block/sda）测，再挂文件系统测，最后在应用层测，逐层对比定位损耗。
- 采集多维数据：带宽、IOPS、延迟分布、CPU占用、温度、功耗、UFS寄存器状态。
- 重复与统计：每组用例至少3次，取中位数并记录波动范围，剔除异常点。
# 示例：使用 fio 测试 UFS 块设备 4K 随机读
fio --name=randread --filename=/dev/block/sda \
--rw=randread --bs=4k --iodepth=32 --numjobs=4 \
--ioengine=libaio --direct=1 --runtime=60 --time_based \
--group_reporting --output-format=json三、典型场景：为什么“跑分高”不等于“体验好”
某车载项目在实验室测得UFS顺序读1850MB/s，接近标称值，但实车多路视频录制时频繁丢帧。复盘发现：录制场景是持续顺序写+小文件元数据随机写的混合负载，而测试只覆盖了纯顺序读。进一步测量显示，混合读写时IOPS下降约60%，且设备温度超过70℃后触发热降频，写入带宽被限制到原来的40%。这说明吞吐测试必须贴近真实业务负载，而不是只追求单项峰值。
四、课程框架与预期收获
本课程共30章，围绕“原理—方法—工具—案例—优化”五条主线展开。前段建立UFS协议与吞吐模型认知，中段深入测试工具、用例设计与数据解读，后段聚焦瓶颈定位、热与功耗影响、多场景实战与复盘方法。
| 模块 | 核心内容 | 预期收获 |
|---|---|---|
| 基础认知 | UFS协议栈、M-PHY/UniPro、吞吐模型 | 能说清吞吐由哪些层决定 |
| 测试方法 | 用例设计、环境固定、分层测量、统计方法 | 能独立设计可信测试方案 |
| 工具实操 | fio、AndroBench、iostat、UFS寄存器读取 | 能采集并解读多维数据 |
| 瓶颈定位 | 软件栈、链路、介质、热与功耗排查 | 能定位真实瓶颈层 |
| 实战复盘 | 手机、车载、AI设备场景案例 | 能输出可落地的优化建议 |
学完本课程，你将能够：独立搭建UFS吞吐测试环境；区分顺序带宽、随机IOPS与延迟三类指标；识别缓存、GC、热降频等常见干扰；用分层方法快速定位瓶颈；并把测试结论转化为可执行的优化动作。吞吐测试的价值，不在于得到一个漂亮数字，而在于让存储子系统的真实能力与业务体验之间建立可验证的对应关系。