前一篇聊了 BLE 透传的基础配置不少朋友照着把 MTU 拉到 247结果速率并没有想象中那么高跑过来跟我说“明明单包都 244 字节了怎么还是只有几 KB/s”。这其实是 BLE 透传速率调优里最典型的一类误区只改了单个参数却没有把整条链路串起来看。这篇文章专门把透传速率的调优路径讲透。我会从物理层、连接参数、MTU/DLE、双端软件实现、应用层协议到实测方法完整过一遍也把我在量产项目里踩过的坑和排查顺序放出来。无论你用 ESP32、nRF52xx 还是其他蓝牙 SoC思路基本通用重点在“先分清楚瓶颈在哪一层”。1. 带宽账本为什么透传永远跑不满规格1.1 物理速率、协议层速率、应用层速率是三个数字很多人看芯片手册写着“BLE 5.0 支持 2Mbps”就以为透传速率能跑到 2Mbps。这是个很自然的误解但物理层 2Mbps 只是最底层空口符号速率真正能拿来传业务数据的速率要打很大折扣。中间隔着的东西有这几层链路层Link Layer有自己的包头、CRC、白名单/加密等开销L2CAP 层要加 4 字节头部ATT/GATT 层要加 3 字节头部每次收发之间有空闲时间IFS和连接事件调度的等待如果使用了带回执的 Write With Response还要等待对端回复一来一回时间直接翻倍。所以实际项目里建议先把“应用层能传多少字节/秒”当作唯一有效指标不要拿物理层速率安慰自己。1.2 各版本 BLE 真正的速率天花板先给一张我常用的参考表基于 1M/2M PHY、MTU 协商到 247、DLE 开启的理想场景链路类型PHY 速率单包最大应用负载单包空中耗时含 IFS理想应用层吞吐BLE 4.0/4.1无 DLE1Mbps约 20 字节约 0.45ms约 44KB/sBLE 4.2DLE 开启1Mbps244 字节约 2.24ms约 109KB/sBLE 5.02M PHY DLE2Mbps244 字节约 1.22ms约 200KB/s别把“理想”当“实际”。上面是极限理想值实际能跑到 40%-70% 就已经算调得不错。比如 1M PHY DLE 的情况下量产项目跑到 40-60KB/s 属于稳定可用的状态2M PHY 跑到 80-120KB/s 是合理的。如果哪个方案标称“稳定跑满 190KB/s”大概率是把小包连续发的测试结果当宣传点端到端实测很难复现。1.3 单包在空中的真实耗时我习惯估算单包耗时公式如下T_packet ≈ (Preamble AccessAddress LL Header L2CAP Header ATT Header User Data CRC) * 8 / PHY Rate IFS以 1M PHY、244 字节用户数据为例空中总字节数 1 4 2 (4 3 244) 3 261 字节传输时间 261 * 8 / 1Mbps 2088us加上 IFS 150us单包约 2.24ms所以一秒最多能发约 446 个包244 * 446 ≈ 109KB/s这就是理论天花板。再往上走只能靠 2M PHY 把空口时间缩短才能突破。明白了这个账你在调优时就不会再盯着“为什么没跑满规格”发愁而是知道自己离理论天花板还有多远差在哪个环节。2. 连接间隔与从机延迟第一把闸门2.1 Connection Interval 是 BLE 的“节拍器”连接间隔Connection Interval决定了主从设备每隔多久在一个固定信道上完成一次握手通信。默认情况下即使你一秒能发几十万个包也要在连接事件到来时才能推出去。很多人以为连接间隔越小吞吐越高。这个直觉对“小包 低延迟”场景成立但对“大包连续传输”不一定成立。看这个计算连接间隔每个事件理论可发包数理论吞吐244B/包7.5ms约 3 包约 97KB/s15ms约 6 包约 97KB/s30ms约 13 包约 105KB/s因为 244 字节的包在空口要 2.24ms一个连接事件里可以塞多个包。连接间隔变大事件频率降低但每个事件里的包数变多理论吞吐几乎不变。实际测试中某些平台反而用较大的连接间隔更容易跑到高速因为连接事件切换和调度开销变少了。调优时不要盲目追求 7.5ms先把“一个事件能塞几包”算清楚。2.2 吞吐公式与参数配置实例如果只看静态理论可以这么近似单事件可发包数 N ≈ floor(ConnectionInterval / T_packet) 应用层吞吐 ≈ 244 * N * (1000 / ConnectionInterval)这只是用来理解方向真实值会受平台调度、接收缓冲、射频环境等因素影响。我实际调参时的推荐起点Connection Interval15ms 或 30msSlave Latency0Supervision Timeout2000ms 或更大MTU协商到 247DLE链路层数据长度协商到 251如果业务对延迟敏感才把连接间隔往 7.5ms 压。纯粹跑吞吐的场景15ms/30ms 通常更稳。2.3 Slave Latency 是吞吐杀手Slave Latency 允许从机跳过指定数量的连接事件以省电为代价换延迟和速率。默认值如果被设成 4 以上吞吐会肉眼可见地往下掉。调优阶段务必把它设成 0特别是在你已经把连接间隔调小的情况下。否则某个连接事件被跳过后前面事件里缓存的数据包只能堆到下一个事件再发瞬时吞吐波动会很严重延迟也会变得不可控。2.4 iOS 和 Android 对连接参数的隐藏限制这是我踩过的最大的坑之一。同样的固件iPhone 连上之后默认连接间隔往往被系统限制在 15ms 或 30ms而部分 Android 手机蓝牙栈会自动用 7.5ms。两端跑出来的速率差距可能接近一倍但问题从不在你的蓝牙协议栈而在系统层。Android 端可以在连接后主动申请requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_HIGH)requestMtu(247)Android 8.0 通过setPreferredPhy尝试切到 2M PHYiOS 端作为 Central 时对连接间隔的干涉能力有限CoreBluetooth 对参数范围有系统约束。作为 Peripheral 时需要在广播的CBAdvertisementData或CBPeripheralManager里正确声明 preferred connection interval让 Central 尽量按你的期望走。调优前先打印或抓包看一下实际协商出来的连接参数不要凭空假设“我请求了 15ms 就一定拿到 15ms”。3. MTU 与 DLE从 20 字节到 244 字节的“扩容配合战”3.1 ATT MTU 协商的本质MTU 协商发生在 ATT 层客户端发起 Exchange MTU Request服务端返回自己的 RX MTU协商结果取二者较小值。这代表双方愿意接收的最大 ATT 包。注意一个细节MTU 值本身不是用户数据长度。ATT Header 占 3 字节所以当协商结果 MTU247 时实际单包用户数据最多 244 字节。如果两端某一端只支持默认 23 字节 MTU协商结果就是 23用户数据只有 20 字节。很多透传模块固件里没有主动发起 MTU 请求主机端也不请求双方就一直按 20 字节跑速率自然上不去这是最常见的第一级瓶颈。3.2 DLE 解决的是链路层“能不能装得下”DLEData Length Extension是 BLE 4.2 引入的链路层能力解决的是链路层单包最大长度。它决定 L2CAP/ATT 层数据能被塞进多大的链路层 PDU 里。MTU 和 DLE 必须互相配合没有 DLE链路层一包只有 27 字节MTU 就算协商到 247也会被链路层拆成多个小包分段传输没有 MTUDLE 只能让链路层传大块数据但 ATT 层依然限制单包应用负载很小。换句话说MTU 是“门”DLE 是“门框”。门做得再大门框不够高大件还是进不来。3.3 协商时机与常见 SDK 接口连接建立成功后尽早发起协商。顺序不重要但一定要等回调结果回来后再开始大批量数据推送。各 SDK 的调用不完全一样AndroidBluetoothGatt.requestMtu(247)底层控制器如果支持 DLE通常在协商过程中会自动处理部分机型需要额外走私有接口iOSCoreBluetooth 没有直接暴露 MTU 协商 API可以用maximumWriteValueLength(for:)查询当前实际单包上限ESP32GATTC 侧有esp_ble_gattc_set_data_len这类接口设置链路层发包长度GATTS 侧在事件回调里接受协商nRF SDK通常在sd_ble_cfg_set(BLE_CONN_CFG_GAP)里配置att_mtu、tx_packet_length等参数。我见过不少人在 Android 侧请求 MTU 后立刻开始写大数据结果请求还没完成onMtuChanged还没回调写进去的包全按 20 字节切这就是“MTU 改了但没生效”的假象。3.4 如何确认协商真的成功了判断 MTU 和 DLE 是否生效最好通过 HCI 日志或空中抓包。Android 开启开发者选项里的“蓝牙数据包日志”会生成 btsnoop_hci.log在 Wireshark 里过滤ATT层可以直接看到 Exchange MTU Request/Response空中抓包用 Nordic BLE Sniffer Wireshark能看到 LL_LENGTH_REQ/LL_LENGTH_RSP以及每个 Data PDU 的实际长度从设备端也可以打印连接事件里的tx_data_length、tx_octets等参数。如果确认协商结果已经是 247/251但速度还是慢问题基本就转移到连接参数、应用层写方式和接收端消费速度上了。4. 双端系统级调优谁是主动方谁在拖后腿4.1 Central 和 Peripheral 在调优中的分工透传场景通常是一个串口蓝牙模块Peripheral和一个手机或网关Central互传数据。MTU 协商通常由 Central 发起Peripheral 响应。如果 Peripheral 一直等 Central 来请求 MTU而 Central 的代码又写得不够积极协商就永远不发生。反过来DLE 协商可以由任意一端在连接后发起。有些 SDK 在连接成功后会默认处理 DLE有些需要主动调用。做固件端时别默认“系统已经开了”打日志确认一下更稳妥。高速透传里另一个容易被忽视的点数据方向不同链路行为完全不同。Central 下发大量数据可以用 Write Without Response连续写Peripheral 上抛大量数据用 Notification前提是 Central 已经订阅 CCCD如果业务里某些指令必须用 Write With Response就单独走指令通道不要把高速数据混在一起否则每个包都在等 ATT Response吞吐被“确认机制”卡死。4.2 iOS 上的实际使用要点iOS 的 CoreBluetooth 比较“黑盒”但有几个经验值得记住外设端能通过updateValue(_:for:onSubscribedCentrals:)发数据发送频率过高时系统内部会排队不是无限制地发调用maximumWriteValueLength(for: .withoutResponse)获取当前允许的单包长度按这个长度分包收到回调后尽量少做耗时操作不要把数据处理逻辑写在didUpdateValueFor characteristic回调里同步做数据库写入、UI 刷新这类事否则系统队列很快堆积手机的射频功耗、后台状态也会明显影响吞吐屏幕关闭后部分系统行为会导致连接事件调度变化。4.3 Android 碎片化与系统蓝牙栈差异Android 机型的蓝牙栈实现差异极大同一套代码在不同手机上可能一个跑 40KB/s一个跑 15KB/s。排查时先看各机型实际协商出来的 MTU、连接参数、PHY。常用调用路径gatt.requestMtu(247); gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_HIGH); if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { gatt.setPreferredPhy( BluetoothDevice.PHY_LE_2M, BluetoothDevice.PHY_LE_2M, BluetoothDevice.PHY_OPTION_NO_PREFERRED ); }setPreferredPhy不是一定会生效需要芯片和系统蓝牙栈都支持 2M PHY部分低端机型会静默失败。想要看到真实结果还是那句话抓 btsnoop、打日志看实际协商结果。4.4 接收端缓冲才是隐藏瓶颈这是很多人到最后才意识到的一点。发送端把把数据发得飞快接收端应用层却在慢慢磨底层协议栈的接收缓冲一旦满了就会对链路层做“零窗口”反馈发送端被迫停下来。表现为抓包看到大量重传、传输速率呈锯齿状、偶尔还会出现蓝牙断连。接收端必须保证及时从系统回调里读取数据哪怕先丢进一个内存队列也不能阻塞回调线程队列消费速度要跟上生产速度否则最终还是一样堆积跨平台框架如果用了 JS 桥接或异步线程处理很容易成为瓶颈实测时尤其注意。发送端同样要有背压机制不能无脑发。iOS 和 Android 都有发送缓冲空间查询手段发现可写空间不够就等一等。5. 应用层协议与传输策略速度最终卡在你写的代码5.1 数据包长度别“刚刚好”MTU 协商到 247 后单包用户数据最大 244 字节。但你在做协议设计时不建议每包都刚好塞满 244 字节。为什么真实链路里还有重传和粘包。一旦你定义“一帧正好等于最大单包长度”接收端做帧解析时只要丢一次包整帧就废了需要重传整帧效率反而低。我更推荐用户数据限制在 200-240 字节之间头部加 1-2 字节序号或类型字段必要时加 16 位 CRC 做完整性校验。留出余量牺牲一点点带宽换取协议稳定性和调试方便。5.2 Write With Response 为什么慢ATT 层有两种写方式Write With Response每个写请求都要等对端 ATT Response数据往返至少跨一个连接事件用于指令通道没问题用于高速透传就是灾难Write Without Response不等待 ATT 层确认底层由链路层负责确认和重传适合连续高速写。Android 里对应writeCharacteristic的WRITE_TYPE_NO_RESPONSEiOS 里对应.withoutResponse的写类型。如果你当前用的是默认写类型先改成 no response速率立刻会上一个台阶。Notice 的发送类似没有 ATT Response但需要接收端订阅后才发送。上抛数据量大时同样建议用 Notification不要用 Indication。Indication 每个包都要回应速度会低很多。5.3 发送队列与内存分配高速透传时发送端不要每发一包就临时申请内存、创建对象或做一次大字符串拼装。这会导致 GC 抖动和系统调用频繁直接把发送节奏打乱。比较好的做法预分配一个发送缓冲区比如 4KB 或 8KB 的环形缓冲Ring Buffer业务数据先写入环形缓冲由发送任务按 MTU 合理大小分包后输出发送回调触发时再从缓冲里取下一段不要边发边拼装接收端同样用环形缓冲接住系统回调数据由独立任务做解析和业务处理。这套设计对固定 MTU 场景很友好也方便加流控。数据量大时发送循环每轮先检查栈里可写空间写不进去就 yield避免无意义的高频调用。5.4 跨平台框架下的“隐藏封装层”如果你用 uni-app 这类跨平台框架开发 BLE 功能需要特别注意框架对底层能力的暴露程度。有些框架只封装了最基础的writeBLECharacteristicValue既不暴露 MTU 协商也不暴露连接参数优先级设置甚至写类型都固定为 with response。这种情况下应用层再努力也跑不高。要么在框架层扩展原生插件把requestMtu、requestConnectionPriority、PHY 切换等能力暴露出来要么干脆对自己要求苛刻一点用双方都支持的最小 MTU 做分片接受速率上限。热搜里那个“uni-app ble ios 可以根据蓝牙的 deviceid 建立连接吗”的问题技术上当然能但别忽略连接能建立只是第一步速率能不能起来取决于框架把多少底层能力留给你。这是跨平台方案做 BLE 透传最容易被低估的坑。6. 实测调优路径从 3KB/s 到 50KB/s 的完整过程6.1 测试环境准备调优之前先搭一个能排除干扰的测试环境。用固定测试固件发送固定长度数据比如每次发 4KB 的伪随机数据不要做文件读写、串口打印接收端只做计数和周期统计不要做解析、存储或 UI 刷新手机距离模块 0.5 米以内去掉中间障碍物确认串口波特率不是瓶颈。关于串口我特别提醒一下很多“BLE 透传模块”标称速率很高但如果你走 UART115200 波特率理论也就约 11.5KB/s就算蓝牙链路能跑 50KB/s数据还是卡在串口。调优时务必把串口波特率调到模块支持的高速率比如 460800/921600或者用 SPI 接口验证否则你会误以为蓝牙能力不足。6.2 分阶段实测过程我最近一个量产项目的实际调参记录可以给你参考阶段改动内容实测应用层吞吐初始状态默认 MTU 23Write With Response约 3KB/s切换到 Write Without Response无 MTU 改动约 8KB/s协商 MTU247 DLE 生效单包 244 字节约 35KB/s连接间隔调整为 15msSlave Latency0参数更新约 42KB/s接收端改为独立消费线程 环形缓冲应用层优化约 48KB/s切到 2M PHY 并确认生效手机与模组均支持 BLE 5.0约 90KB/s每一步改动都很小但叠加起来效果非常明显。如果你当前只有 3KB/s大概率是卡在“默认 20 字节包 带回执写”这两件事上如果你已经有 35KB/s 但上不去重点看连接参数和接收端消费速度。6.3 用抓包数据判断瓶颈当速率卡在某个值不动时我通常先看两张图连接事件分布如果连接事件之间间隔忽大忽小多半是调度异常或系统挤占了蓝牙任务每事件包数和重传率如果重传率超过 3%-5%多半是环境干扰或发送缓冲溢出不一定是配置问题。空中抓包能看到每次连接事件里实际传了多少包、每个包多大、有没有重传。这是判断“配置是否生效”和“瓶颈在哪”最直接的手段。如果不想买抓包设备Android 的 btsnoop 日志也能看到 ATT 层交互足够确认 MTU 协商结果和读写字类型。iOS 侧就相对难一些只能靠设备端日志回推。7. 快速排查清单与几个真实教训7.1 按这个顺序排查别瞎调我把最常踩的坑整理成一张清单遇到“速率上不去”就按顺序过一遍确认物理层是 1M 还是 2M是否真的协商成功确认 ATT MTU 实际协商结果不是“我请求了”而是“双方共同确认了”确认 DLE 是否开启抓包看链路层单包长度确认写类型是 Write Without Response 或 Notification不是带回执确认连接参数实际生效Slave Latency 为 0连接间隔不是异常大确认接收端回调没有阻塞底层缓冲没有满确认串口波特率不是瓶颈确认测试距离和射频环境不要在信号差的地方谈极限速率确认两边蓝牙协议栈版本都支持相应特性老模块可能根本不支持 DLE最后才怀疑芯片能力不要一上来就换芯片。7.2 常见现象对照表现象大概率原因解决方向速率极低只有几 KB/s单包 20 字节 Write With Response切 no response MTU 协商MTU 改了但速率没变化DLE 没开启或 AP 侧不支持大包确认链路层单包长度速率波动大、像锯齿接收端回调阻塞或缓冲溢出接收端改独立消费队列一台手机快一台手机慢平台连接参数或蓝牙栈差异抓包看实际协商结果远距离速率骤降明显射频衰减和重传增加回到测试距离或降低 PHY串口很慢蓝牙再快也没用UART 波特率不足提高波特率或换 SPI7.3 速率、功耗、距离的取舍调优到最后一定会面对这三者的平衡。2M PHY 吞吐高、空口时间短理论上总能量消耗可能反而更低但接收灵敏度比 1M PHY 差距离稍远就容易重传1M PHY 覆盖更好但吞吐上限低如果项目需要穿墙或远距离可以考虑 LE Coded PHY但那是以速率换距离吞吐可能掉到 10KB/s 以下。我一般建议同一套硬件软件做成可选 PHY 和可选连接参数根据业务场景动态切换。实时性要求高、距离近就切 2M距离远、允许低速率就切 1M 或 Coded。不要指望一个配置通吃所有场景。7.4 我在实际调优中的一点体会BLE 透传速率调优真正难的不是某一个参数而是链路太长每一层都在“看似合理”地限速。只有先把账算清楚、把每一层实际协商结果都确认到才不会今天调一下 MTU、明天改一下间隔最后还是在原地打转。我个人的工作习惯是每次调优只改一个变量改完立刻抓包或跑吞吐测试记录。连接参数、MTU、PHY、应用层队列分别控制在已知状态再逐项放开。这样做看起来慢实际上是最快定位瓶颈的方法。很多朋友一上来就“梭哈”把所有配置全改完出了问题根本不知道是哪一项引起的反而更浪费时间。