每次新手机发布会，“UFS 3.1”这个词几乎成了标配，跑分截图里那一串串破2000MB/s的顺序读写数字，看起来赏心悦目。但说句实话，很多搞嵌入式、搞驱动开发的朋友对UFS 3.1的了解，往往也停留在“快”这个层面。UFS 3.1的完整协议栈长什么样？一条读写命令从操作系统发起，到真正落到闪存颗粒上，中间要穿过多层协议？我们常说的“协议分析”，拿到一条trace后到底在看什么？这篇文章把UFS 3.1协议分析前四章的内容拉通讲一遍，核心就是UFS概述——从协议架构、关键特性到实测分析手段，一次说清楚。

这篇内容适合三类人：一是做存储驱动或BSP开发的工程师，需要理解UFS底层行为；二是做手机/平板/嵌入式产品硬件选型和性能调优的朋友，想知道UFS 3.1的甜点到底在哪；三是刚接触存储协议、想系统入门的学习者，看完你能建立起对整个UFS协议栈的完整认知，而不是停留在跑分软件的数字里。

1. UFS 3.1是什么：从移动存储的演进说起

1.1 eMMC的瓶颈与UFS的登场

移动设备的存储接口，过去十年走了一条非常清晰的路：从MMC、eMMC，到UFS 2.0/2.1/2.2，再到今天的UFS 3.0/3.1甚至4.0。理解这段历史不是为了考古，而是为了明白UFS协议为什么要被设计成今天这个样子。

eMMC最大的问题在于它是半双工的。什么意思？读写共用一套数据总线，同一时刻要么读，要么写，不能同时进行。这在早期功能机时代完全够用，但到了智能机时代，一边后台写日志、一边前台加载图片这种场景越来越多，eMMC的吞吐瓶颈就暴露得非常明显。另外，eMMC的命令队列深度只有一条（严格说eMMC 5.x引入了命令队列，但深度和调度能力远弱于UFS），host发一条命令就得等它完成，整个存储子系统的并发能力非常有限。

UFS则完全不同。它把SCSI命令体系、命令队列、全双工传输这些“企业级存储”的概念引入移动设备，目标很明确：用接近SSD的协议架构，在极低的功耗预算内提供远超eMMC的带宽。UFS 3.1作为这一演进过程中的成熟版本，技术指标和功能完整度都到了一个很好的平衡点——所以至今仍然是大规模量产的主流方案。

1.2 UFS 3.1的定位、速率与技术指标

UFS 3.1由JEDEC发布，完整的规范章节覆盖了UFS命令集、UTP传输协议、设备管理器、互操作标准等。它继承了UFS 3.0的物理层基础——M-PHY高速接口和UniPro传输层，同时在外围特性上做了三处重大补充：Write Booster（写入加速器）、Deep Sleep（深度睡眠）、Performance Throttling Notification（性能节流通知），以及从UFS 3.0继承并增强的Host Performance Booster（主机性能增强器，简称HPB）。

速率上，UFS 3.1的物理层支持M-PHY HS-G3速率档，每个通道约5.8Gbps，双通道（2-Lane）组合后理论接口带宽约11.6Gbps。注意这是接口层速率，不是用户能拿到的实际读写速度。实际项目中，好的UFS 3.1闪存在顺序读上能做到2000MB/s以上，顺序写在1200MB/s到1800MB/s之间（取决于Write Booster开启情况和颗粒本身素质），随机读通常突破50K IOPS。

这里插一句容易混淆的点：UFS 3.1的“3.1”是指协议版本，不直接等于性能档位。颗粒体质、主控固件策略、通道数、甚至手机散热设计，都会显著影响最终跑分。这也是为什么同样是UFS 3.1，不同机型的实测差异可以非常大。

2. UFS协议栈三层架构：一次命令的完整旅程

UFS协议栈的核心是三层结构：应用层（Application Layer）、传输层（UniPro）、物理层（M-PHY）。虽然平时调试主要接触的是应用层的命令交互，但分析问题时，三层都需要有基本概念。我按一条读命令从host到设备的过程，把每一层拆开讲。

2.1 应用层：UCS命令集与UTP传输协议

应用层往下细分，又分三块：UFS命令集（UCS）、UTP传输协议、设备管理器（Device Manager）。

