Apple在iOS上用于后台GATT服务广告的专有技术如何工作？
根据Apple的文档，当使用CoreBluetooth来实现BLE外围设备的iOS应用在后台运行时，不再发布服务UUID，而是将其放置在特殊的“溢出区域”：
CBAdvertisementDataServiceUUIDsKey密钥值中包含的任何服务UUID都不适合分配的空间，请转到特殊的“溢出”区域。只有显式扫描它们的iOS设备才能发现这些服务。当您的应用程序在后台运行时，不会公布本地名称，并且所有服务UUID都位于溢出区域。 -developer.apple.com
但是这个“溢出区域”是什么？如何运作？
I set up a bluetooth sniffer and captured the BLE data exchange，但找不到此服务UUID的任何通信。前台的第二个iOS设备可以反复成功地在后台的iOS设备上发现服务广告，但是the packet capture从未登录过服务UUID。
那么这如何工作？
如果我能弄清楚它是如何工作的，我想尝试对Android设备进行编程以使用相同的过程。
[溢出区是当至少一个iOS应用从后台发布CoreBluetooth服务时，从iOS设备发出的制造商广告。看起来像这样：
ff 4c 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
ff表示制造商广告，4c 00字节对应于蓝牙SIG为Apple分配的制造商代码0x004C。 01将其标识为溢出区域广告。最后16个字节（128位）是广告服务的哈希位掩码。
您发布的每个服务UUID都会将这128位中的一个准确地设置为1。在服务UUID和它在此位掩码中设置的位位置之间存在一对一的映射。这在iOS设备上是一致的。一些专有的Apple哈希算法将服务UUID转换为位掩码中的位位置。
由于存在大量可能的128位UUID – 2 ^ 128（大约10 ^ 38）–多个服务UUID共享同一位位置。
由于许多服务UUID共享溢出区位掩码中的每个位位置，因此不可避免发生冲突。 iOS将为扫描回调提供冲突但不同的服务UUID。这不会经常发生。但是，程序员应该意识到，他们可能只扫描服务以获取回调，以检测出后台的iOS设备，该设备在广告完全不同的服务，而该服务恰好在溢出区域的位掩码中发生冲突。
有趣的是，溢出区域可以进行操作，以使两个后台的iOS应用程序能够在后台交换数据。 See my blog post for more info.