产品要验证 BT 侧的速率协商用打流工具跑了一轮每秒吞吐稳定在 83 Kbps 左右。后来查明其中一大部分不是链路慢是打流工具自己有病——发送循环里人为加了固定延时、统计把 990 字节的包记成 222 字节、逐包打印吃掉三分之一吞吐。三轮修完83 → 804 → 1208 Kbps15 倍。这段排障的完整过程在下一篇文章本文先讲另一件事那次能顺利定位问题前提是手里有一个设计得足够干净的打流工具——统计口径可信、角色模型对称、不会自己成为瓶颈。这篇文章就把这个打流工具本身拆开讲清楚为什么要认真设计一个测试工具怎么分层双向测试的角色怎么建模它的适用面比看起来宽任何需要验证 BT 链路吞吐的场景打印机、音频串流、固件空中升级这套设计都能直接搬走。一、先想清楚打流到底在测什么写打流工具之前先回答一个问题它测出来的数字要用来做什么决策我们的答案有三层验证速率协商是否正常。经典蓝牙 BR/EDR 连接建立后两端要协商包型与调制方式1-DH5 / 2-DH5 / 3-DH5EDR 逐级提速率。协商是否成功、协商到了哪一级直接决定链路上限——打流吞吐就是协商结果最直接的体检指标。协商失败或降级吞吐立刻现形。验证底层调度能力。协议栈内部的缓冲调度、credit 流控、线程切换效率平时看不出好坏满速压力下才见真章。压力测试协议栈稳定性。长时间满速打流数百上千包/秒是对整个栈最便宜的稳定性测试——内存泄漏、缓冲堆积、异常分支打半小时比点半天鼠标容易暴露得多。这三层答案决定了后面的设计基调工具自己不能成为瓶颈你测不出比自己更快的链路——83 Kbps 那次教训的根源就是工具自己带了三处病度量必须不失真统计错误会让所有优化算错账角色模型要对称双向都要能测。二、分层工具放在哪一层我们的中间件是标准五层应用层 → API 层 → 公共服务层 → 适配层 → 原厂协议栈。打流工具的代码怎么放有两个方案堆进适配层离协议栈最近的那层——写起来顺手但适配层的定位是只做字节搬运塞进打流状态机和统计逻辑后这层就脏了放公共服务层适配层只留写路径的流控判断——主逻辑状态机、统计、线程集中在公共服务层适配层只保留一个职责判断写失败是流控还是错误这个判断必须贴着协议栈做后面讲我们选了后者。三个理由业务集中可测——打流状态机、统计公式都在一个文件里可复用——BLE 侧也有同款打流工具workqueue 承载统计、线程自删这些模式直接继承适配层保持纯粹——它只认识字节和句柄不认识打流这个业务换一个上层调用方它照样工作。先看整体分层与打流代码的位置分层后的职责一览层在打流中承担应用层CLI 命令bt_iperf解析、下发API 层对外唯一入口bt_iperf_cmd 回调注册bt_callback_register签名稳定公共服务层核心iperf 状态机、统计、1 秒定时、pump 线程、收发分发适配层SPP 写spp_port_write含流控判定、SPP 收数据回调协议栈RFCOMM/SPP、credit 流控、链路传输两个跨层接口的细节单独说一下写路径spp_port_write(struct { connHandle, port, data*, length })——length用uint32_t。这不是随手写的打流数据包 990 字节如果哪层接口把长度参数声明窄了比如uint8_t990 就会被截断——真踩过这个坑统计侧因此把吞吐低估了 4.46 倍详见排障篇。接口参数的宽度要跟数据包真实上限对齐这是分层设计里最容易被忽略的一条契约。收路径协议栈回调 → 适配层 → 公共服务层入口回调 →转发进 workqueue 线程处理。协议栈回调的上下文不适合做重活解析、统计、打印收到即转发回调本身尽快返回。三、包设计一次发多长打流数据包固定长度结构就三段具体字段取值按自家协议约定即可不展开帧头(2B) 长度(2B) 数据载荷 → 单包最大 990B990 是怎么定的它不是蓝牙协议的规定是本平台协议栈一次写入接口允许的最大长度。定了之后它要满足两个条件不超过最高速率包型的空口载荷上限。经典蓝牙 EDR 的最高速率包型 3-DH5单包载荷上限1021 字节——990 1021只要速率协商成功一包上空口不用分片协商不到最高速率时协议栈自动按低级包型分片重组应用层无感。链路协商到什么级别吞吐天花板就摆在哪包长取在最高包型之内测出来的数字才反映协商结果本身。贴住本平台栈的上限让测量压着天花板跑。注意这两条是通用原则990 这个数是本平台的结果不是普适值有的栈一次写入就允许 1021 字节直接顶满 3-DH5那就取 1021。关键动作是去查你所用栈的写接口最大长度 对应包型上限按实际情况填你自己的一次发送最大长度照抄任何文章里的数字都没有意义。控制命令帧bt_tp_cmd_t很小8B管启动/停止和统计上报数据包管打流两类帧同走一条 SPP 链路。伪代码示意字段按自家协议自行定义struct bt_tp_cmd_t { /* 控制命令帧共 8B */ uint16_t head; /* 帧头标识用于和 990B 数据包区分 */ uint8_t op; /* 1start 0stop */ uint8_t mode; /* 打流模式 */ int8_t rssi; /* 统计上报时回填 */ uint16_t avg_tp; /* 平均吞吐统计上报时回填 */ };四、命令模型与双向角色bt_iperf op handle port op 1: start-tx本端为发送泵 2: start-rx本端为接收统计 0: stop handle 连接句柄 port SPP 端口号前置流程打流前必须先在 BT 连接上建好 SPP 链路——服务用固定服务 UUID 创建spp_server_createRFCOMM 通道由栈分配返回spp_connect拿到端口号后打流命令才有意义。完整前置链路见开头的流程图BT 连接 → 配对绑定 → 建服务 → 连接 → 打流。两端都能当发起端这是设计里的一个务实决定。双向测试的本意是两个方向都要测主机发给从机tx要测从机发给主机rx也要测——但这两个方向靠主机一端的命令就能跑全主机下发 start-tx 测主机→从机下发 start-rx 测从机→主机不存在测不到的问题。那为什么还要让从机也能发起为的是操作位置可以不挑有些场景下主机侧串口不方便接 PC 输入命令测试人员只能守在从机这边操作主机多连接的场景下一拖多台从机在从机上直接发起、就近验证自己那条链路比去主机上区分下发方便得多。我们的做法是用一个对称角色模型统一两端端role行为发起端CLIENT只发 8B 命令帧不建发送泵等对端 echo回执帧就是收到了三个字的一句话答复回来后才建泵对端SERVER收到 START 帧走 server 分支起统计定时器 每秒上报并 echo 命令帧echo回执这个设计解决了发起方怎么知道对端准备好了的问题命令帧到达 → 对端起好统计 → echo 返回 → 发起方才开始 pumppump 在这里指发送泵一个满速连发包的循环线程像水泵一样一股劲往外灌数据。一个 8 字节的握手不引入任何新协议状态。而echo 之后才建泵这个顺序避免了发起方单方面开跑、对端统计丢前几包的错账。双向矩阵下谁能跑场景谁是发送泵谁统计上报主机发起主机从机从机发起从机主机同一个工具、同一套代码两个方向都能测。顺带一提配套的bt_ping命令用的也是这套角色模型机制完全对称——角色模型做对一次其它工具直接继承。一个必须说的坑双向握手的前提是对端以 SERVER 态响应。如果对端残留着上次的 CLIENT role上次测试没正常终止又没断链会把你的 START 帧当继续打流处理而不 echo发起方干等。所以角色残留的清理路径必须是完备的正常终止走 STOP echo 归零异常残留靠断链回调兜底清——这条链上任何一环缺失双向测试就会偶发打不起来。role 生命周期的完整表格和 STOP echo ping-pong 的实机教训见排障篇。五、统计1 秒窗口软定时器只做轻活统计窗口 1 秒。每秒输出一条[iperf tx]: 0-1 sec avg tp 1167 Kbps, rssi:-21设计点在定时器回调的职责切分。软定时器回调跑在系统的软定时器线程里这个线程被所有定时器共享——回调里干重活会拖长中断关断窗口、拖住其它定时器的精度。原始版本把统计平均、读 RSSI、写 TP 上报、打印全串行塞在回调里副作用是统计窗口自身漂移打印慢一拍sec_time就慢一拍。修法是回调瘦身到只剩两件轻量事软定时器回调(1s): 提交统计 workqueue 无条件重武装定时器 ← 立即返回 workqueue 线程: 统计 avg / 读 RSSI / 上报 TP / 打印 ← 耗时活全在这无条件重武装的意思是哪怕 workqueue 提交失败未就绪等极端情况定时器也继续走最多丢一次统计绝不中断采样节奏。统计公式本身简单avg 窗口累计字节 × 1000 / 实际耗时(ms)换算 Kbps 时按×8/1000口径。口径不重要重要的是全链路一个口径——打印的、上报的、平均的如果换算基准不一致对比就没意义。六、线程模型打流跑起来时有这几条执行流pump 线程满速写 990B 包的发送循环打流核心上报线程每秒把 TP 通知帧写给对端workqueue统计、打印的承载软定时器只做触发器两个设计约束线程退出自删。pump 线程是一次性的——停止即废弃退出前sys_thread_delete归还自身栈。打流是要反复启停的测试不自删的话启停几十轮就是几十个泄漏的栈。防重复启动。运行标志拦截重复 start并发双泵会让计数翻倍。栈大小、优先级统一宏管理一处调整全局生效。七、验收清单设计完成后验证过这些条目作为这个工具可以拿来测链路了的门槛主/从双向打流均正常CLIENT/SERVER 对称角色每秒统计周期稳定软定时器瘦身后窗口不漂移反复启停无线程泄漏自删 标志拦截STOP 一次成功先停泵再发 有限重试统计读数与真实包长一致无截断失真工具就长这样。下一篇讲它投入使用后暴露的三个真实瓶颈——发送循环里的固定延时、uint8_t截断 990B、逐包打印吃掉串口 IO——也就是开头那个 83 Kbps 的完整来龙去脉。系列文章 - 本文第 1 篇蓝牙SPP打流工具设计详解分层架构、双向角色模型与990B包型 - 第 2 篇蓝牙SPP吞吐从83Kbps到1.2Mbps三个隐蔽瓶颈的定位与修复实录相关标签蓝牙SPPRFCOMMiperf吞吐测试嵌入式