UCS层直接继承SCSI命令体系。你发给UFS设备的命令，底层很多就是SCSI命令的变体：读数据用READ(10)、写数据用WRITE(10)、TRIM对应UNMAP、刷新缓存用SYNCHRONIZE CACHE(10)、设备信息查询用INQUIRY、电源管理用START STOP UNIT。这套命令体系的好处是生态成熟、工具链完善，Linux内核里很多SCSI层面的调试经验可以直接迁移过来。

UTP层负责把命令封装成协议信息单元，也就是UPIU（UFS Protocol Information Unit）。UPIU是UFS协议分析中最重要的概念之一——类似网络抓包里的IP数据报文。一次读操作会产生三类UPIU：

• 命令UPIU：host发给设备，携带CDB（命令描述符块），比如读命令的起始LBA和长度。
• DATA IN UPIU：设备返回数据给host，里面既包含数据负载，也包含命令执行状态。
• 响应UPIU：命令完成后的状态返回，类似网络协议里的ACK+RST组合。

设备管理器则负责设备的配置和状态管理。设备描述符、几何描述符、单元描述符这些参数，都是通过Query Request机制来读写的。比如判断设备是否支持Write Booster，就要查几何描述符里的bWriteBoosterBufferSize字段。协议分析时，看到Query Request/Response UPUI，就知道是在做设备管理层面的操作，而不是数据传输。

2.2 传输层：UniPro协议的核心机制

UniPro（Universal Protocol）由MIPI联盟定义，负责把UPIU可靠地从一个节点搬到另一个节点。从层次上讲，它内部又分传输层、网络层、数据链路层和物理适配子层。很多初次接触UFS协议的人会被这堆层搞晕，我的经验是抓住两个重点：分段与重组、流控与重传。

当一条UPIU很大（比如4KB的读数据），UniPro会在发送端把它切分成一个个数据段（Segment），每个段加上头部信息变成帧（Frame）后逐帧发送；接收端再按序号重组。这个过程相当于TCP协议里的分段和重组。

流控机制则类似TCP的滑动窗口，但更精细。UniPro在数据链路层采用基于credit的流控——发送方要知道接收方有多少个接收缓冲区（credit）可用，每发一帧就少一个credit，接收方处理完一帧就还一个credit。如果接收方来不及处理，credit耗尽后发送方必须停等。协议分析中，如果发现同一时间段内出现大量FC（Flow Control）帧，说明接收端处理能力吃紧，这时候问题往往不在UFS本身，而是UniPro链路另一端的瓶颈。

2.3 物理层：M-PHY差分信号与链路训练

物理层M-PHY是所有协议的最终承载者。它使用差分信号传输，数据线上有HS（高速）和PWM（低速）两套模式，类似千兆以太网和百兆以太网的速率差别。HS模式用于正常数据传输，PWM模式则用于低功耗状态下的命令通路。

M-PHY支持多速率档，UFS 3.1设备实际跑通的是HS-G1（约1.2Gbps）、HS-G2（约2.5Gbps）、HS-G3（约5.8Gbps）几个档位。协议分析仪抓物理层信号时，首先就是要确认链路是否协商到了目标速率档。链路训练失败或者速度回退（比如从G3退到G2），是物理层故障最常见的表象——信号完整性不好、PCB走线过长、供电纹波偏大，都会导致速率降档。

我在实际项目中遇到过一种情况：某平台的UFS读写偶尔很慢，协议分析仪显示物理层已经协商到HS-G3，但频繁出现M-PHY链路重训练事件。后来定位到是主控端的参考时钟抖动过大，导致误码率上升，UniPro层反复触发重传，形成恶性循环。这种问题只看应用层log是发现不了的，必须把协议分析仪接在M-PHY链路上看物理层事件。

3. UFS 3.1四大关键特性逐个拆解

3.1 Write Booster：SLC缓存如何把写入拉满

Write Booster（简称WB）是UFS 3.1最务实的特性。NAND闪存本身有“写入放大”和“低速编程”的问题，尤其是TLC/QLC颗粒，直接写入时延偏高，顺序写速度远不如读速度。WB的思路很简单：在闪存里拿出一部分区域，以SLC模式运行，写入速度快得多，作为写入缓存；host写入的数据先落进这块SLC缓存，主控再在后台把数据搬移到TLC/QLC区域。

这里有两个关键点直接影响调试：

