如果使用CoreBluetooth来扫描信标而不是CoreLocation，那么检测到的每个广告包都会得到一个回调，而CoreLocation则会收到每秒一个回调。 有两种方法的优点和缺点，因此必须准确了解每种方法是如何工作的，从而做出正确的选择。其优缺点受信标广告率的影响很大，标准的iBeacon广告率为10 Hz。

使用CoreLocation测距

下面的方法将获得每秒一次回调，但只对匹配iBeacon布局的BLE广告和已注册为 CLBeaconRegion 对象一部分的布局中的ProximityUUID进行匹配。当满足这些条件时，无论在该时间间隔内检测到多少信标数据包，每秒钟都会调用以下回调：

locationManager(_ manager: CLLocationManager, didRangeBeacons beacons: [CLBeacon], in region: CLBeaconRegion) 。

CLBeacon 数组中的每个 beacons 对象都有一个 rssi 字段。该字段包含在过去一秒间隔内检测到的所有信标数据包的平均rssi。

如果信标以10赫兹作广告，这个rssi读数将是过去一秒钟接收到的8-10个数据包的平均值(由于无线电噪声、碰撞和干扰，通常只有80%-90%的数据包被接收)。

如果信标的广告频率在1Hz或更低(典型的电池信标，试图节省电力)，那么平均只会包含一个rssi读数。(无法知道回调返回的rssi值中有多少检测到了。)

因此，虽然您无法从每个检测中访问rssi值，并且无法控制平均间隔，但您确实可以从多个检测中获得好处，即rssi值是平均的，并且比只有一个读数时的噪声要小。因此， CoreLocation为您提供了与CoreBluetooth相同的准确性，只要您愿意接受它的硬编码平均间隔。

CLBeacon 对象还有用于 accuracy 和 proximity 的字段，这些字段基于在较长时间间隔内过滤的rssi的派生值(实验表明约为20秒)。API中没有对这个平均间隔的控制，对于一些您希望在距离估计中快速更新的应用程序来说，20秒是一个很长的延迟。

基于的CoreBluetooth扫描

这通常是通过设置允许重复结果的标志来完成的：

centralManager.scanForPeripherals(withServices: [], options: [CBCentralManagerScanOptionAllowDuplicatesKey: true] )

当启动上述扫描时，对检测到的每一个蓝牙广告都进行以下回调：

centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber)

此回调中的rssi编号是来自单个数据包检测的原始值。如果你的信标是在10赫兹的广告，你将得到8-10回调每秒在这个方法(同样，不是100%的数据包被接收)，你可以平均或过滤你的rssi，无论你喜欢。这为您提供了对使用rssi的细粒度控制，并且可以在任意平均间隔上进行距离估计。

基于上述动机，我开发了开源 iOS信标工具 ，它允许使用 CoreBluetooth 检测杆菌，并根据任意指定的平均间隔收集的rssi计算距离估计。

然而，使用 CoreBluetooth 有几个缺点

• iBeacon数据包无法解码，因为操作系统过滤掉与其布局匹配的任何数据包的数据有效负载。因此，您必须使用类似于AltBeacon的布局，或者使用Eddystone框架。
• 像AltBeacon这样的制造商广告不是在后台，而是在前台。
• 像Eddystone这样的服务广告是在后台发布的，但速度非常非常慢。因此，它对rssi数据收集并不有用。