BLE应用启动时如何处理DeviceWatcher缓存的旧设备问题

问题根因 #

Windows BLE协议栈默认会缓存所有历史配对/连接过的设备信息，DeviceWatcher启动时第一波触发Added事件返回的是本地缓存设备，不是当前实时广播的在线设备。另外BluetoothLEDevice::FromIdAsync接口仅从缓存中读取设备元数据构造实例，不会发起实际物理连接，所以调用必然返回成功，真正的连接请求是在首次调用GATT相关接口时才会触发，因此你会在GetGattServicesAsync阶段才收到不可达错误。

可行解决方案 #

方案1：扫描阶段过滤缓存设备（推荐，实现成本低） #

构造DeviceWatcher时在AQS查询条件中附加广播相关属性的拉取规则，Added事件触发时通过属性有效性判断设备是否在线：

• 注册DeviceWatcher时，额外请求拉取System.Devices.Bluetooth.Rssi、System.Devices.Bluetooth.AdvertisementData两个属性
• Added事件触发后，先检查返回的DeviceInformation对象中上述两个属性是否存在有效值：
  • 有有效值：设备当前正在广播，属于在线设备，可以发起连接
  • 无有效值：属于本地缓存的离线设备，直接跳过即可

如果你不需要连接已配对的设备，可以直接在AQS过滤条件中加入System.Devices.Aep.IsPaired := System.Boolean#False，从根源上过滤掉所有历史配对缓存设备。

方案2：新增快速可达性校验 #

如果不能修改扫描逻辑，可以在拿到BluetoothLEDevice实例后、调用服务扫描接口前，加一个快速校验步骤：
调用ReadCharacteristicAsync接口，用BluetoothCacheMode::Uncached模式读取通用的设备名称特征UUID 00002a00-0000-1000-8000-00805f9b34fb，设置3秒超时：

• 读取成功：设备在线，继续后续服务扫描逻辑
• 读取失败/超时：设备离线，直接释放BluetoothLEDevice实例即可
  该方法比等待GetGattServicesAsync返回的耗时短很多，能快速过滤不可达设备。

方案3：延迟连接过滤 #

缓存的离线设备通常会在Added事件触发后1~2秒内触发Removed事件，你可以做一个简单的临时缓存逻辑：

• 维护一个临时字典存储刚触发Added事件的设备ID
• 收到Removed事件时从临时字典中删除对应设备ID
• 延迟2秒后，仍存在于临时字典中的设备判定为在线，再发起连接
  该方案完全不需要修改现有扫描和连接逻辑，适配成本最低。

内容的提问来源于stack exchange，提问作者Hari