CoreBluetooth 扫描检测时间在 MacOS 上不可靠答案

【问题标题】：CoreBluetooth scan detection times unreliable on MacOSCoreBluetooth 扫描检测时间在 MacOS 上不可靠
【发布时间】：2018-04-29 01:37:34
【问题描述】：

在 MacOS 上扫描 BluetoothLE 制造商广告时，发现回调的频率远低于 iOS。对于 10 Hz 的发射器广告，iOS 每秒会收到近 10 个发现回调。在 MacOS 上，通常每秒会看到 1-3 个回调，但有时回调之间可能会有很多秒——有几次我测量的检测间隔超过 90 秒！下面是我所做的图表，显示了在大约两个小时的测试运行中发现之间的秒数。

与 iOS 相比，为什么 MacOS 上的发现时间如此难以预测？有没有办法让回调更可靠？

我在 MacBook Pro（Retina，15 英寸，2014 年中）上的 macOS Sierra 10.12.6 上记录了这些数据，但我听到同事抱怨新款 MacBook 存在类似的不可靠性。

centralManager = CBCentralManager(delegate: self, 
                                  queue: DispatchQueue.global(qos: .default))
centralManager.scanForPeripherals(withServices: nil, 
                                  options: [CBCentralManagerScanOptionAllowDuplicatesKey: true])

...

func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) {
            let secsSinceDetection = Date().timeIntervalSince(self.lastDetectionTime)
            lastDetectionTime = Date()
            NSLog("LDT: \(secsSinceDetection))")
}

【问题讨论】：

标签： macos core-bluetooth

【解决方案1】：

我在 MacBook Pro（15 英寸，2017 年）上看到 macOS High Sierra 10.13.3 存在同样的问题。甚至 Apple 的蓝牙资源管理器应用程序（硬件 IO 工具的一部分）也出现了同样的问题。

某些外围设备受到的影响比其他外围设备更大。 Apple TV 似乎总是很快出现，而其他外围设备则较慢或根本不出现。

请参阅此处已回答相关问题： CoreBluetooth advertising detection time 显然，CoreBluetooth 没有连续收听，而是与 Wi-Fi 和常规蓝牙共享天线和资源。我原本以为同时关闭 Wi-Fi 和“Handoff”可以提高看广告的能力并缩短连接时间。 “Handoff”在 Apple - System Preferences - General 中通过取消选中“Allow Handoff between this Mac and your iCloud devices”关闭，但这可能不是真的。

请注意，该问题不会出现在 iOS 中，这可能是由于更好的 BT 和 Wi-Fi 共存支持以及切换（空投）和常规 BLE 使用之间的关系。该问题似乎只是扫描和连接期间 BLE 侦听时间的比例之一。建立连接后，似乎没有那么多干扰。部分原因是，在一个连接之后，在固定时间连接间隔之间会自动进行低级 BLE 重试和跳频。在扫描和建立连接期间（两者都依赖于查看广告数据包），每个 scanInterval 上依次循环通过 3 个 BLE 广告通道。从技术上讲，广告渠道与 Wi-Fi 不重叠（请参阅http://www.argenox.com/a-ble-advertising-primer/）。

[为新信息编辑] 经过更广泛的测试后，macOS 的问题似乎不是 Wi-Fi 或 Handoff 的干扰，而是 scanWindow 和 scanInterval 设置的行为更像 iOS 在后台的工作方式.由于对于某些外围设备，有时需要长达 1.5 分钟才能找到，因此 30/300 的比率与 1 秒的广告和最多 10 毫秒的随机移位（因此平均移位为 5 毫秒）可能需要 (300-30)/5 = 54 间隔（秒）如果外围设备未遵循 Apple 的广告间隔指南（故意远离 300 毫秒倍数并且运气不好），则检测到的时间间隔（秒）可能会稍长一些，这大致看起来是这样。不幸的是，我还没有找到一种方法来强制 macOS 使用类似于 iOS 前台的更高的 scanWindow/scanInterval 比率。

[SECOND EDIT ADDITIONAL INFO] 如果在外围设备中遵循 Apple 的 1022.5 毫秒广告时间，那么即使使用 iOS 背景或 macOS 30 毫秒 scanWindow 和 300 毫秒 scanInterval，中位时间约为 5 秒，而最大值约为19 秒因此可能会更长一些，因为 0-10 毫秒的随机移位非常糟糕。

【讨论】：

很好的见解。我没有看到其他问题，感谢您指出。
仅供参考：以下两个链接：lists.apple.com/archives/bluetooth-dev/2015/Feb/msg00000.html lists.apple.com/archives/bluetooth-dev/2014/Sep/msg00001.html 表示 iOS 的 scanWindow 为 30 毫秒，scanInterval 为 40 毫秒，而 scanInterval 在后台增加到 300 毫秒。这意味着即使在没有其他无线电干扰的前台，iOS 在每次尝试时也只会在 75% 的时间里看到广告（假设外围设备会随机移动 10 毫秒的广告）。
因此对于典型的 1 秒广告率，这是在 1 秒后 75%、2 秒后 94%、3 秒后 98% 的扫描（以及连接）中看到的概率秒，4 秒后 99.6%，等等 [1 - ((40-30)/40)^adverts]
对于同样的 1 秒广告示例，但在后台扫描窗口为 30 毫秒，扫描间隔为 300 毫秒，我们有可能将广告视为 [ 1 - ((300-30)/300)^广告 ] 1 秒后 10%，2 秒后 19%，3 秒后 27%，4 秒后 34%，5 秒后 41%，10 秒后 65%，20 秒后 88%，30 秒后 95.8%， 1 分钟后达到 99.8%。