三年前接手一个电池供电的温湿度采集节点需求书上明明白白写着“一颗纽扣电池跑满一年”。硬件同事把蓝牙 BLE 芯片的待机电流压到 1.2 微安拍着胸脯说稳了结果整机实测四十多天就趴窝。后来一路查下去芯片没问题、电池没问题问题出在连接参数上——手机端默认连接间隔 45 毫秒从机延迟设成 0等于每个连接事件都得醒一次收发一轮。这件事把我对蓝牙 BLE 的认知彻底打翻了低功耗从来不是某颗芯片自带的属性而是广播策略、连接参数、GATT 交互节奏和业务逻辑一起算出来的一笔账。这篇就把我从协议栈啃到抓包器、从广播包字节数到 MTU 协商的这套东西完整摊开写给准备上手 BLE 的嵌入式工程师、做物联网终端的产品同学以及被“连不上、老掉线、传得慢”折腾过的人。看完你至少能明白广播包里那 31 个字节怎么花、连接间隔该设多少、为什么你的吞吐只有别人一半、掉线到底是哪一层在发脾气。1. 先想清楚 BLE 适合干什么别一上来就啃协议栈很多人学 BLE 的第一反应是打开协议规范从头读读到 L2CAP 就放弃了。我的建议反过来先建立“这东西到底解决什么问题”的直觉再去补协议细节效率差好几倍。1.1 BLE 和经典蓝牙的分水岭其实不在“低功耗”三个字市面上讲 BLE 的文章几乎都会说“BLE 就是低功耗版蓝牙”这话对但不准确容易误导选型。真正的分水岭在于连接模型经典蓝牙是面向持续数据流的一条链路建立起来就像拉了一根管子音频、文件传输都走这条路BLE 是面向“事件”的大部分时间链路处于休眠只在约定的时间点醒来交换几个字节交换完立刻睡回去。这个差异直接决定了适用边界。你要传一首歌、要做免提通话BLE 的带宽和调度模型根本不合适。你要做一个每 10 分钟上报一次温度、平时深度休眠的传感器用经典蓝牙就是灾难。我见过有团队拿 BLE 做实时语音对讲折腾两个月最后换方案——不是技术做不到是强行在不合适的模型上叠业务功耗和延迟两头都不讨好。从数据上看这个差别更直观BLE 的物理层速率是 1 MbpsBLE 5.0 引入 2 Mbps看起来不低但有效吞吐受连接间隔、每事件包数、MTU 三重限制实际能做出来的稳定单向吞吐通常在几百 kbps 量级。而它的平均功耗可以做到微安级这才是它真正的杀手锏。1.2 一个反直觉的结论BLE 的省电是“用时间换的”新手最容易犯的错误是把 BLE 当成“一直连着、随时可发”的通道。你这么理解代码写出来就是主循环里不断查有没有数据要发有就立刻发。结果功耗炸掉因为每一次主动发起通信都意味着一次射频唤醒。正确的模型是从机外设和主机手机/网关事先约定一个时间表叫连接事件Connection Event。每个连接事件里主机先发一个包从机必须在约定的窗口内回应如果从机没有数据要说它可以连续跳过若干个连接事件不回应这叫从机延迟Slave Latency。这段时间里射频前端完全关闭。所以一颗纽扣电池能不能撑一年取决于三件事连接间隔多长、从机延迟多大、每个连接事件里实际交换了多少包。这三件事全在你手里而不是在芯片厂手里。后面第 6 章我会给一套完整的倒推计算方法把“一年”这个目标拆成可配置的参数。1.3 什么场景该用 BLE什么场景该绕开我自己的判断标准比较粗暴分三档场景特征推荐方案理由小数据量、低频次、电池供电、和手机交互BLE手机原生支持无需配对驱动功耗可控需要持续较高带宽500 kbps、多节点组网其他无线方案BLE 的连接数、调度开销会拖垮你需要 Mesh 组网、几十上百节点BLE Mesh 或私有协议单连接模型撑不住得上泛洪或路由需要和手机做音频经典蓝牙BLE 音频有专门规范但生态另说特别提醒一点如果产品核心卖点是“和手机 App 交互”BLE 几乎是唯一理性选择因为手机端不需要用户装驱动、不需要额外权限除了新版本系统对蓝牙权限的收紧开箱即用。这个体验优势值很多技术妥协。2. 协议栈从下往上拆每一层到底替你干了什么协议栈不是背出来的是“出问题时能定位到第几层”的工具。我的习惯是把协议栈当成快递系统物理层是公路链路层是货车调度L2CAP 是分拣中心ATT 是快递单GATT 是货架编号GAP 是营业厅规则。2.1 物理层与链路层广播包那 31 个字节到底怎么花先讲最实的东西——广播包。传统广播的 PDU 载荷是 37 字节其中 6 字节是设备地址剩下31 字节就是你能自由支配的全部空间。这 31 字节里还要塞长度字段和类型字段每段数据占 2 字节头1 字节长度 1 字节 AD Type所以实际能放的有效数据远少于 31。一个典型的广播包拆开长这样0x02 0x01 0x06—— 长度 2类型 0x01Flags值 0x06不支持经典蓝牙 通用可发现0x05 0x09 N o d e—— 长度 5类型 0x09完整设备名值 “Node”0x0A 0xFF ...—— 长度 10类型 0xFF厂商自定义数据后面全是你自己的字节很多产品的广播包就是在这里翻车的设备名起太长比如 “TempSensor-Pro-2024-V2”一下吃掉 20 字节厂商数据只剩几个字节还得塞电量、状态、序列号。我的做法是设备名压到 6~8 个字符能省则省真要区分设备靠厂商数据里的 ID别靠名字。另外广播包是明文广播的任何在范围内的设备都能收到不要往里塞密钥、Wi-Fi 密码这类东西——这是我在真实项目里见过的最离谱的安全问题。BLE 5.0 之后有了扩展广播Extended Advertising单包可以到 254 字节还能分链。但注意兼容性老手机、老网关不一定支持做产品时要么降级要么在广播包里放个标志位让主机知道该用哪种方式扫描。2.2 L2CAP 与 ATT把“读写”这件事标准化L2CAP 这一层平时不用管但有个功能必须知道它是 MTU 协商的载体。ATTAttribute Protocol定义了一套极简的操作码本质上就是“对某个句柄做读、写、订阅”。默认 MTU 是 23 字节减去 3 字节 ATT 头一个包最多带20 字节有效载荷。这个数字是所有 BLE 新手第一个撞上的墙。ATT 的常用操作码值得记一下抓包时一眼就能认出来操作码名称是否需要响应典型用途0x0ARead Request是读特征值0x0BRead Response—读的回应0x12Write Request是可靠写0x13Write Response—写的确认0x52Write Command否高频写不等确认0x1BHandle Value Notification否从机主动推数据0x1DHandle Value Indication是需要确认的推送Write Command和Notification这两条“无需响应”的通道是 BLE 吞吐和功耗优化的核心抓手后面的章节会反复用到。2.3 GAP 与 GATT角色和服务模型GAP 管的是“我在广播什么、我要不要连、连上之后谁是老大”。两个角色广播方叫外设Peripheral扫描并发起连接的叫中心Central。注意这两个角色和数据流向无关——外设也可以给中心推数据很多人误以为“外设只能被读”这是混淆了 GAP 角色和 GATT 权限。GATT 是数据组织方式一套“服务 → 特征值 → 描述符”的树。这里有个特别容易被忽略的点GATT 的每个节点都有个 16 位句柄Handle运行时会变。你写的代码绝对不能把句柄写死成常量必须在服务发现阶段动态读出来。我见过有代码把句柄硬编码成 0x0021换一批固件就崩排查了两天才发现是服务表里多加了一个描述符导致后面全体后移。UUID 也有讲究16 位 UUID 只能用于官方注册的服务自定义服务必须用 128 位。128 位 UUID 在广播包里要占 16 字节几乎吃掉半个广播包所以常见做法是——广播包里只放 16 位的自定义标识完整 128 位服务定义放在连接后的服务发现里。2.4 SM 安全层配对、绑定和那几种让人头大的组合安全层最容易被跳过但出货产品跳不过。BLE 的配对方式有四种Just Works、Passkey Entry、Numeric Comparison、OOB。选哪种取决于双方有没有输入输出能力。配对方式需要的能力抗中间人攻击典型场景Just Works无否无屏传感器安全性最低Passkey Entry一端有键盘是手机输 PIN 配设备Numeric Comparison两端都有屏是手机与带屏设备OOB带外通道是有 NFC 或二维码我的实践建议是没有屏幕的设备用二维码或 OOB 传递配对信息别裸用 Just Works。裸用 Just Works 意味着任何人在你旁边都能连上虽然不影响功能但如果你的设备能开门、能控制电机这就是个大洞。BLE 4.2 之后引入了 LE Secure Connections密钥交换强度够了但配对方式选错照样白搭。还有“绑定”Bonding和“配对”Pairing的区别配对是这一次建立密钥绑定是把密钥存下来下次直接用。产品上要区分“临时连一下”和“长期信任设备”后者必须绑定否则每次重连都要走一遍配对流程用户体验很差。3. 广播模式与连接模式两套完全不同的设计思路很多人做 BLE 产品上来就写连接逻辑其实有大量场景根本不需要连接——只用广播就够了功耗能低一个数量级。3.1 广播包设计把信息塞进去让主机不用连就能判断最典型的例子是温湿度信标。设备每 2 秒广播一次广播包里就带着当前温度和电量手机扫到直接解析根本不用建立连接。这种“无连接”模式的好处是设备不需要维护连接状态射频开启时间极短平均电流可以做到十几微安。广播包设计有几个经验点第一厂商自定义数据AD Type 0xFF前面一定要放公司标识符虽然自定义场景下没人校验但养成习惯能避免和别人的设备混淆。第二字节序统一我所有项目都强制小端且在多字节字段前放一个版本号方便以后扩展字段。第三留扩展位我一般会预留 2~3 个字节填 0后面加字段时不用改版本号。广播类型也要选对。ADV_IND是可连接可扫描的通用广播最常用ADV_NONCONN_IND是不可连接的纯广播功耗最低适合纯信标ADV_SCAN_IND可扫描但不可连接适合需要响应扫描请求返回更多数据的场景。选错了不影响功能但白白多耗电。3.2 连接参数三个数字决定功耗和延迟的平衡一旦建立连接就有三个参数需要协商连接间隔Connection Interval、从机延迟Slave Latency、监督超时Supervision Timeout。连接间隔范围 7.5 ms 到 4 s步进 1.25 ms。间隔越短响应越快功耗越高。从机延迟 0 到 499表示从机可以连续跳过多少个连接事件不应答。监督超时 100 ms 到 32 s超过这个时间没收到对方任何包就判定断连。这里有个硬性约束公式必须记住Supervision Timeout (1 Slave Latency) × Connection Interval × 2不满足这个条件链路会因为“长时间没收到包”而误判断连。我踩过这个坑连接间隔 100 ms从机延迟 20监督超时设了 2 s算下来 (120)×100×2 4200 ms 2000 ms链路每隔几分钟就断一次日志里看是超时断开查了半天才反应过来是公式不满足。还有一个现实问题主机尤其是手机不一定接受你请求的参数。iOS 对连接间隔有明确范围限制最小 15 ms且对某些档位有偏好安卓各厂商实现差异更大。所以正确的做法是从机主动发起参数更新请求然后读回实际生效的值用实际值做后续的资源预算不要假设请求成功就万事大吉。3.3 扫描策略主动扫描和被动扫描的代价不一样主机侧扫描也分两种被动扫描只收广播包主动扫描收到可扫描广播后会再发一个扫描请求Scan Request外设回一个扫描响应Scan Response这样就多出 31 字节的空间。这个机制很实用——把静态信息设备型号、序列号放扫描响应里把动态信息温度、电量放广播包里既不浪费周期又扩大了总容量。代价是主动扫描的主机功耗略高而且外设要多响应一次。扫描窗口和扫描间隔的比例直接决定发现延迟和功耗。做手机 App 时我的经验是前台扫描用 100% 占空比窗口间隔保证秒级发现后台扫描降到 10% 左右否则手机电量掉得肉眼可见。这个细节很多产品经理不理解总觉得“蓝牙扫描又不费电”实际上持续全占空比扫描能让手机一小时掉 15% 的电。4. 服务和特征值怎么设计决定了后期维护的痛苦程度协议栈通了只是“能连上”真正决定项目好不好维护的是 GATT 表怎么设计。我接手过一张有 60 多个特征值的表没有文档命名全是char_01到char_60改一个字段要反编译固件。4.1 特征值属性的组合每一个都有实际含义一个特征值Characteristic的属性可以是 Read、Write、Write Without Response、Notify、Indicate 的组合。这些不是随便勾的每一项都对应实际行为Read主机可以主动读当前值。适合状态查询类数据。Write主机写入并等确认。适合配置类数据保证到达。Write Without Response主机写入不等确认。适合高频数据流牺牲可靠性换吞吐。Notify从机主动推送不等主机确认。适合传感器数据。Indicate从机主动推送等主机确认。适合关键指令保证不丢。我的设计原则是每个特征值只承担一种语义不要把配置和数据塞在同一个特征值里。另外长度可变的数据一定要加一个“长度描述符”或者在数据头里带长度字段否则主机无法判断有效字节数。还有个坑Notify 必须由主机写 CCCD客户端特征配置描述符UUID 0x2902开启不写这个描述符从机发 Notification 主机会直接丢弃。新手最常问的“为什么我发了通知手机收不到”八成是没开 CCCD 或者 CCCD 写错了句柄。4.2 MTU 协商从 20 字节到 244 字节的那一步默认 MTU 23有效载荷 20 字节。传一个 100 字节的数据包需要分 5 次每次都要等一个连接事件延迟和功耗都难看。所以连接建立后第一件事应该是发起 MTU 交换。协商流程很简单主机发 MTU Exchange Request 带上自己支持的 MTU从机回 Response 带上自己的双方取较小值。常见配置是请求 247对应有效载荷 244这是很多芯片栈的默认上限。协商到 247 之后一个包能带 244 字节效率提升十几倍。但要注意两点第一MTU 协商不是强制的有些主机不发这个请求从机就得用默认 23 工作代码必须兼容。第二协商结果可能小于请求值比如你请求 247手机只给 185那有效载荷就是 182。所以发送逻辑里不能把 244 写死要动态读当前 MTU。再往上还有数据长度扩展DLE把链路层 PDU 从 27 字节扩到 251 字节。MTU 247 加上 DLE 才是完整的高吞吐配置。这两个是不同层的东西经常被混为一谈——MTU 是 ATT 层的事DLE 是链路层的事两个都得开才有最佳效果。4.3 通知和指示的区别用错了就是给自己挖坑Notification 不需要确认发出去就不管了速度快但可能丢。Indication 需要主机回确认可靠但一次只能有一个在途速度慢。判断标准很简单丢了会不会出事传感器周期数据丢了就丢了下一包补上用 Notification。固件升级的每个数据块、开锁指令、支付确认这些丢了要出大事用 Indication 或者在上层自己做序号确认。我吃过一次亏早期一个设备的参数下发用 Notification结果在干扰强的环境下偶尔丢一包设备配置就是错的还查不出来。后来全部改成 Write Request带确认 从机回写结果问题消失。代价是配置一次多花几十毫秒完全可接受。5. 吞吐上不去先把这几个参数逐个排一遍“我的 BLE 传输只有 20 kB/s正常吗”——这个问题我被问过太多次答案几乎都是不正常配置没调对。5.1 影响吞吐的五个变量吞吐不是单一参数决定的是五个变量的乘积效应变量典型低配值典型高配值对吞吐的影响连接间隔100 ms7.5 ms线性正相关每事件包数1~24~6线性正相关ATT MTU23载荷 20247载荷 244近似线性链路层 PDUDLE27 字节251 字节消除分片开销物理层速率1 Mbps2 Mbps近似翻倍理解这个表的关键是连接间隔决定了“多久能说话一次”MTU 决定了“一次能说多少”每事件包数决定了“一次能说几句”。三者是乘法关系任何一个拖后腿整体就上不去。举个实际算例。连接间隔 7.5 msMTU 247有效载荷 244DLE 开启1 Mbps 物理层。一个满载数据包在空中的时间大约是 (1 前导 4 接入地址 2 头 251 载荷 3 CRC) 261 字节 ≈ 2088 μs加上包间隔 150 μs主机发一包从机回一包粗算一个来回约 2.4 ms。7.5 ms 的连接事件里能塞 3 个来回也就是 3 × 244 732 字节除以 7.5 ms得到约 97.6 kB/s折合 780 kbps。实测通常能到 600~750 kbps因为要留出协议栈调度余量。反过来看低配连接间隔 100 msMTU 23每事件 1 包那就是 20 字节 / 100 ms 200 B/s。差了将近 500 倍。所以“BLE 传得慢”这个印象绝大多数情况是配置问题而不是技术上限。5.2 实测中的三个意外配置调对了实测还是达不到理论值通常是这三件事第一手机端的连接间隔被系统改回去了。你请求 7.5 msiOS 可能给你 15 ms 甚至 30 ms因为它要兼顾系统里其他蓝牙设备的调度。这个只能在代码里读回实际值按实际值算预期别拿请求值当承诺。第二发送队列没有填满连接事件。很多协议栈的实现是“应用层调一次发送接口底层发一包”中间没有批量填充机制。想跑满每个连接事件得用“多发”接口或者自己在回调里连续塞包。这个细节各家的栈不一样要翻文档或者读源码。第三2M PHY 开了但对方不支持。BLE 5.0 的 2M PHY 需要双方都支持并且协商成功只开一边没用。而且 2M PHY 的覆盖范围比 1M 略差远距离场景反而可能因为重传导致实际吞吐下降。5.3 分包策略应用层怎么配合底层即使 MTU 到 247一个固件包动辄几十 KB还是要分包。我的做法是应用层自己定义一个小包头包含序号、总包数、当前包长度每个包控制在 MTU-3 以内。接收端按序号拼装缺包就请求重传。这里有个性能陷阱如果每包都等确认再发下一包吞吐会被 RTT 拖死。正确做法是滑动窗口一次连发 N 包N 取 4~8只对最后一个包或者按周期做确认。这样能把链路的并行能力用起来。6. 功耗这笔账必须倒着算回到开头那个四十天就趴窝的项目。后来我重做了功耗预算结论很清楚不是硬件不行是参数没算。6.1 从电池容量倒推平均电流一颗 CR2032 标称容量 220 mAh考虑自放电和低温衰减按 180 mAh 可用算。要撑一年8760 小时平均电流上限是180 mAh ÷ 8760 h ≈ 20.5 μA也就是说整个系统的平均电流必须压在 20 微安以内。这个预算非常紧任何一次“顺手多连一下”都可能超标。平均电流的构成公式是I_avg (I_peak × T_event I_sleep × (T_interval - T_event)) ÷ T_interval其中I_peak是射频收发时的峰值电流常见 5~10 mAT_event是每个连接事件的实际持续时间T_interval是连接间隔。代入一组数峰值 8 mA事件持续 3 ms连接间隔 100 ms睡眠电流 1.5 μA。I_avg (8 mA × 3 ms 0.0015 mA × 97 ms) ÷ 100 ms (24 0.1455) ÷ 100 ≈ 0.241 mA 241 μA241 微安是预算的 12 倍。这就是四十天趴窝的真正原因——每次连接事件都在唤醒射频10 次/秒谁也扛不住。6.2 三个立竿见影的调整第一拉长连接间隔。从 100 ms 拉到 1 s同样的事件时长平均电流降到约 24 μA。再拉到 2 s降到 12 μA进预算了。代价是下行指令延迟变成秒级能不能接受取决于业务。第二用从机延迟。从机延迟设成 9连接间隔 100 ms意味着从机最多连续 9 个事件不应答只在第 10 个事件醒来。等效间隔变成 1 s但主机仍保留 100 ms 的调度粒度需要紧急下发时可以立即生效主机发数据时从机必须回应延迟被打破。这个机制比直接拉长间隔更灵活是我的首选。第三砍掉不必要的连接。如果只是周期上报数据根本不需要维持连接——用广播发数据主机扫到就解析。射频开启时间从“每 100 ms 醒一次”变成“每 2 s 发 3 ms”差了一个数量级。调整后的实测数据同一块板子同一颗电池配置平均电流理论续航间隔 100 ms延迟 0241 μA约 31 天间隔 1 s延迟 024 μA约 312 天间隔 1 s延迟 46.2 μA超过 1 年纯广播2 s 一次4.8 μA超过 1 年注意纯广播那行看起来只比延迟 4 好一点但它的优势是没有连接维护开销主机侧也不用一直连着系统复杂度低很多。所以做产品时先问一句这个场景真的需要连接吗6.3 那些容易被忽略的漏电点参数调好了还有几个隐蔽的耗电源头调试日志。串口打印在低功耗场景下是致命的一条printf唤醒 CPU 的时间可能比整个连接事件还长。量产固件必须关日志或者改成环形缓冲异步输出。GPIO 悬空。未使用的引脚如果配成输入且外部悬空会有漏电流。我在一个项目里因为一个悬空引脚多耗了 8 μA占了预算的 40%。唤醒后的收敛时间。射频从睡眠到可用的建立时间通常几百微秒到 1 ms是纯浪费要算进T_event里。有些栈支持“提前唤醒”优化值得翻文档。广播间隔的抖动。广播间隔如果设成固定值多个设备可能周期性撞车导致重传。加一点随机抖动±10%反而更省电。7. 连不上、老掉线、数据丢一套可复现的排查链路BLE 的故障现象高度相似但根因可能在第 1 层到第 7 层的任何地方。我总结了一套从外到内的排查顺序基本能覆盖九成问题。7.1 连不上先分清是“扫不到”还是“连不上”这两个是完全不同的问题但用户描述都是“连不上”。扫不到说明广播没发出去或者发得不合规。排查顺序用手机端的通用调试 App 扫一遍能看到设备名说明广播正常看不到就查固件里广播是否真的启动了、广播数据长度是否超限超过 31 字节很多栈会直接报错但不崩溃、广播间隔是否设得太长。还有一个隐蔽原因设备地址类型配错用了随机静态地址但没正确设置某些主机会过滤掉。扫得到但连不上通常是连接参数或者安全要求的问题。检查清单广播包里是否声明了可连接ADV_IND而不是ADV_NONCONN_IND设备是否已经连了别的中心达到连接数上限是否要求绑定但主机没有配对信息导致连接后立刻被踢白名单是否开着但主机不在名单里我在一个量产项目上遇到过第 4 条出厂固件开了白名单模式本意是只允许自家网关连接结果产线测试时手机连不上还以为是射频问题查了两天才发现是白名单。凡是加了访问限制的功能一定要留一个恢复出厂/关闭白名单的入口。7.2 老掉线八成是监督超时或者射频环境掉线的排查要有时间维度。我的做法是记录每次断连的原因码各栈都有对应的回调参数然后分类统计断连原因可能根因处理方向监督超时0x08参数不满足公式、射频被干扰按公式校验参数加大超时远端用户终止0x13主机主动断开查主机侧逻辑是否超时清理连接建立失败0x3E信道拥挤、连接窗口太窄换广播信道加长连接窗口配对失败0x05密钥不匹配、绑定信息失效清绑定重配监督超时是最常见的。除了前面说的公式约束还有一个隐藏因素Wi-Fi 2.4G 干扰。BLE 的 40 个信道里有 37 个数据信道和 Wi-Fi 的 1/6/11 信道大量重叠。如果设备装在路由器旁边丢包率会显著上升表现为“在办公室好好的装到现场就老掉”。解决办法是开启信道分类或者自适应跳频大部分现代栈默认开了实在不行就把设备挪开半米——听起来很土但有效。7.3 数据丢从 CCCD 到并发缓存逐层查“手机收不到数据”这个现象我按这个顺序查第一CCCD 有没有写很多栈在没开通知的情况下直接丢弃不报错。第二特征值的 Notify 属性有没有在 GATT 表里声明第三发送时返回值是什么缓冲区满返回NO_RESOURCE和应用层丢包要分清。第四手机的蓝牙缓存有没有问题安卓上换 GATT 表结构后不关蓝牙会读到旧缓存这个坑我踩过——改了固件加了个特征值手机端死活看不到关一次蓝牙就好了后来才知道是系统缓存了服务列表。还有一个经典问题发送速度超过连接事件的处理能力导致协议栈内部缓冲溢出。表现是发着发着就静默丢包没有任何错误码。解决办法是加流控每个连接事件最多发 N 包或者根据发送回调的返回状态做退避。提醒一句不要把“发送接口返回成功”当成“数据已经到达对方”。BLE 的发送成功通常只代表数据进了本地协议栈缓冲真正的端到端到达需要应用层自己做确认。7.4 抓包是终极手段但要会看软件层查不出来的时候就得上空口抓包。抓包器的价值在于能看到空中的每一个包、每个连接事件的时序、重传次数。看包的时候重点关注三个指标重传率高说明干扰严重、每事件包数低说明发送策略没跑满、连接间隔实际值和你请求的是否一致。手工分析时序比较累我一般先看统计如果重传率超过 5%先解决射频环境如果每事件只有 1 个包而 MTU 是 247说明发送队列没填满回头改应用层。这两个指标能定位八成的性能问题。8. 几个不值得再踩一遍的坑写到这儿把几个最疼的教训单独拎出来。广播包超长不报错。有些栈在广播数据超过 31 字节时会静默截断你以为加了厂商数据实际发出去的是残缺的。每次改广播包都要用手机端工具核对实际收到的字节别只看代码。句柄硬编码。前面提过这里再强调一次所有句柄必须动态发现。更进一步把服务发现的结果缓存下来并加版本号固件升级后如果 GATT 表变了主动让主机重新发现。把配对当加密。配对只解决“双方有共同密钥”不解决“对方是谁”。Just Works 配对能被中间人轻松截获如果你的数据敏感必须用带认证的配对方式或者在上层加应用层加密。忽略连接数上限。芯片标称支持 8 个连接实际跑起来 4 个就开始丢包因为 RAM 不够。选型时一定要看“同时连接数”对应的缓冲配置而不是数据手册的最大值。没做固件升级通道的预留。产品出货之后才发现没法远程升级这是最绝望的。GATT 表设计时就把 OTA 服务和特征值留好哪怕第一版不用。测试只用一台手机。iOS 和安卓的连接参数行为差异巨大安卓各厂商又不一样。我现在的规矩是最少三台设备覆盖一台 iOS、一台主流安卓、一台低端安卓全过了才算联调完成。最后分享一个我自己一直在用的习惯每个 BLE 项目建一个“参数表”文档记录连接间隔、从机延迟、监督超时、MTU、DLE、广播间隔、发射功率这七个值以及它们为什么这么设。这个文档在项目交接和后期调优时的价值远超你当时花的那十分钟。