cnb*_*com 6 bluetooth objective-c ios bluetooth-lowenergy
正如 iOS 文档所述,当使用 BLE 作为外设的 iOS 应用程序移动到后台模式时,不会公布本地名称,并且所有服务 UUID 都放置在溢出区域中。文档指出它们只能被 iOS 设备发现。
我的总体问题是,这到底是如何在较低级别发生的。使用非 iOS 蓝牙数据包嗅探器,当我的 iOS 外围应用程序处于前台和后台模式时,我检查了它的广告数据结构。前台模式下的广告数据结构看起来符合预期,类似于来自非 iOS 设备的其他广告数据,例如我来自 Android 设备的广告数据。
当 iOS 应用处于后台模式时,此结构发生变化,服务 UUID 不明显。我没有看到任何暗示“溢出”区域的东西。
如果 UUID 不是广告数据包的一部分,iOS 中心设备如何发现处于后台模式的外围设备?
根据Apple 文档,有一个所谓的溢出区。可以在此存档页面中找到有关Core Bluetooth 概念的更多信息。
我已经通过空气嗅探了这些数据包。您可以在github上阅读详细信息。iOS 所做的是广播带有表示 UUID 的特定位的自定义包。例如,UUID3333由 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 02 00 00 0 0 0 0 D
您会在此处看到02被零包围的某处(在D3在 8 位 RSSI 值之前)。
每个 UUID 都被单热编码到这个范围内的一个位。这将导致冲突。你会注意到,如果你1001用一部 iPhone发送并3333用另一部 iPhone扫描你会收到广告,就像 UUID3333发送。
注意,有很多关于这个的废话。这只是一个普通的无向 BLE 数据包。这不是扫描响应。在后台运行时,我可靠地每 0.2 秒收到一次 BLE 数据包。
时间在 x 轴上(超过几天)。消息之间的间隔绘制在 y 轴上。您会看到有时间隔是 0.2 秒的倍数。但是,您还会看到这在三部 iPhone 之间共享(一台广播1000、一台广播FFFF和一台3333在后台广播)。这意味着这是来自接收消息的笔记本电脑的工件。iPhone 可能比这更坚固。在整个周末,电池电量下降就像25%,这很可能与 BLE 广播以外的其他事情有关。
| 归档时间: |
|
| 查看次数: |
5121 次 |
| 最近记录: |