目录

一、 扫描的本质

二、 扫描的两种基本模式

三、扫描的核心参数

3.1 扫描窗口 vs 扫描间隔

3.2 扫描类型

3.3 扫描滤波

① 白名单滤波

② 广播数据滤波

四、 完整交互流程

五、 扫描窗口与间隔的影响

六、结语

 📚 蓝牙学习系列专栏

---

一、 扫描的本质

中心设备的“耳朵”与“雷达”。扫描，是中心设备（如手机、平板）主动寻找和发现外围设备（如手环、耳机）的唯一手段。其核心流程可以被概括为一种 “监听-解析-回应”​ 的循环：

1. 监听：在特定的无线电频率（广播信道）上监听信号。
2. 解析：对接收到的广播包进行解码，提取出设备地址、信号强度、广播数据等信息。
3. 回应（可选）：如果对某个设备感兴趣，可以发起“扫描请求”以获取更多信息。
4. 上报：将发现的设备信息（名称、服务、信号强度RSSI等）汇总给上层应用。

---

二、 扫描的两种基本模式

被动 vs. 主动。扫描并非只有一种“听”法。根据是否需要与广播设备互动，分为两种模式，其选择对功耗和获取信息的完整性有直接影响。

模式	比喻	行为	功耗	获取信息
被动扫描​	“只带耳朵的听众”​	只接收广播包，绝不发送任何回复。	极低​	仅限于广播包中携带的基础信息（如设备地址、基础服务列表）。
主动扫描​	“带耳朵还带嘴巴的记者”​	先接收广播包，如果感兴趣，会立即发送一个“扫描请求”，以索取更多信息。	较高​	可获得 “广播包” + “扫描响应包”​ 的全部信息（通常包含完整的设备名、详细服务列表等）。

关键点：主动扫描是获取完整设备信息的标准方式。例如，一个设备可能将缩短的名称放在广播包，而将完整的 MyAwesomeHeartRateMonitor长名称放在扫描响应包中，只有主动扫描才能拿到全名。

---

三、扫描的核心参数

想象一下这个场景：你站在一个广场上，周围有很多广播车在循环播放广告。你想知道有没有你感兴趣的内容，于是你竖起耳朵听——这就是BLE的扫描（Scanning）。

扫描的效率、功耗和快慢，由下面几个参数决定：

---

3.1 扫描窗口 vs 扫描间隔

你是“一直听”还是“听一会儿歇一会儿”？这两个参数共同决定了扫描的“节奏”。

参数	技术定义	通俗解释
扫描窗口	单次扫描的持续时间	你每次竖起耳朵听多久
扫描间隔	两次扫描开始时刻之间的时间	你每隔多久听一次

两者有一个硬性关系：扫描窗口 ≤ 扫描间隔。

这句话用“听广播”来解释就特别简单：

• 如果窗口 = 间隔：比如你每隔5秒听一次，每次听满5秒。这意味着你一直在听，没有休息——反应最快，但也最累（最耗电）。
• 如果窗口 < 间隔：比如你每隔5秒听一次，但每次只听2秒。这意味着你听一会儿，歇一会儿——没那么累（省电），但可能会错过在你休息时经过的广播车。

总结：窗口和间隔的差距越大，扫描越省电，但漏掉广播的可能性也越大。开发者需要在“响应速度”和“功耗”之间找平衡。

---

3.2 扫描类型

你是“只听不问”还是“听完再问”？BLE支持两种扫描模式：

扫描类型	技术行为	通俗解释
被动扫描	只接收广播包，不发送任何请求	只听不问——你默默听着广播车在喊什么，但不搭理它
主动扫描	收到广播后，发送扫描请求，获取更多数据	听完再问——你听到一辆广播车路过，主动上前问：“能再详细介绍一下吗？”广播车会回复一个“扫描响应包”，补充更多信息

被动扫描更省电（因为你只接收，不发消息），但获得的信息有限（只有广播包里的31字节）。

主动扫描信息更全（能拿到扫描响应包里的额外数据），但要多发一次消息，功耗略高，也会增加空中的通信负担。

---

3.3 扫描滤波

