为什么 iOS 应用 iBeacon 唤醒间隔不同?

Why iOS app iBeacon wake up intervals varies?

您好,我有一个 swift 应用程序可以通过信标与 BLE 设备进行通信。

当我终止应用程序时,信标会在后台唤醒应用程序,它会连接到设备并开始通信。

在我终止应用程序后,检测/连接的时间间隔通常在 30 秒到最多 1 分钟之间。但有时需要 3 4 分钟。

有没有人遇到过这样的问题并且知道可能会发生它是同一个过程为什么它会不时变化是否与设备本身有关系?

感谢

由于 iOS 是封闭源代码,因此无法确定为什么会发生信标检测延迟。在个别情况下尤其如此——有很多变数。

但是,我们确实对 iOS CoreLocation 如何基于逆向工程检测信标有一些想法,并且我对基于构建使用类似概念的 Android 信标库有一些见解.

这是我们所知道的:

  • CoreLocation 使用 BLE 硬件过滤器进行模式匹配,以尽快进行检测。如果硬件过滤器插槽可用,信标监控将使用蓝牙芯片本身来寻找模式优先匹配。当信标首次出现时,这将使您在不到一秒的时间内进行检测。

  • 在某些情况下无法使用硬件过滤器(它们已耗尽)或已知信标在附近,因此将其忽略。在这些情况下,定期备份扫描用于查找信标。

  • 备份扫描以不同的速率发生,这取决于 phone 的状态和 phone 上应用 运行 的 beacon/bluetooth 扫描状态].如果没有应用程序在主动扫描并且屏幕关闭,则可以每隔几分钟扫描一次。

  • 屏幕打开时,通常会触发备份扫描。

  • 如果您的应用程序在前台可见并且使用测距 API 或主动使用 CoreBluetooth 进行 BLE 扫描,则它正在以 100% 的占空比进行扫描。

  • 在其他情况下,占空比会更低。如果您正在测试不经常发布广告的信标(例如低于 iBeacon 规范中的 10Hz),它可能会在 10% 占空比扫描时错过检测。

根据您的描述,有几点需要考虑:

  1. 您可能已经用尽了 phone 上的所有 BLE 硬件过滤器,而您的应用可能没有。不幸的是,这种优化是完全隐藏的,因此无法确定。您可以卸载您认为可能正在扫描蓝牙的任何应用程序,然后卸载并重新安装您的应用程序,然后重新启动 phone,从而增加获得硬件插槽的机会。如果一切都失败了,请在测试中恢复出厂设置 phone。

  2. 每当您重新启动 phone 时,完全启动所需的时间比看起来要长得多。位置服务是最后要完全初始化的东西之一。始终在重启后等待 5 分钟,然后再进行任何时间敏感的测试。

  3. iOS需要时间来检测它是否处于带信标的区域外状态。如果应用程序在屏幕上可见,这通常是 30 秒,但如果不是,则可能需要更长的时间,因为备份扫描的时间。如果 iOS 没有意识到你已经退出,你将无法获得新的区域进入事件。

  4. 如果您在信标可见时(或最近可见时)关闭您的应用,iOS 可能不知道区域内/区域外状态。如果它认为它不在区域中,它可能需要很长时间才能弄清楚它不在区域中。