ios - iOS 服务广告如何在后台工作？

Question

Apple 在 iOS 上用于后台 GATT 服务广告的专有技术如何工作？

根据 Apple 的文档，当使用 CoreBluetooth 实现 BLE 外设的 iOS 应用程序在后台运行时，服务 UUID 不再广告，而是放在一个特殊的“溢出区域”:

Any service UUIDs contained in the value of the CBAdvertisementDataServiceUUIDsKey key that don’t fit in the allotted space go to a special “overflow” area. These services are discoverable only by an iOS device explicitly scanning for them. While your app is in the background, the local name isn’t advertised and all service UUIDs are in the overflow area. -- developer.apple.com

但是这个“溢出区域”是什么？它是如何工作的？

I set up a bluetooth sniffer and captured the BLE data exchange ，但未能找到此服务 UUID 的任何通信。前台的第二台 iOS 设备反复成功地发现后台 iOS 设备上的服务广告，但是 the packet capture从未记录过服务 UUID。

那么这是如何工作的呢？

如果我能弄清楚它是如何工作的，我想尝试对 Android 设备进行编程以使用相同的过程。

Answer 1

溢出区域是当至少一个 iOS 应用程序从后台宣传 CoreBluetooth 服务时从 iOS 设备发出的制造商广告。它看起来像这样:
ff 4c 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80ff表示制造商广告，4c 00字节对应于蓝牙 SIG 分配的 Apple 制造商代码 0x004C。 01将此标识为溢出区域广告。最后 16 个字节(128 位)是广告服务的散列位掩码。

您宣传的每个服务 UUID 都会导致这 128 位中的一个被设置为 1。服务 UUID 和它在此位掩码中设置的位位置之间存在一对一的映射。这在 iOS 设备上是一致的。将服务 UUID 转换为位掩码中的位位置是一些专有的 Apple 散列算法。

因为有大量可能的 128 位 UUID——2^128(大约 10^38)——多个服务 UUID 共享相同的位位置。

由于许多服务 UUID 共享溢出区域位掩码中的每个位位置，因此冲突是不可避免的。 iOS 将给一个扫描回调一个冲突但不同的服务 UUID。这不会经常发生。但程序员应该意识到，他们可能扫描他们的服务只是为了获得一个回调，以检测一个后台 iOS 设备广告一个完全不同的服务，该服务恰好在溢出区域的位掩码中发生冲突。

有趣的是，可以操纵溢出区域以使两个后台 iOS 应用程序在后台交换数据。 See my blog post for more info.