正如iOS文档所述,当使用BLE作为外围设备的iOS应用程序移至后台模式时,不会公布本地名称,并且所有服务UUID都将放置在溢出区域中。该文档指出它们只能由iOS设备发现。
我的整体质疑是如何在较低级别上发生这种情况。使用非iOS蓝牙数据包嗅探器,当我处于前台和后台模式时,我检查了我的iOS外围应用程序中的广告数据结构。前台模式中的广告数据结构看起来是预期的,类似于来自非iOS设备的其他广告数据,例如我来自Android设备的广告数据。
当iOS应用程序为后台模式时,此结构会更改,并且服务UUID不明显。我没有看到任何暗示“溢出”的区域。
如果UUID不是广告数据包的一部分,iOS中央设备如何发现处于后台模式的外围设备?
答案 0 :(得分:-1)
根据Apple documentation,存在所谓的溢出区。可以在此存档页面中找到有关Core Bluetooth concepts的更多信息。
我在空中嗅着这些小包。您可以在github上阅读详细信息。 iOS所做的是广播自定义包,其中包含代表UUID的特定位。例如,UUID 3333
由BLE包中的一点位表示。
04 3E 24 02 01 00 01 8C 91 A0 AD 8F 40 18 02 01 1A 14 FF 4C 00 01 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 D3
您在这里02
处被零包围(在D3
8位RSSI值之前)。
每个UUID都被热编码到该范围内的一位。这将导致碰撞。您会注意到,如果您通过一部iPhone发送1001
,而通过另一部iPhone扫描3333
,您将收到广告,就像发送了UUID 3333
一样。
注意,关于此的很多废话。这只是一个常规的无向BLE数据包。这不是扫描响应。当在后台运行时,我已经可靠地每0.2秒获取BLE数据包。
时间在x轴上(几天)。
消息之间的间隔在y轴上绘制。您会看到时间间隔有时是0.2秒的倍数。但是,您还会看到,这在三部iPhone中共享(在后台一广播1000
,一广播FFFF
和一广播3333
)。这意味着这是来自笔记本电脑接收消息的人工产物。 iPhone可能比这更坚固。在整个周末,电池电量下降的情况类似于25%
,这很可能与BLE广播有关。