在 BLE 开发中，“广播（Advertising）”是最基础、也是最容易被误解的一部分。

很多开发者知道：

• BLE 有 3 个广播信道：37、38、39
• 设备通过广播让手机发现
• 手机通过扫描拿到设备

但一旦深入，就会出现大量疑问：

• 广播是按 37→38→39 依次发送，还是随机？
• 主端是同时监听 3 个信道，还是轮流扫描？
• 扫描间隔、扫描窗口到底是什么？
• 广播有没有类似“窗口”的概念？
• 广播随机延迟是干什么的？
• 为什么有时候一直扫描不到设备？
• 广播包和扫描响应包是不是都只有 31 字节？
• 扩展广播是怎么回事？为什么能到 251 字节？
• 为什么 BLE 只用 3 个广播信道？
• Wi-Fi 为什么会干扰 BLE？BLE 如何避开？
• iOS 能区分广播包和扫描响应包吗？HCI 日志能看出来吗？
• 扫描时到底应该关注哪些广播数据？

这篇文章我们一次讲清楚。

---

一、BLE 为什么只有 3 个广播信道？

BLE 工作在 2.4GHz 频段，共有 40 个信道：

• 37 / 38 / 39 → 广播信道
• 0 ~ 36 → 数据信道

广播信道的频率：

• 37 → 2402 MHz
• 38 → 2426 MHz
• 39 → 2480 MHz

为什么只用 3 个？

BLE 的目标不是高吞吐，而是：

• 低功耗
• 快速发现
• 抗干扰

如果广播信道很多：

• 功耗会上升
• 扫描复杂度增加
• 协议更复杂

所以 BLE 选择：

用最少的信道完成“发现”这件事

---

为什么选这 3 个位置？

因为：

👉 尽量避开 Wi-Fi 主干扰区

Wi-Fi 一个信道通常占 20MHz，而 BLE 只有 2MHz。
BLE 把广播点分散在频段不同位置，可以降低被 Wi-Fi 完全压制的概率。

---

二、BLE 广播是怎么发的？是顺序还是随机？

结论：

✅ 一次广播事件通常会按 37 → 38 → 39 顺序发送

也就是说：

• 不是随机选一个信道发
• 而是一个“广播事件”内，连续覆盖 3 个信道

你可以理解为：

一次广播 = 连续在 3 个信道发三次

这样可以提高被扫描到的概率。

---

三、主端是怎么扫描的？

主端（Central）通常：

❌ 不是同时监听 3 个信道
✅ 而是通过时间分片轮流扫描

大致行为：

• 一段时间监听 ch37
• 切换到 ch38
• 再切到 ch39

切换非常快，所以你感觉像“同时在扫”。

---

本质理解

广播和扫描之间：

❗没有同步机制，是“概率相遇”

---

四、扫描间隔 & 扫描窗口到底是什么？

1️⃣ 扫描间隔（Scan Interval）

表示：

两次扫描周期之间的时间

---

2️⃣ 扫描窗口（Scan Window）

表示：

在一个周期内，真正监听的时间

---

举例

• Interval = 100ms
• Window = 50ms

表示：

• 每 100ms 开启一次扫描
• 其中 50ms 在监听，50ms 不监听

---

本质

参数	含义
Interval	扫描周期
Window	有效监听时间

---

五、广播有没有“广播窗口”？

没有严格对应的“窗口”概念。

但有：

广播间隔（Advertising Interval）

表示：

两次广播事件之间的时间

---

广播行为

• 到时间 → 发一次广播事件
• 广播事件内 → 37→38→39
• 发完 → 等下一个间隔

---

六、广播随机延迟（Advertising Delay）是什么？

BLE 在每次广播间隔上会加一个：

随机延迟（随机抖动）

---

为什么要这样？

如果没有随机延迟：

• 多个设备可能“完全同步广播”
• 一直互相碰撞
• 永远扫不到

---

加了随机延迟后：

• 时间错开
• 减少长期碰撞

---

👉 本质：

避免“永远撞不上”

---

七、会不会一直扫描不上？

会，而且很常见。

原因包括：

• 广播间隔太大
• 扫描窗口太小
• 无线干扰严重
• 多设备碰撞
• iOS 后台限制
• 广播类型不匹配