第一，WB区域能不能用、容量多大，是通过几何描述符暴露给主机的。只有描述符里的bWriteBoosterBufferType和bWriteBoosterBufferSize非零，host才会去配置WB相关控制。

第二，WB缓存满了之后怎么办？设备会通过Exception Event机制向host发通知，或者将设备状态切换到WB禁用的正常模式。如果应用层持续写入而host没有及时处理，写入性能会断崖式下跌。所以协议分析时如果看到写入速度先高后低，别急着骂驱动，先查WB状态切没切换。

3.2 Deep Sleep：待机功耗的极限压榨

UFS设备有多个电源状态：Active、Idle、Sleep、Deep Sleep和Power Off。之前的版本里Sleep已经能显著降低功耗，但UFS 3.1引入Depp Sleep，把待机功耗往下再压了一档。原理不复杂：Deep Sleep状态下，设备的时钟和PLL大规模关停，只保留必要的唤醒逻辑。

代价是唤醒延迟变长。从Deep Sleep恢复到Active，需要重新锁相、重新训练链路，延迟可以到毫秒级。所以主机驱动需要权衡：是让设备进入更省电的Deep Sleep，还是保持在Sleep以求快速响应？Linux内核里对应的电源管理策略，往往取决于产品定位——主打续航的设备会激进地进入Deep Sleep，主打性能的设备则会保守一些。

协议分析中，进入Deep Sleep通常会观察到M-PHY链路进入低功耗状态，UniPro层会做链路挂起操作。如果在此时收到新的IO请求，trace里会出现一个明显的“唤醒-链路重训练-恢复传输”的过程。

3.3 性能节流通知与主机性能增强器

Performance Throttling Notification（PTN）解决的是温度与性能的矛盾。UFS设备内部有温度传感器，当温度超过阈值，继续全速写入可能导致颗粒数据保持能力下降，设备会主动降频。降频之前，设备通过Exception Event向host发送节流通知，host可以据此调整IO调度策略，比如暂停后台任务、降低写入频率。

PTN在协议分析中有个标志性看头：Exception Event UPIU。如果在高温压力测试中频繁看到这类UPIU，说明散热设计可能有问题，或者设备节流阈值设置太激进。

Host Performance Booster（HPB）则是UFS 3.1里面向“随机读性能”的重要机制。手机闪存的逻辑地址到物理地址映射表，传统上由设备内部维护，每次随机读都需要查映射表，带来了额外的读放大和延迟。HPB的思路是把部分映射信息缓存在主机DRAM里，host可以直接告诉设备“物理地址是xxx”，省掉设备内部查表的过程。

HPB的协议分析要重点关注HPB Read命令和HPB Control UPIU。如果设备返回的物理映射信息（L2P MAP）与缓存不一致，还会触发设备端异常。实际调试中，HPB相关的bug往往表现为随机读性能不稳定，有时候快有时候慢。

4. UFS 3.1性能实测与协议分析方法

4.1 从规格到现实：性能测试怎么跑、数据怎么看

规格书上的理论带宽是上限，真正能到多少，要拿实测数据说话。我常用的方法是分三档测：

第一档用AndroBench或FIO跑顺序读写、随机读写，拿到基础的性能基线。注意测试时设备剩余空间至少留20%以上，否则垃圾回收会严重干扰结果，数据不可信。

第二档跑混合读写和读写切换测试。UFS 3.1支持命令队列（深度32），这意味着多个IO请求可以在设备端并发执行。协议分析时可以通过观察队列深度判断设备端调度效率——队列深度不能被有效利用，往往说明固件或者驱动有问题。

第三档是长时间压力测试。连续写入半个小时后看性能曲线是否平稳。这里特别能反映Write Booster的缓存策略和垃圾回收算法。好的UFS 3.1设备，在SLC缓存耗尽后性能会平缓回落，而不是断崖式崩盘。

有一组我实测过的reference数据供参考：某平台UFS 3.1（2-Lane HS-G3），顺序读约2050MB/s，顺序写1400MB/s，4K随机读约52K IOPS，4K随机写约42K IOPS（以上为缓存充足时的峰值数据，不同的颗粒和固件差异很大）。

4.2 协议分析工具：抓包、解码与时序定位

如果你也做过网络抓包分析，理解UFS协议分析会特别快——本质上是“抓报文、看交互、找异常”，处理IP数据转发报文、分析ARP协议的过程，和UFS的UPIU分析思路一脉相承。区别在于，网络抓包用Wireshark，UFS协议分析得靠下面几类工具：

