CoreBluetooth广告检测时间
这个问题已在10月份讨论过了。 这是一个新问题，因为CoreBluetooth相当新，从那以后可能会发生一些变化。
我每2秒就有一个BLE设备广告。 使用以下命令启动扫描：
[self.CM scanForPeripheralsWithServices:nil options:0] 最常返回（通过centralManager didDiscoverPeripheral回调）大约2s到4s之后。 （CM是我的CentralManger）
但是，大约30％的时间，扫描需要10到18秒。 已禁用附近设备中的WiFi和BT以尽可能清除频谱。 扫描时间似乎与RSSI无关。 在iPAd3旁边是-40dB，在另一个房间大约5米处是-70dB。
[self.CM stopScan];
在scanWithPeripherals之前调用，因为它减少了真正长时间等待的发生。
没有连接。 没有要求提供任何特征或服务数据。 广告数据就足够了。
有一个有用的TI 演示应用程序 。 这给出了类似的结果（实际上稍微差一点，因为它没有进行任何stopScan调用）
如果有任何事情似乎延长了发现时间，则可以在此Stackoverflow中看到CBCentralManagerScanOptionAllowDuplicatesKey选项。
显然，下一步是使用一些更高级的BT嗅探器/广告生成工具来进一步表征这个CoreBluetooth响应。
这是另一个有用的SO问题 ，但没有详细说明响应时间。
CoreBluetooth没有连续收听。 它与蓝牙经典和Wifi共享硬件资源。
基本上你必须“幸运”才能收到广告包。 “幸运”，因为2个非同步系统的2个滑动窗口必须相互碰撞。 如果CoreBluetooth在10％的时间打开它的BLE窗口并且您已经设置了广告间隔而不知道确切的时间，那么它将/可能需要10倍的广告间隔。
一个建议是在前30秒（例如20ms，你应该在第一个活动的CoreBluetooth窗口中发现它）播放> fast <，然后减慢到Apple指定的间隔。 2,00秒不是一个好数字。
请参阅此处的指南： https ： //developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
第18页
广告时间间隔应仔细考虑蓝牙配件的广告时间间隔，因为它会影响发现和连接性能的时间。 对于电池供电的配件，还应考虑其电池资源。 要被Apple产品发现，蓝牙配件应首先使用推荐的20 ms广告时间间隔至少30秒。 如果在最初的30秒内未发现，则附件可选择节省电池电量并增加其广告间隔。 Apple建议使用以下较长间隔之一来增加Apple产品的发现机会：
645 ms 768 ms 961 ms 1065 ms 1294 ms
因此，如果必须节省电池，请尝试1294 ms。
虽然这是一个老线程，但我在MacBook Pro（15英寸，2017年）的MacOS High Sierra 10.13.3中看到了同样的问题。 问题因外围设备而异，“Apple TV”往往很快出现，可能是因为它的广告时间很短。 有些外围设备需要很长时间才能显示或者根本不显示。 此外，如果广告太慢，那么连接也可能很慢，因为通过首先找到广告并在之后非常短的固定时间响应它（外围设备正在该时间内收听）来进行连接。
我找到了解决此问题的方法，即关闭Wi-Fi和Handoff。 通过进入Apple – 系统首选项 – 常规并取消选中“允许在此Mac和iCloud设备之间切换”来关闭Handoff。 这不仅使扫描更快地显示广告包并且连接更快，而且还显示更高（更少负）RSSI，表示接收更强的信号强度。
请注意，问题并未出现在iOS中，可能是由于更好的BT和Wi-Fi共存支持以及Handoff（Airdrop）和常规BLE使用之间的关系。 该问题似乎只是扫描和连接期间BLE监听时间的一部分。 建立连接后，似乎没有那么多干扰。 在某种程度上，这是因为在一次连接之后，存在自动低级别BLE重试和连接间隔之间的跳频。 在扫描和建立连接（两者都依赖于看到广告包）期间，应该依次监视3个BLE广告信道，但是macOS表现得好像它没有这样做。 从技术上讲，广告渠道与Wi-Fi渠道不重叠（请参阅http://www.argenox.com/a-ble-advertising-primer/ ）。