通过 iBeacon Monitoring & Ranging vs CoreBluetooth scanForPeripheralsWithServices 检测信标

Question

对于 iOS 对想要扫描 BLE 信标\外围设备的应用程序施加的限制存在很多混淆。 在阅读了几个博客和 Stack Overflow 的答案后，我想看看我是否正确理解了所有问题。如果有什么我误解或遗漏的地方，请纠正我。我只指 iOS 7 及更高版本，专注于检测而不是连接（您可以使用 iBeacon Monitoring & Ranging API 连接到 CLBeacon 吗？）。

信标的选项很明确 - 使用通用 BLE 外围设备或使用在 iBeacon format 中进行广告的 BLE 外围设备（此外，非标准外围设备可以在 adv-packet 中以 iBeacon 格式进行广告，并且扫描响应数据包中的不同格式）。

一般限制

• iBeacon Ranging 将让您知道您周围有哪些信标。您必须事先指定信标广告的 ProximityUUID（无“一般”扫描）。 didRangeBeacons 将每秒调用一次，其中包含最近发现的 CLBeacon 对象数组。与信标的距离及其准确性由 iOS 使用一些只有 Apple 开发人员真正知道的机密算法计算（该算法基于信标所宣传的 rssi 值和 rssi-at-1-meter 校准字节）。您还可以在每次进入或退出区域时使用 iBeacon Monitoring 调用委托 - 同样，您必须指定要查找的 ProximityUUID（您也可以指定主要和次要）。 “退出区域”是指一段时间内没有收到任何广告，因此不能立即退出。 每台设备可以同时监测\监测的区域数量限制为 20 - 这意味着如果其他应用同时监测\监测，您的应用可能无法监测\范围（对吗？）。
• CoreBluetooth - 您还可以检测信标广告中的其他广告结构。如果信标也以 iBeacon 格式进行广告，您将看不到 iBeacon 字段（ProximityUUID、major、minor...），尽管事实上它们是在您可以在其他情况下看到的标准“制造商特定”广告结构下发送的.

在前台运行 - 限制较少的用例：

• iBeacon 测距和监控 - 没有其他限制。
• CoreBluetooth - 在serviceUUIDs 的scanForPeripheralsWithServices 中传递nil 将扫描所有外围设备。在选项中将CBCentralManagerScanOptionAllowDuplicatesKey 传递为YES 将使didDiscoverPeripheral 为同一个外围设备\信标多次调用（我假设使用计时器您检测到一段时间未收到广告并假设用户退出“区域”）。

在后台运行 - 更受限制的用例：

• iBeacon Ranging 不能直接工作。 iBeacon Monitoring 将调用didEnterRegion 并为应用程序提供 6 秒的运行时间 - 您可以在其中启动 Ranging（例如，检测主要和次要）。由于 iOS 会打开和关闭扫描以节省电池电量，因此检测可能不会立即进行。如果您进入具有相同 ProximityUUID 的多个信标的区域，并且您在没有特定主要和/或次要的情况下监视此 UUID，则当您开始接收来自第一个信标的信号时，将调用 didEnterRegion - 但是，如果您没有退出第一个信标的区域，并且您还进入了第二个信标的区域，该应用程序将不会再次被唤醒（didEnterRegion 不会再次被调用），因此您无法开始测距以检测第二个信标的主要和次要。该应用不能简单地弹出到前台，而是可以创建本地通知和其他后台操作。
• CoreBluetooth - 根据Core Bluetooth Background Processing scanForPeripheralsWithServices 可以在后台运行使用，但必须至少指定一个serviceUUID。 didDiscoverPeripheral 的运行时间为 10 秒。使用 CBCentralManagerScanOptionAllowDuplicatesKey 将不起作用 - 每个外围设备都会调用一次 didDiscoverPeripheral。因此，您无法检测到从该区域“退出”和“重新进入”。我想您可以使用更改其 MAC 地址的非标准 BLE 外围设备来解决此问题。该应用程序不能简单地弹出到前台，而是可以创建本地通知和其他后台操作。由于 iOS 会打开和关闭扫描以节省电池电量，因此检测可能不会立即进行。

应用被杀死后运行

• iBeacon 监控 - 有效！即使用户关闭了应用程序或设备重新启动。
• CoreBluetooth - 如果应用程序被 iOS 杀死（由于不活动或内存限制），它将被唤醒。但是，如果用户明确地杀死了应用程序，它将不会被唤醒（这使得第一种情况难以测试）。我不知道设备重启后会发生什么...

有没有人对这些限制有更多经验？在某些用例中，scanForPeripheralsWithServices 可以用作 iBeacon 监控的更好替代方案吗？

谢谢！

Answer 1

您的描述基本正确。只需澄清两点：

• 20 个区域的限制不是每台设备，它是特定于应用程序的。无论其他应用在移动设备上做什么，iOS 仍然允许您的应用监控多达 20 个区域。也就是说，可能存在特定于设备的硬件限制，即在硬件辅助下可以在后台监控多少个区域。这些限制没有记录。如果您超出了这些未记录的限制，则在后台检测到信标可能需要更长的时间。 （尽管如此，操作系统无法保证检测到的时间。）

• 您无法使用 Monitoring 和 Ranging API 连接到 CLBeacon。这些 API 仅适用于无连接的 BLE 广告数据包。

是的，可以使用scanForPeripheralsWithServices 作为替代方案。这就是 Gimbal 信标为实现专有系统所做的事情。然而，在背景检测时间和可靠性方面存在真正的缺点。