Bleak库中BleakScanner回调函数失效问题解析

问题现象

在使用Python蓝牙BLE库Bleak时，开发者发现当使用BleakScanner类进行设备扫描时，设置的detection_callback回调函数没有被触发。示例代码中虽然扫描到了21个蓝牙设备，但回调函数中的打印语句始终没有执行。

技术背景

Bleak是一个跨平台的Python蓝牙低能耗(BLE)客户端库，BleakScanner是其提供的设备扫描工具。正常情况下，该扫描器支持两种工作模式：

1. 主动轮询模式：通过discover()方法一次性获取所有设备
2. 事件驱动模式：通过回调函数实时接收设备发现通知

问题根源

经过分析，这个问题源于对BleakScanner工作模式的误解。在示例代码中，开发者同时混用了两种工作模式：

devices = await BleakScanner(detection_callback=...).discover()

这里的关键点在于：

1. discover()是一个类方法，它会创建新的扫描实例，而不是使用当前构造的实例
2. 当调用discover()时，实际上创建了一个独立的扫描过程，忽略了之前设置的callback参数

正确用法

要实现回调功能，应该使用上下文管理器模式：

async with BleakScanner(detection_callback=lambda device, _: print(device)) as scanner:
    await asyncio.sleep(10)  # 持续扫描10秒

或者显式地控制扫描生命周期：

scanner = BleakScanner(detection_callback=...)
await scanner.start()
await asyncio.sleep(10)
await scanner.stop()

设计原理

BleakScanner的这种设计体现了：

1. 类方法与实例方法的职责分离
2. discover()作为快捷方法，适用于简单场景
3. 完整实例化方式，适用于需要细粒度控制的场景

最佳实践建议

1. 简单场景：直接使用discover()类方法
2. 需要回调或持续扫描：使用实例化方式
3. 注意异步上下文管理器的使用
4. 扫描时间需要合理设置，避免资源浪费

总结

理解BleakScanner两种工作模式的差异对于正确使用该库至关重要。在需要实时处理设备发现的场景下，应当避免使用discover()快捷方法，而应采用实例化扫描器的方式，这样才能确保回调函数被正确触发。这种设计模式在Python的异步IO库中相当常见，体现了关注点分离的设计原则。