4. 连接参数概念：连接间隔、延迟、超时、更新流程
好，咱们进入正题。连接参数这个概念，说简单也简单，说深也深。我见过不少开发者把这几个参数当成「填数字就行」的东西，结果产品在实际环境中频频断连、功耗爆炸。今天我把这些参数掰开揉碎了讲清楚，顺便聊聊我曾经踩过的坑。
4.1 三个核心参数：间隔、延迟、超时
连接参数本质上就是BLE链路的「心跳协议」。主机和从机通过这组数字来协商：多久联系一次？能忍住多久不说话？多久算失联？
| 参数 | 单位 | 典型范围 | 含义 |
|---|---|---|---|
| 连接间隔 Connection Interval | 1.25 ms | 7.5 ms – 4 s | 两个连接事件之间的时间 |
| 从机延迟 Slave Latency | 个事件 | 0 – 499 | 从机可以跳过的最大连接事件数 |
| 超时时间 Supervision Timeout | 10 ms | 100 ms – 32 s | 超过此时间无通信即断开 |
关键公式：超时时间必须大于 (连接间隔 × (1 + 从机延迟))，否则链路会异常断连。我曾经排查一个蓝牙耳机断连问题，发现产品工程师把超时设成了200ms，间隔30ms，延迟为0——计算一下：30×(1+0)=30ms，明明远小于200ms啊？
等等，我忘了说单位换算。间隔单位是1.25ms，30×1.25=37.5ms，超时200ms没问题。问题出在芯片内部对超时的最小值限制，实际只能用150ms以上，加上延迟后间距只有37.5ms，差一点就触发边界——这种临界情况很容易被环境干扰放大。
4.2 连接间隔：功耗与吞吐量的跷跷板
连接间隔越小，主机轮询从机的频率越高。从机每次都要醒来收发数据，功耗自然就上去了。但好处是延迟低，吞吐量高。反之，间隔大则省电，但数据包要排队等。
我习惯把间隔比喻成「公交车发车间隔」：间隔短，车多，乘客（数据）不用等太久，但耗油（电）；间隔长，省油，但你可能等半天才等到一班车。
- 游戏手柄 / 鼠标：要求低延迟，间隔通常在7.5 – 15 ms。
- 健康手环 / 传感器：数据不频繁，间隔可以拉到100 – 400 ms。
- 音频流：需要稳定吞吐，但也要兼顾功耗，一般在15 – 30 ms。
我的经验：如果产品同时需要高速率和长待机，可以考虑动态调整间隔。我在一个运动手环项目里做过：运动模式下用20ms间隔，待机时自动切换到100ms，续航从1天直接提升到5天。但要注意切换时机的抖动处理，不然用户会感觉数据卡顿。
4.3 从机延迟：让从机偷偷「摸鱼」
从机延迟允许从机在一定次数的连接事件中保持睡眠，不用每次都响应主机。你想想看，如果传感器每10ms上报一次温度，但温度变化很慢，每次响应都在浪费电。这时候把延迟设成9，意味着从机可以连续跳过9次连接事件，只在第10次才真正醒来应答。
但注意了：延迟不是从机想跳就跳的，它必须在连接参数里明确写好，并且主机同意。我在一个门锁项目里见过坑：从机设了延迟49，但主机端的协议栈默认不支持高延迟，结果从机睡了，主机还在等回复，双双超时断连。
| 场景 | 建议延迟值 | 原因 |
|---|---|---|
| 持续数据流（音频、OTA） | 0 | 每次事件都要传输，不能跳过 |
| 间歇传感器（温度、湿度） | 3 – 9 | 允许跳过大部分空轮询 |
| 低功耗按钮（门铃、遥控） | 0 | 因为大部分时间连接未建立或已断开，延迟无意义 |
注意：延迟值过高会导致数据上报延迟变大。例如间隔30ms、延迟99，那么从机最晚可以在99×30ms = 2.97秒后才响应。这对某些实时应用来说是不可接受的。
4.4 超时时间：最后的底线
超时时间是连接的生命线。当主机和从机之间的通信彻底中断时，双方各自开始倒计时，一旦超过超时时间仍未收到任何有效包，链路自动断开。
这个参数设得太短，容易造成误断连。比如环境中有WiFi同频干扰，偶尔丢一个连接事件，超时50ms的话可能直接就断了。设得太长，比如32秒，则用户按了关机键后，对端要等30秒才知道设备已离线，体验极差。
我推荐一个保守的实践：
超时 = 连接间隔 × (1 + 从机延迟) × 2～3倍，再加一个安全余量。例如间隔30ms，延迟5，则最小超时 = 30×(1+5)=180ms，建议取400～500ms。
4.5 连接参数更新流程
很多开发者以为连接参数在建立连接时会自动协商好，之后就固定不变了。其实BLE协议栈允许在连接的生命周期内发起参数更新请求。流程如下：
- 从机或主机发起请求：通过 L2CAP 连接参数更新请求（Connection Parameter Update Request）。
- 对端处理：接收到请求后，检查新参数是否在自身上限内。如果通过，回复接受（Accept）；否则拒绝（Reject）或带有自己的建议值。
- 应用层生效：双方采用新参数进入下一轮连接事件。
注意：更新请求只能在连接建立后的某个时间窗口内发起。有些芯片只允许从机发起，有些则允许主机。我遇到过最头痛的情况是，iOS 设备对参数更新非常严格，它允许的间隔范围远小于Android。如果你想让产品同时兼容两个平台，建议参考 Apple 的 BLE 设计指南，把间隔控制在 30 – 50 ms 之间，否则更新请求会被 iOS 默默拒绝。
典型更新时序：假设初始间隔 20ms，延迟 0。从机发现电池电量低，希望拉大到 80ms，延迟 4。它发送请求，主机确认后，下一个连接事件起使用新参数。整个过程中断流吗？不会。参数更新是「无缝切换」的，但不同芯片实现可能有短暂丢失，我在调试时通常会在更新前后各抓一次log，对比连接事件的时间差来确认切换成功。
4.6 知识结构图：连接参数全貌
下面这张 SVG 图把本章核心概念串在一起。你能看到三个基本参数如何影响功耗、延迟、吞吐量，以及参数更新触发时机。
4.7 实战避坑清单
最后，我把这些年积累的几个切肤之痛列出来，你写代码之前最好看一眼：
- 间隔与超时的比例：我曾把一个智能锁的间隔设为200ms，延迟49，超时只设了3秒。结果连接间隔×(1+延迟)=200×50=10秒，远超3秒超时！锁在正常使用中频繁断连，差点被客户退货。
- 更新时机不对：不要在传输大数据（如OTA升级）的中途发起参数更新，部分芯片会因此丢包甚至死机。建议在升级结束后再切换。
- 兼容性差异：不同手机对连接参数的处理大相径庭。我在华为手机上测试良好的参数，到了小米手机上就频繁掉线。务必在目标机型上做压力测试。
记住一个原则：连接参数不是「越大越好」或「越小越好」，而是「刚刚好」。在开发阶段把三者的关系画一张类似上面的关系图（或用表格列出组合），调试时会省很多精力。