BLE 连接建立与参数优化
BLE 连接建立与参数优化
考点定位
面试官常问：“BLE 从扫描到连接建立，中间经历了什么？”“Connection Interval 和 Latency 怎么调？调错了会怎样？”
这个章节在蓝牙开发面试中属于中高频考点，权重约 7/10。通常出现在：
- 初级岗位：考察连接流程是否清晰，能否说出关键参数
- 中高级岗位：追问参数优化逻辑、功耗与吞吐量的权衡、实际调试经验
典型问法：
- “说说 BLE 连接的建立过程，从 Advertiser 和 Scanner 两个角色分别讲”
- “Connection Interval 设成 7.5ms 和 100ms 分别有什么影响？”
- “Slave Latency 是干什么的？设成 0 和设成 10 有什么区别？”
1. BLE 连接建立流程
核心概念
BLE 连接是两个设备通过广播-扫描-连接请求三步握手，建立一条双向、分时、跳频的数据通道。
原理（展开）
第一步：广播（Advertising）
- 外设（Peripheral）以固定间隔（Advertising Interval，典型值 20ms~10.24s）发送广播包
- 广播包包含：设备地址、设备名称、服务 UUID、发射功率等
- 广播类型分三种：可连接广播、可扫描广播、不可连接广播（面试常考区分）
第二步：扫描（Scanning）
- 中央设备（Central）在扫描窗口内监听广播信道（37/38/39）
- 收到广播后，可以选择发送扫描请求（Scan Request），外设回复扫描响应（Scan Response）——这步不是必须的，但能获取更多信息
第三步：连接请求（Connection Request）
- 中央设备发送 CONNECT_REQ PDU，包含：
- 连接参数（Connection Interval、Slave Latency、Supervision Timeout）
- 跳频算法种子（Channel Map、Hop Increment）
- 两个设备的访问地址（Access Address）
- 外设收到后回复一个空包，连接建立
连接建立后：双方在约定的 Connection Interval 内交替收发数据包，使用跳频机制在 37 个数据信道上通信。
面试常考细节
广播信道和数据信道是分开的：广播只在 37/38/39 三个信道，连接后跳到 37 个数据信道。面试官可能问“为什么蓝牙要保留三个广播信道？”——为了避开 Wi-Fi 的 1/6/11 信道干扰。
CONNECT_REQ 的时序窗口：外设发送广播后，会在 150μs 内开启接收窗口等待连接请求。如果中央设备在这个窗口外发送，连接会失败。这就是为什么广播间隔和扫描窗口需要匹配。
连接建立的“竞态条件”：多个中央设备同时扫描同一个外设时，谁先发送 CONNECT_REQ 谁就建立连接。外设无法拒绝——这是 BLE 设计决定的。
面试话术参考
“BLE 连接建立本质上是外设主动暴露自己，中央设备主动发起连接的过程。外设通过广播宣告存在，中央设备在扫描到广播后，可以发送连接请求。关键点是：连接请求必须在外设的接收窗口内到达，否则连接失败。实际开发中，我遇到过因为广播间隔设得太短（比如 20ms）导致中央设备来不及处理，或者设得太长（比如 1s）导致连接建立太慢的问题。后来通过调整广播间隔到 100ms，同时让中央设备连续扫描，才达到平衡。”
2. 核心连接参数详解
| 参数 | 含义 | 典型值 | 面试高频考点 |
|---|---|---|---|
| Connection Interval | 两次连接事件之间的时间间隔，单位 1.25ms | 7.5ms ~ 4000ms | 影响吞吐量和功耗 |
| Slave Latency | 从设备可以跳过多少个连接事件而不响应 | 0 ~ 499 | 影响功耗，但会引入延迟 |
| Supervision Timeout | 连接超时时间，单位 10ms | 100ms ~ 32000ms | 必须大于 (1+Latency)×Interval×2 |
2.1 Connection Interval
核心概念：两个设备约定每隔多少时间交换一次数据。
原理：
- 每个连接事件（Connection Event）中，Master 先发，Slave 后发，一来一回算一次数据交换
- Interval 越小，数据交换越频繁，吞吐量越高，但功耗也越高
- Interval 越大，设备可以更长时间休眠，功耗低，但延迟大
面试常考细节：
- 最小间隔限制：iOS 要求 Connection Interval ≥ 20ms（15 个 1.25ms 单位），Android 通常允许 7.5ms，但部分设备有硬件限制
- 吞吐量计算公式：理论吞吐量 ≈ (251 字节 × 包数/事件) / Interval。例如 Interval=7.5ms，每个事件发 4 包，吞吐量 ≈ 251×4/0.0075 ≈ 133KB/s
- 实际吞吐量远低于理论值：因为要考虑 PHY 速率（1Mbps/2Mbps）、包间隔（150μs）、CRC 校验等
面试话术：
“Connection Interval 是 BLE 连接最核心的参数。调小能提高吞吐量，但代价是功耗上升。我做过一个项目，需要传输音频数据，把 Interval 从 50ms 降到 15ms，吞吐量从 20KB/s 提升到 60KB/s，但设备续航从 3 天降到了 1 天。后来用了 2M PHY 和 Data Length Extension，在 30ms 的 Interval 下达到了 80KB/s，功耗反而更低。”
2.2 Slave Latency
核心概念：从设备可以“偷懒”不回应 Master 的轮询，但最多能连续跳过多少个连接事件。
原理：
- 正常情况下，每个连接事件 Slave 都必须回复（即使没有数据也要回空包）
- 设置了 Latency 后，Slave 可以连续跳过 N 个连接事件不回复，只在第 N+1 个事件回复
- 这允许 Slave 在无数据时更长时间休眠
面试常考细节：
- Latency 不减少 Master 的功耗：Master 仍然在每个 Interval 发送轮询包，只是 Slave 可以不回
- Latency 引入的延迟：最坏情况下，数据需要等待 (Latency+1)×Interval 才能发送。例如 Interval=50ms，Latency=9，最坏延迟=500ms
- Supervision Timeout 必须大于 (1+Latency)×Interval×2：否则连接会因超时断开
对比表格：
| 场景 | Latency=0 | Latency=10 (Interval=50ms) |
|---|---|---|
| Slave 功耗 | 高（每 50ms 唤醒一次） | 低（每 550ms 唤醒一次） |
| 最坏延迟 | 50ms | 550ms |
| 适用场景 | 实时控制、音频 | 传感器数据上报、低功耗设备 |
2.3 参数优化策略
面试常考问法：“给你一个智能门锁，电池供电，要求 1 年续航，偶尔开锁时响应时间 < 1s，你怎么配参数？”
参考答案思路：
- 连接建立阶段：广播间隔设 500ms（兼顾发现速度和功耗），扫描窗口设 300ms
- 连接参数协商：
- 初始连接：Interval=50ms，Latency=0（保证首次交互快速）
- 空闲后：通过 Connection Parameter Update Request 改为 Interval=500ms，Latency=10
- 这样空闲时实际唤醒间隔 = (10+1)×500ms = 5.5s，功耗极低
- 开锁时：再次更新参数到 Interval=20ms，Latency=0，保证响应 < 100ms
- Supervision Timeout：设为 10s（大于 (1+10)×500ms×2 = 11s，留余量）
3. 进阶追问：连接参数协商过程
核心概念
连接参数不是一成不变的，连接建立后双方可以通过Connection Parameter Update Procedure协商修改。
原理
- 通常由 Slave 发起请求（因为 Slave 更清楚自己的功耗需求）
- 请求包含：最小 Interval、最大 Interval、Latency、Timeout
- Master 可以接受、拒绝或提出自己的建议值
- iOS 有更严格的参数要求，拒绝率较高
面试常考细节
- iOS 的“黑盒”限制：iOS 只允许在特定范围内修改参数，且不接受过于激进的请求。很多开发者遇到“Android 能连，iOS 连不上”的问题，就是因为参数不符合 iOS 规范
- 协商失败的处理：如果 Master 拒绝，Slave 可以继续使用当前参数，或者断开重连
- LL_CONNECTION_PARAM_REQ PDU：这是链路层的数据包，不是 ATT/GATT 层的
面试话术
“连接参数协商是 BLE 开发中容易踩坑的地方。我遇到过一个问题：在 Android 上可以正常修改 Interval 到 7.5ms，但在 iOS 上总是失败。后来查了 Apple 的 BLE 规范，发现 iOS 要求 Interval 必须是 15 的倍数（即 18.75ms 以上），而且 Latency 不能超过 4。最后我们把 Interval 设为 30ms，Latency 设为 0，两边都正常工作了。”
4. 举一反三：变化问法
“BLE 连接建立时，如果两个设备同时发起连接请求会怎样？”
- 答：BLE 协议规定了 Master 和 Slave 角色，只有中央设备可以发起连接。如果两个设备都配置为 Central，它们不会互相连接——这是协议设计的单向性。
“Connection Interval 和 MTU 有什么关系？”
- 答：两者独立。MTU 决定每个数据包的最大长度（默认 23 字节，可协商到 247 字节），Interval 决定发送频率。优化吞吐量需要同时调整两者。
“为什么 BLE 连接会断开？怎么排查？”
- 答：常见原因：Supervision Timeout 触发、信号干扰、参数不匹配、设备进入休眠。排查方法：抓 air log（用 Ellisys 或 Nordic nRF Sniffer），看断开前的最后一个包是什么。
“BLE 5.0 的 Coded PHY 对连接参数有什么影响？”
- 答：Coded PHY 速率低（125Kbps/500Kbps），但传输距离远。连接参数需要相应调整：Interval 可以设大一些（因为每个包传输时间更长），但 Supervision Timeout 也要相应增大。
总结：面试官想听什么
- 不是背参数：面试官不关心你记得 Interval 的单位是 1.25ms，而是你知不知道为什么这么设计
- 要有对比思维：能主动说出“如果 Interval 小会怎样，大会怎样”
- 要有实际经验：能举出真实项目中的参数配置和踩坑经历
- 要有系统思维：能把连接参数和功耗、吞吐量、延迟、兼容性串起来讲
一句话记住：连接建立是“广播-扫描-连接请求”三步握手，参数优化是“功耗-延迟-吞吐量”三角权衡。