我正在为 Linux 开发一个 BLE 智能手表配套应用程序，它需要在选定的设备处于范围内时自动重新连接到该设备。我的幼稚实现只是在连接丢失时启动设备发现。它运作良好，但当手表不在身边时，它只会永远在后台扫描。我认为这是浪费，但我不知道为什么。蓝牙适配器的功耗会明显增加吗？还有其他影响吗？
定期发现是否更好？有什么我应该注意的常见陷阱吗？频繁启动和停止设备发现是否会产生额外成本（除了 D-Bus 消息的成本）？
我希望保持较低的检测延迟，因此我考虑使用 10-20 秒的发现间隔和 2-3 秒的发现持续时间（在大多数情况下，这在我的测试中似乎足够了），为了确定起见，也许每几分钟就会进行一次更长的发现。这个想法有什么明显的问题吗？
正如您所说，有多种方法可以实现这一目标，这完全取决于您的功率、处理和延迟要求。如果您的 Linux 设备不是电池供电的，那么按照 Emil 的建议进行连续扫描或连续传出连接并没有什么大害处。换句话说，一旦您收到智能手表断开连接的事件，您的应用程序就应该处于“连续”状态，尝试重新连接到智能手表。就延迟而言，这将是最佳选择，但对于功耗或后台处理而言并不理想。
如果您的设备是电池供电的，那么最好的选择是定期扫描/连接尝试。因此，当您的智能手表断开连接时，您的 Linux 设备将立即扫描/重新连接 30 秒左右，但然后进入睡眠状态 30 秒，然后重新尝试连接。这样，当您尝试重新连接到智能手表时，您的设备仅在 50% 的时间内处于活动状态。
最后，您可以根据您的处理要求调整睡眠/扫描持续时间。我个人认为对于大多数 Linux 设备来说不会有任何大的处理影响，因为它们是多线程的并且支持许多 GB 的 RAM，但是在重新连接后保持清醒并让设备休眠一段时间并没有什么坏处。尝试。