微信小程序设置BLEMTU教程｜协商降级与吞吐优化 – MPForge

一、MTU 协商到底带来什么

结论先讲清楚：MTU 决定一次能传多少数据，协商成大包能明显减少分包次数，但它不是必然成功的能力。

BLE 默认的有效载荷很小，一次只能装二十字节左右；传一帧固件数据或一段传感记录要拆很多包，速度慢还容易出错。把 MTU 协商上去（例如 247），同样数据量需要的包数骤减，吞吐成倍提升，这对固件升级、批量数据同步类场景是质变。但要注意三点现实：协商结果由系统与设备共同决定，小程序申请的值不一定如数批下来；部分机型或系统版本根本不支持应用层协商；协商失败不代表连接失败，只是回到默认包长继续工作。把「MTU 是优化项不是依赖项」想明白，降级策略就是自然而然的结论。

二、协商与降级的标准流程

结论先讲清楚：连接成功后再协商、失败用默认、分包按实际 MTU 适配，三步定生死。

1. 先建立连接：严格在连接成功回调里再发起 MTU 协商，连接未完成就协商必然失败，BLE 连接的完整口径见小程序BLE连接设备教程。
2. 发起协商：向设备申请目标 MTU 值，取系统返回的实际值为准，不假设申请值等于生效值。
3. 失败即降级：协商失败或返回值偏小时，立即按默认 20 字节有效载荷切到小包模式，流程继续不中断。
4. 分包适配：写入端按实际 MTU 计算每包容量并做好分包，分包写入的细节见小程序BLE特征值写入教程；接收端按同一口径重组。
5. 记录机型结果：把每类机型的协商结果与实测吞吐记进机型名单，作为后续适配与排期依据。

验收动作：双端真机各验证一次「协商成功」与「协商失败」两条路径，确认分包逻辑在两种 MTU 下都数据完整。

三、分包写入与吞吐实测

结论先讲清楚：吞吐不是协商出来就完事，分包容量、写入间隔、设备缓冲共同决定真实速度。

实操口径分三件：第一，每包容量按「实际 MTU 减去协议开销」计算，顶格写入容易触发设备缓冲溢出，留出余量反而更快；第二，连续写入之间留出设备处理间隔，包与包硬塞会丢包重传，整体更慢；第三，用真实业务数据测吞吐——传一份完整固件或一整段记录，算端到端耗时，别用单包延迟推算。机型差异要当正式资产管：iOS 与安卓的协商行为不同，同一品牌不同系统版本也可能不同，机型名单表按「机型、系统、协商结果、实测吞吐」四列维护，新机型进名单前不宣称支持大包。这套表格同时也是客服话术的依据——用户反馈「传得慢」，先查机型名单再定位，很多「问题」其实是该机型本来就协商不上大包。

四、自检对照表：联调上线前逐项核对

结论先讲清楚：蓝牙类问题的排查成本高，上电前用表格核对一遍最划算。

设备端能力边界（固件支持的 MTU 上限）由硬件方提供书面口径，软件侧不猜测、不假设。

五、先连通再提速：排期与验证的顺序

结论先讲清楚：MTU 是第二阶段的事，第一阶段把小包链路做稳，提速才有意义。

推荐排期：第一阶段只用默认包长把连接、写入、断连重连做稳，业务闭环先跑起来；第二阶段引入 MTU 协商做吞吐优化，用机型名单灰度放开。这样安排的好处是失败可控：协商出问题，回退到小包链路，业务不受影响；反过来一开始就绑死大包，协商不上的机型直接不可用，等于把优化做成了门槛。验证顺序同理：先验小包完整性，再验大包完整性，最后对比两类机型的端到端耗时，让提速收益有数字可讲。这个顺序也符合审核与客服口径——对外宣传吞吐指标时，只讲机型名单内实测过的数字。

六、避坑清单

蓝牙项目里最费时间的四条坑，都有对应的前置检查。

• 别协商失败硬用大包：按实际返回值适配分包，失败就回 20 字节，数据完整性永远优先于速度。
• 别没有降级策略：大包小包两套路径并存且自动切换，只写一条路径的代码迟早翻车。
• 别拿一台机型测完就上线：双端机型名单化实测，未测机型明确不支持，避免「别人手机都行就我的不行」。
• 别把 MTU 和地理位置能力混淆：蓝牙吞吐与小程序 GEO 地理位置配置无关，附近曝光靠地址与经纬度配置，两个方向的需求分开排。

七、常见问题 FAQ