此问题已在十月进行了讨论回到这里 。 这是一个新的问题，如CoreBluetooth是相当新的，从那时起一些变化可能发生。
我有一个BLE装置每2秒广告。 扫描采用启动：
[self.CM scanForPeripheralsWithServices:nil options:0]
返回最常（通过centralManager didDiscoverPeripheral回调）2秒左右到4秒钟以后。 （CM是我CentralManger）
然而，时间约30％，扫描需要10到18秒。 WiFi和BT在附近的设备已被禁用清除频谱尽可能。 扫描的时间似乎无关的RSSI。 这是-40dB时，旁边的iPad3，-70dB走5米左右时，在另一个房间。
[self.CM stopScan];
因为它降低了很长的等待发生的scanWithPeripherals之前被调用。
没有连接正在取得进展。 被请求无特性或服务的数据。 广告数据就足够了。
有一个有用的TI 演示应用 。 这给了相似的结果（实际上稍微差一些，因为它没有任何stopScan电话）
如被看见在这个CBCentralManagerScanOptionAllowDuplicatesKey选项＃1回答如果有的话似乎延长发现倍。
显然，下一步是使用一些更先进的BT嗅探器/广告生成工具，以进一步表征这一CoreBluetooth响应。
这是另一种有用的SO问题 ，但对响应时间不细说不够。
该CoreBluetooth不是连续听。 它与经典蓝牙和Wifi共享HW资源。
基本上，你必须是“幸运”来接收广告包。 “幸运”为，所述非同步2个系统的2个滑动窗口必须相互撞击。 如果CoreBluetooth打开它的BLE窗口时间的10％，并已设置没有关于确切时间的知识通告间隔那么它将/可以采取10倍的通告时间间隔。
一个建议是广告>快<前30秒（20ms的说，你应该发现它在第一有源CoreBluetooth窗口），然后减速到苹果指定的时间间隔。 2.00秒是不是一个好数字。
这里见准则： https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
第18页
发布时间间隔蓝牙配件的发布时间间隔应仔细考虑，因为它影响的时间来发现和连接性能。 对于电池供电的配件，其电池资源也应予以考虑。 由苹果产品被发现，蓝牙配件应该先用20毫秒推荐的发布时间间隔至少30秒。 如果没有最初的30秒内发现，该配件可以选择以节约电池电量，并提高其广告间隔。 苹果公司建议使用以下较长的时间间隔由苹果产品增加的发现的机会之一：
645毫秒768毫秒961毫秒1065毫秒1294毫秒
因此，尝试1294毫秒，如果你必须节省电池。
虽然这是一个古老的线程，我看到我的MacBook Pro（15英寸，2017）在MacOS上海伊谢拉10.13.3同样的问题。 这个问题通过的外围设备的“苹果电视”往往总是很快显现出来，也许是因为它有一个很短的广告时间而变化。 一些外设需要很长的时间来显示或似乎不显示在所有。 此外，如果广告是太慢，则也可以连接自连接通过首先找到的广告，并在非常短的时间固定响应它之后（外设在该时间期间收听）发生缓慢。
我发现这个问题，就是关闭两台无线网络连接和切换的解决方法。 系统偏好设置 - - 一般并取消选中“此Mac和iCloud的设备之间允许切换”一个通过进入苹果关闭切换。 这不仅使扫描更快速地显示广告数据包和连接速度更快，这也说明接收代表更强的信号强度较高（少负）RSSI。
请注意，这个问题不会在iOS中出现，可能是由于更好的BT和Wi-Fi共存支持和切换（空投），并定期BLE使用之间。 这个问题似乎只能是BLE收听时间比重的一次扫描过程中，并连接。 一旦连接建立，似乎没有要尽可能多的干扰。 在某种程度上，这是由于这样的事实，即一个连接后有自动低电平BLE重试和频率连接间隔之间跳频。 在扫描和建立连接（这两者都依赖于广告看到包）一个应该按顺序监控3个BLE广播频道，但MacOS的行为就好像它没有这样做。 从技术上讲，广告信道不与Wi-Fi信道（见重叠http://www.argenox.com/a-ble-advertising-primer/ ）。