逻辑分析仪是最低成本的入手选择。MIPI M-PHY是差分信号，逻辑分析仪需要支持差分输入，采样率至少要到1GHz才能观察HS-G1以上的信号细节。适合看时序、量电平、查上电复位顺序，做底层调试。

商用协议分析仪（比如Keysight、Teledyne LeCroy的UFS方案）价格高，但功能强。它们能解码UPIU层和UniPro层，直接把协议事件以列表形式呈现，还能自动统计各类型UPIU的数量和耗时。做协议符合性测试、定位链路训练问题和命令超时问题，这类工具最省力。

软件层的trace分析则适合日常驱动调试。Linux内核的ufshcd驱动有完善的tracepoint，在/sys/kernel/debug/tracing里可以打开ufshcd命令事件跟踪，不需要额外硬件就能看CMD UPIU和响应的时间戳，定位软件层的命令超时和队列堆积非常有效。

4.3 常见问题与排查思路

整理几个我排查UFS问题时高频遇到的坑，按协议栈自上而下排列：

• 命令超时：先查上层UFS驱动有没有在预期时间内收到响应UPIU。如果协议分析仪上只看到CMD UPIU、看不到响应，大概率是设备卡在内部处理（查GC是否频繁、固件策略是否异常）；如果响应有但host没及时处理，问题在host端驱动或调度。
• 速率回退：物理层G3协商失败回退到G2甚至G1，顺序读写性能直接掉到标称的一半。优先检查PCB差分走线、参考时钟、电源去耦。用协议分析仪看链路训练阶段的速率协商序列，能拿到第一手证据。
• 写入性能抖动：优先考虑Write Booster状态切换和垃圾回收。写满缓存后的性能回落曲线，能帮你判断设备SLC缓存容量和固件GC策略。
• 随机读异常：优先检查HPB相关配置。如果设备支持HPB但host端没有使能，或者使能了但映射信息管理有bug，随机读可能比纯设备端查表还要差。

再补一个通用的排查顺序建议：先看物理层（速率、信号），再看传输层（重传、流控、帧错误），最后看应用层（命令序列、超时、设备状态）。很多团队一上来就扒应用层log，查了半天发现是物理层速率回退导致的性能问题，方向错了效率极低。类似的经验在网络协议分析里也成立——先确认链路通了、速率对了，再谈协议交互，这个方法论放之四海而皆准。

5. UFS 3.1与现有方案的选型思考

项目选型时，UFS 3.1和UFS 2.2、UFS 3.0怎么选？抛开市场宣传，从协议分析角度讲三点实在的。

第一，如果产品定位中高端，需要连续读写大文件、跑4K视频等高码率场景，UFS 3.1的双通道HS-G3带宽是值得的。但要注意，带宽要配套散热设计。前面说过PTN机制，UFS 3.1设备在全速写入时发热明显，如果散热压不住，设备会主动节流，跑分好看的UFS 3.1体验上可能还不如散热好的UFS 2.2。

第二，如果产品以轻量级应用为主，UFS 2.2的成熟方案性价比更高。UFS 3.1的WB特性和HPB特性需要对应的主控和固件支持，硬件成本和技术门槛都更高。不要为了参数好看而上配置，要看实际场景能否让性能发挥出来。

第三，UFS 3.1对比UFS 3.0时，重点关注的不是跑分，而是Deep Sleep带来的待机功耗差异和Write Booster的稳定性。这两个特性在重度使用场景中的体验差异，比多出来的几百MB/s顺序读更有感知。

我在实际项目里见过不少选型踩坑的例子：芯片平台刚刚支持UFS 3.1，评估板跑分很高，但没有做长期温度压力测试就量产，结果用户连续拍4K视频时设备卡顿严重——这就是PTN节流与散热设计不匹配的典型表现。所以，协议分析不只是工具层面的“抓包看报文”，更应该从产品定义阶段就参与进来，把链路、功耗、散热当成整体来设计。

UFS 3.1协议分析这一块，内容很深，前四章讲完也还只是地基。这套协议的价值在于，它把此前只存在于企业级SSD里的技术，在严格功耗预算内做成了移动设备的标配——理解它，无论对驱动开发、性能调优还是硬件设计，都很有帮助。