---

👉 本质：

BLE 扫描是概率事件，不是保证事件

---

八、广播包 & 扫描响应包都是 31 字节吗？

在**传统广播（Legacy Advertising）**中：

• 广播包最大：31 字节
• 扫描响应包最大：31 字节

但注意：

👉 不是全部都能用来放业务数据

因为包含：

• Flags
• Name
• UUID
• Manufacturer Data 等

---

九、扩展广播是怎么回事？

扩展广播（Extended Advertising）是 BLE 后续版本引入的增强机制。

---

核心思想

把“发现入口”和“数据承载”分离

---

工作流程

Step 1：主广播信道（37/38/39）

发送：

• ADV_EXT_IND（指路包）

内容：

• 我还有更多数据
• 去哪个信道
• 什么时候

---

Step 2：辅助信道（0~36）

👉 这里是关键：

辅助信道 = 从数据信道中借用的信道

不是新增信道！

---

然后发送：

• AUX_ADV_IND
• AUX_CHAIN_IND

👉 真正的大数据在这里

---

十、什么是“辅助信道”？

不是新信道！

👉 本质是：

把原本用于通信的 0~36 信道，用来承载广播数据

---

十一、251 字节是怎么来的？

不是信道决定的！

正确认知：

类型	数据能力
传统广播	31 字节
扩展广播	单 PDU 可达 251 字节

---

本质原因：

👉 BLE 协议升级（如 BLE 5）

带来了：

• 更大 PDU
• 更高链路层承载能力

---

重要结论（非常关键）

❌ 不是“37信道小，0~36信道大”
✅ 而是“广播机制决定数据大小”

---

十二、为什么扩展广播不用 37/38/39 传大数据？

因为：

1️⃣ 主信道必须“轻量”

• 用于快速发现
• 不能被长时间占用

2️⃣ 避免拥堵

• 所有设备都在 37/38/39
• 如果发大包 → 全部阻塞

3️⃣ 解耦设计

功能	信道
发现	37/38/39
数据	0~36

---

十三、Wi-Fi 为什么会干扰 BLE？

因为：

都在 2.4GHz

区别：

• BLE：2MHz
• Wi-Fi：20MHz

👉 Wi-Fi 会“压住”多个 BLE 信道

---

十四、BLE 如何避开干扰？

主要靠：

1️⃣ 频率分散（3个广播信道）

2️⃣ 跳频（连接态）

3️⃣ Channel Map（动态避开差信道）

---

十五、iOS 如何区分广播包 vs 扫描响应包？

结论：

❗iOS 无法明确区分

CoreBluetooth 的：

didDiscoverPeripheral

返回的是：

系统整合后的 advertisementData

👉 不是原始包

---

经验：

• Name 常来自 Scan Response
• 但不能绝对判断

---

十六、HCI 日志能看出来吗？

👉 更接近底层，可以看出来更多细节

通常能看到：

• 广播类型
• 原始数据
• 是否有 scan response

👉 比 iOS delegate 更可信

---

十七、广播里应该关注哪些信息？

重点：

1️⃣ Name

2️⃣ MAC / Address

3️⃣ Service UUID

4️⃣ Manufacturer Data ⭐

5️⃣ Service Data

6️⃣ RSSI

7️⃣ 是否可连接

👉 其中：

Manufacturer Data 最有价值

---

十八、总结（工程师视角）

• BLE 用 3 个信道解决“发现问题”
• 广播是按 37→38→39 顺序发
• 扫描是时间分片轮询
• 扫描是概率事件，不保证一定能扫到
• 31 字节来自“协议限制”，不是信道限制
• 扩展广播引入“辅助信道（0~36）”承载大数据
• 251 字节来自协议升级，不是信道变强
• iOS 无法区分广播包 vs 扫描响应包
• HCI 日志更接近真实情况
• BLE 本质是一个“低功耗 + 抗干扰 + 概率通信系统”

BLE 的广播机制，看似简单，其实背后是一套围绕“功耗、干扰、时序、概率”的精密设计。

真正理解广播，不只是知道“能扫到设备”，而是理解：
为什么有时扫不到、为什么数据不完整、为什么不同平台表现不同。

这些，才是 BLE 工程能力的分水岭。