只关心你想听的。如果广场上有几十辆广播车同时喊话，你不可能全听一遍——太累了。滤波就是帮你“筛选”的功能，让你只关注真正感兴趣的设备。

① 白名单滤波

• 技术定义：链路层只处理白名单中指定设备的广播包
• 通俗解释：你手里有一张“重点关注名单”，名单上的车喊话你才听，其他人的声音自动过滤掉

好处：极大降低干扰，省电又省心。适合“我只想等我的手表广播”这类场景。不过，要注意一点，如果定向广播数据包中的目的地址并非自己，那么也应该抛弃该数据包，即使在自己的白名单中也不例外。

② 广播数据滤波

• 技术定义：主机或应用层根据广播包内容（如服务UUID、设备名称）进行过滤
• 通俗解释：你不在乎是哪辆车，只在乎它在喊什么内容——比如你只对“卖冰淇淋”的广播感兴趣，其他的一概不理

这种滤波通常在上层实现（主机或App），可以非常灵活，比如“只接收心率服务的设备”。

---

四、 完整交互流程

以手机发现智能手环为例，让我们将广播与扫描结合起来，看一个“手机寻找手环”的完整故事，它清晰地展示了一次成功的设备发现所需的所有步骤与时机。

上图揭示了设备发现流程中严格的时序依赖关系：

• 发现的前提是时序重叠：手机的扫描窗口必须与手环的广播事件在时间和信道上都对齐，才能成功捕获广播包。任何一方参数设置不当都可能导致“找不到设备”。
• 速度的权衡：更短的广播间隔和更长的扫描窗口能提高发现速度，但代价是双方设备的功耗都显著上升。
• 完整的发现需要两步：在主动扫描模式下，一次完整的发现需要“广播->扫描请求->扫描响应”三次成功的数据交换，这比单纯的被动监听更能获取信息，但也更复杂。

---

五、 扫描窗口与间隔的影响

理解参数如何影响实际表现，是进行性能优化的关键。

• 场景一：快速发现（高功耗）
  • 设置：扫描窗口 = 扫描间隔（如，均为100ms）。这称为连续扫描，手机射频几乎不停歇。
  • 效果：能在极短时间（通常一秒内）内发现设备。常见于用户主动点击“刷新设备列表”时。
• 场景二：低速发现（低功耗）
  • 设置：扫描窗口远小于扫描间隔（如，窗口20ms，间隔1s）。
  • 效果：手机每秒钟只工作20毫秒，其余时间休眠，非常省电。但可能需要多个广播/扫描周期才能对齐，发现设备可能需要几秒甚至更久。常见于后台持续扫描的场景。

---

六、结语

扫描是广播的完美搭档。一个优雅的设备发现体验，需要广播方和扫描方共同优化：

1. 对于广播方（外围设备）：
   1. 在需要快速被发现时（如配对模式），使用较短的广播间隔（如20-100ms）。
   2. 将最关键的信息放在广播包，将补充信息（如长名称）放在扫描响应包。
2. 对于扫描方（中心设备/手机App）：
   1. 明确扫描目的：需要快速发现就用连续扫描，需要后台监听就用间隔扫描。
   2. 尽可能使用白名单或服务过滤，避免处理不相关的广播包，节省系统资源。
   3. 理解 RSSI（接收信号强度指示）值波动很大，仅适用于粗略的距离估算或信号强弱排序，不能用于厘米级精确定位。

由于个人水平有限，文中若有任何疏漏或表述不清之处，欢迎在评论区指正与交流。

后续更新预告：我将持续更新ble系列的技术科普，下一篇计划《BLE 连接建立过程详解》。如果本文对你有帮助，欢迎点赞、收藏、关注，这是对我最大的鼓励！

---

 📚 蓝牙学习系列专栏

本系列是系统性的蓝牙低功耗(BLE)技术教程，从协议栈原理到实战开发，适合嵌入式开发者、物联网工程师和所有对蓝牙技术感兴趣的读者。

🎯 **系列导航**：本文是《蓝牙学习系列》第4篇  

🔗 **完整专栏**： 蓝牙学习系列专栏