GATT读写通知吞吐量疑问：单字节特征优化及传输方式对比

1. 你对TI示例的理解是正确的 #

TI的这个吞吐量示例确实用单字节特征承载了大缓冲区的通知数据——这里的核心逻辑是：GATT通知的 payload 大小并不受特征定义的“标称长度”限制，而是由BLE链路的**最大传输单元(MTU)**决定。

BLE 5.0+支持的MTU最大可达251字节（扣除ATT层3字节开销后，实际数据载荷约248字节），示例里的noti缓冲区就是利用了这个MTU上限。单字节特征只是GATT表中的一个“权限占位符”，实际发送时协议栈会忽略特征的标称长度，直接把缓冲区里的整段数据塞进通知帧发送——这是BLE协议栈的常见优化，只要特征具备通知权限，就能用这种方式批量传数据。

2. 更大尺寸的特征无法提升吞吐量 #

吞吐量的瓶颈从来不是特征的定义长度，而是BLE链路的MTU大小、连接间隔和数据包发送效率。只要特征支持通知，不管标称长度是1字节还是251字节，协议栈都会按MTU上限打包发送数据。

反而，定义过大的特征长度没有实际意义，还会增加GATT服务发现时的数据包体积，拖慢设备初始化速度。

3. GATT读写的吞吐量确实远低于GATT通知 #

这是两种操作的机制差异导致的：

• GATT通知是单向、无确认的批量推送（也可开启确认通知，但默认无确认），设备能在每个连接间隔内连续发送多帧数据，几乎没有等待开销。
• GATT读写是请求-响应模式：每发一个读写请求，必须等待对方的响应包才能发送下一个，中间的等待时间会大幅拉低传输效率。哪怕是单字节特征的读写，每次操作都要走“请求→响应”流程，吞吐量最多只有通知的1/5甚至更低。

因此传输大文件时，GATT通知（或带确认的指示，吞吐量略低）是最优选择，完全无需纠结特征的标称长度。

内容的提问来源于stack exchange，提问作者bobuhito