UWP(Windows 10)中如何获取蓝牙BLE设备的完整设备名称列表

问题本质 #

• BLE传统广播包单包载荷上限仅31字节，扣除广播标志位、服务UUID、发射功率等公共字段后，剩余空间不足以承载12字符的完整名称。绝大多数设备会把长名称放在主动扫描触发的扫描响应包中，BluetoothLEAdvertisementWatcher默认使用被动扫描模式时，根本不会向设备请求扫描响应，自然只能拿到截断的8字节短名称，甚至拿不到名称字段。
• 不同工具、系统界面的名称显示差异，完全来自扫描策略区别：LightBlue默认用主动扫描+更长的响应等待窗口，能稳定拿到扫描响应里的长名称；EFR Connect、Windows旧版设备枚举逻辑的扫描等待窗口短，没等到扫描响应就停止接收，就只能拿到短名称。
• 配对后即使取消配对也能显示长名称，是因为配对流程中系统会主动建立GATT连接，读取通用访问服务下的设备名称特征，并将结果写入系统级设备缓存，后续枚举直接读取缓存，不需要再等广播包。

可落地实现路径 #

1. 先把广播监听器配置对 #

不要上来就换接口，先调整BluetoothLEAdvertisementWatcher的基础配置：

• 将扫描模式设置为BluetoothLEScanningMode.Active，显式要求扫描时主动向设备发送扫描请求，触发设备返回携带完整名称的扫描响应包。
• 不要在广播过滤条件里加名称字段规则，首轮过滤仅保留携带目标服务UUID的设备，避免因为首轮广播包没带名称直接漏过目标设备。
• 单设备的扫描等待窗口不要低于2秒，给扫描响应包预留足够的空口传输时间。

基础配置代码示例：

var bleWatcher = new BluetoothLEAdvertisementWatcher();
// 开启主动扫描，请求扫描响应
bleWatcher.ScanningMode = BluetoothLEScanningMode.Active;
// 仅按目标服务UUID过滤，不提前加名称筛选
bleWatcher.AdvertisementFilter.Advertisement.ServiceUuids.Add(yourTargetServiceGuid);

2. 结合系统枚举接口补全缓存信息 #

DeviceInformation.CreateWatcher()是性价比很高的补充方案，不需要额外连接设备，功耗极低：

• 从广播监听器拿到设备的BluetoothAddress后，和系统枚举返回的设备地址做匹配，优先取系统缓存里存储的完整设备名称。
• 枚举时记得显式声明需要拉取的属性：System.Devices.Aep.DeviceAddress（用于地址匹配）、System.ItemNameDisplay（系统缓存的设备名）、System.Devices.Aep.Bluetooth.Le.IsConnectable（判断设备是否支持连接读名称），避免默认返回字段不全导致匹配失败。

3. 异常设备兜底方案 #

对前两步都拿不到完整名称的设备（比如测试中那台固件配置有问题的设备），用短暂GATT连接的方式兜底：

• 确认设备处于可连接状态后，用拿到的BluetoothAddress创建BluetoothLEDevice实例，建立GATT连接。
• 找到通用访问服务（GUID 00001800-0000-1000-8000-00805f9b34fb）下的设备名称特征（GUID 00002a00-0000-1000-8000-00805f9b34fb），直接读取特征值拿到完整名称。
• 读完名称立刻主动断开GATT连接，把名称和设备地址的映射关系存在本地应用缓存，下次扫描到同地址设备直接用缓存，不用重复连接。

推荐的标准发现流程 #

• 启动主动模式的BluetoothLEAdvertisementWatcher，仅按目标服务UUID过滤，记录所有命中设备的地址、广播携带的名称、RSSI值。
• 同步启动DeviceInformation.CreateWatcher，将广播拿到的设备地址和系统枚举结果做匹配，优先使用系统返回的完整名称。
• 对连续扫描超过3秒、前两个渠道都没拿到完整名称的可连接设备，触发短暂GATT连接读取名称特征，结果写入本地缓存。
• 不要把广播里的名称作为设备唯一标识，设备地址（隐私随机地址场景配合设备专属服务数据做校验）才是稳定的识别依据。

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