1. BLE吞吐测试概述：什么是吞吐量、为什么重要、测试场景分类
吞吐量——这个词你肯定不陌生。但说真的，很多人一上来就问我：「老师，BLE到底能跑多快？」
嗯，这个问题其实没那么简单。吞吐量不是固定的数字，它跟你用的芯片、协议栈配置、空中环境、甚至测试方法都有关系。我做了这么多年蓝牙开发，见过太多人把「理论速率」和「实际吞吐」混为一谈，结果产品量产了才发现性能不达标。
这一章，我们先打好基础。把吞吐量的概念、重要性、以及测试场景理清楚。后面再一步步动手测。
1.1 什么是BLE吞吐量？
吞吐量，说白了就是单位时间内成功传输的有效数据量。单位通常是 bps（bits per second）或 KB/s、MB/s。
注意我强调的「有效」两个字。你发出去100个包，对方只收到了80个，那吞吐量只能按80个算。重传的、丢掉的、协议开销的，都不算。
举个例子：
- BLE 4.2 的理论速率是 1 Mbps
- 但实际应用层吞吐，我测下来通常在 300~700 Kbps 之间
- BLE 5.0 引入了 2M PHY，理论 2 Mbps，实际能到 1.2~1.4 Mbps 左右
核心公式：
实际吞吐量 = (有效数据字节数 × 8) / 总传输时间
总传输时间 = 连接间隔 × 连接事件数 + 重传时间 + 协议处理延迟
你想想看，协议栈每发一个包，都要走完「应用层 → 主机层 → 控制器层 → 空中 → 对端控制器 → 对端主机 → 对端应用」这么长的链路。每一层都有开销。所以实际吞吐永远低于理论值。
1.2 为什么吞吐量测试这么重要？
我遇到过不止一个项目，开发阶段功能跑得挺好，一到客户现场就崩了。为什么？因为客户要的是「每秒传 500 KB 文件」，而我们只在实验室里测了「能不能连上、能不能发几条指令」。
吞吐量测试的重要性，我总结为三点：
- 验证产品性能是否达标——你的产品标称「支持 BLE 5.0 高速传输」，那实际能跑多少？客户会拿这个数据验收。
- 发现协议栈和硬件瓶颈——吞吐上不去，可能是 MTU 没配大、可能是连接间隔太短、也可能是射频干扰。不测，你永远不知道问题在哪。
- 保证用户体验——OTA 升级、日志传输、固件下载，这些场景用户等不起。吞吐太低，用户直接退货。
避坑提醒：
我曾经在一个项目中，芯片手册写的是「BLE 5.0 2M PHY 支持」，结果实际测下来吞吐只有 400 Kbps。查了两周才发现，是协议栈的 DLE（数据长度扩展）没使能。所以，不要相信手册，要相信你亲手测出来的数据。
1.3 测试场景分类
吞吐测试不是一把尺子量到底。不同的场景，关注点完全不同。我个人习惯把测试场景分成三类：
| 场景类型 | 典型应用 | 核心关注点 | 常见瓶颈 |
|---|---|---|---|
| 点对点吞吐 | 手机 ↔ 设备、设备 ↔ 设备 | 最大有效数据速率 | PHY、MTU、连接间隔 |
| 多连接吞吐 | 网关同时连接多个传感器 | 总吞吐 vs 单连接吞吐 | 调度策略、内存带宽 |
| 干扰环境吞吐 | Wi-Fi 共存、多 BLE 设备同区域 | 抗干扰能力、重传率 | 射频设计、跳频算法 |
咱们这门课，主要聚焦在 点对点吞吐 上。因为这是最基础、最常用的场景。你把这个搞明白了，多连接和干扰场景自然能举一反三。
1.4 影响吞吐量的关键因素
这里我列一个清单，都是我在项目中踩过坑的地方：
- PHY（物理层）：1M、2M、Coded（125K/500K）。2M 最快，但距离短；Coded 最慢，但穿墙好。
- MTU（最大传输单元）：默认 23 字节，可以协商到 512 甚至更大。MTU 太小，吞吐直接腰斩。
- DLE（数据长度扩展）：BLE 4.2 引入，让单个包能装更多数据。不使能，一次只能发 27 字节；使能后能到 251 字节。
- 连接间隔：7.5 ms ~ 4 s。间隔越短，吞吐越高，但功耗也越大。
- CPU 处理能力：协议栈处理需要时间。MCU 太慢，吞吐上不去。
- 空中干扰：Wi-Fi、Zigbee、甚至微波炉，都会抢 2.4 GHz 频段。
我的经验：
刚开始做 BLE 吞吐测试时，我建议你先把 MTU 设到 247、连接间隔设到 7.5 ms、PHY 选 2M。这样能排除大部分配置问题，直接看到芯片的「底力」。然后再逐步调整参数，找到性能和功耗的平衡点。
1.5 本章知识体系
下面这张图，帮你把这一章的核心逻辑串起来：
1.6 小结
这一章我们聊了三个核心问题：
- 吞吐量是什么——有效数据速率，不是理论速率
- 为什么重要——验证性能、发现瓶颈、保证体验
- 测试场景分类——点对点、多连接、干扰环境