BlueZ DBus API扫描BLE设备时不定期无响应该如何解决

你存在4项核心遗漏操作，按优先级依次修复即可解决问题： #

1. 未配置扫描过滤器，导致DBus消息队列被打满

BlueZ 5.53版本默认会上报所有BLE广播包的重复数据，每秒可产生数百条DBus信号，极易压垮DBus消息队列，导致bluetoothd死锁，这是你退出应用后蓝牙工具仍无响应的核心原因。
必须在调用StartDiscovery前先设置扫描过滤，参考代码：

GVariantBuilder *filter_builder = g_variant_builder_new(G_VARIANT_TYPE("a{sv}"));
// 关闭重复数据上报，仅上报设备首次发现/广播数据变化的事件
g_variant_builder_add(filter_builder, "{sv}", "DuplicateData", g_variant_new_boolean(FALSE));
// 可选：限制只扫描BLE设备，过滤经典蓝牙
g_variant_builder_add(filter_builder, "{sv}", "Transport", g_variant_new_string("le"));

GError *error = NULL;
g_dbus_connection_call_sync(
    mConnection,
    "org.bluez",
    "/org/bluez/hci0", // 替换为你的适配器路径
    "org.bluez.Adapter1",
    "SetDiscoveryFilter",
    g_variant_new("(a{sv})", filter_builder),
    NULL,
    G_DBUS_CALL_FLAGS_NONE,
    -1,
    NULL,
    &error
);
g_variant_builder_unref(filter_builder);

2. 未监听扫描状态变化，未定时重发扫描请求

BlueZ默认扫描会在180秒后自动停止，你没有监听适配器的Discovering属性变化，扫描停止后没有重新触发StartDiscovery，就会出现运行一段时间后无设备上报的假象。
需要订阅org.freedesktop.DBus.Properties的PropertiesChanged信号，监听适配器的Discovering属性，当属性变为false时主动重新调用StartDiscovery。

3. 未监听DBus连接异常，无错误恢复逻辑

你当前只订阅了设备增减的信号，未监听GDBusConnection的closed信号，当DBus连接因为消息积压、超时断开后，没有重连和资源重置逻辑，会直接导致扫描完全停止。
需要绑定g_dbus_connection_signal_subscribe监听连接关闭事件，触发后主动停止扫描、释放旧连接、重新获取DBus总线、重新初始化扫描流程。

4. 无正常退出的资源清理逻辑

应用退出时如果没有主动释放BlueZ资源，会导致bluetoothd内部状态异常、资源泄漏，严重时必须断电重启才能恢复。
退出前必须按顺序执行以下操作：

// 1. 停止扫描
g_dbus_connection_call_sync(mConnection, "org.bluez", "/org/bluez/hci0", "org.bluez.Adapter1", "StopDiscovery", NULL, NULL, G_DBUS_CALL_FLAGS_NONE, -1, NULL, &error);
// 2. 取消已订阅的DBus信号
g_dbus_connection_signal_unsubscribe(mConnection, iface_add_sub);
g_dbus_connection_signal_unsubscribe(mConnection, iface_remove_sub);
// 3. 释放事件循环和DBus连接
g_main_loop_quit(mLoop);
g_main_loop_unref(mLoop);
g_object_unref(mConnection);

附加优化建议 #

BlueZ 5.53存在多个已知的BLE扫描资源泄漏、状态机异常的bug，条件允许的话升级到5.60及以上版本，可大幅降低底层故障概率。

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