您好，我有一个 swift 应用程序，可以通过信标与 BLE 设备进行通信。
当我杀死应用程序时，信标会在后台唤醒应用程序并连接到设备并开始通信。
在我杀死应用程序后，检测/连接的时间间隔主要在 30 秒到 1 分钟之间。但有时需要 3 4 分钟。
有没有人遇到过这样的问题，并且知道可能会发生什么，这是相同的过程，为什么它会不时发生变化，它与设备本身有关系吗？
谢谢
【问题讨论】：
标签： swift background ibeacon
由于 iOS 是封闭源代码，因此无法确定为什么会发生信标检测延迟。在个别情况下尤其如此——有很多变数。
但是，对于 iOS CoreLocation 如何基于逆向工程来检测信标，我们确实有一些想法，并且我对构建使用类似概念的 Android Beacon 库有一些见解。
这是我们所知道的：
CoreLocation 使用 BLE 硬件过滤器进行模式匹配，以尽快获得检测结果。如果硬件过滤器插槽可用，信标监控将使用蓝牙芯片本身来寻找模式优先匹配。当信标首次出现时，这将在不到一秒的时间内为您提供检测。
在某些情况下，无法使用硬件过滤器（它们已用尽）或已知信标在附近，因此将其忽略。在这些情况下，会使用定期备份扫描来查找信标。
备份扫描以不同的速率发生，具体取决于手机的状态和手机上运行的应用程序的信标/蓝牙扫描状态。如果没有应用程序正在主动扫描并且屏幕关闭，则可能每隔几分钟。
当屏幕打开时，通常会触发备份扫描。
如果您的应用在前台可见并使用测距 API 或使用 CoreBluetooth 主动执行 BLE 扫描，则它以 100% 的占空比进行扫描。
在其他情况下，占空比会更低。如果您使用不经常发布广告的信标进行测试（例如，低于 iBeacon 规范中的 10Hz），它可能会在 10% 占空比扫描时错过检测。
根据您的描述需要考虑的几点：
您可能已经用尽了手机上的所有 BLE 硬件过滤器，而您的应用可能没有一个。不幸的是，这种优化是完全隐藏的，因此无法确定。您可以通过卸载您认为可能正在扫描蓝牙的任何应用程序，然后卸载并重新安装您的应用程序，然后重新启动手机来增加获得硬件插槽的机会。如果一切都失败了，请在测试手机上恢复出厂设置。
每当您重新启动手机时，完全启动所需的时间比看起来要长得多。定位服务是完全初始化的最后一件事。重新启动后始终等待 5 分钟，然后再进行任何时间敏感的测试。
iOS 需要一段时间才能通过信标检测到它是否处于区域外状态。如果应用程序在屏幕上可见，这通常是 30 秒，但如果不是，则由于备份扫描的时间问题，这可能需要更长的时间。如果 iOS 没有意识到您已经退出，您将无法获得新的区域进入事件。
如果您在信标可见（或最近可见）时终止应用，iOS 可能不知道区域内/区域外状态。如果它认为它不在区域内，则可能需要很长时间才能确定它不在区域内。
【讨论】：