我有一个需要信标范围的项目，我看了很多示例代码，它们都使用CLLocationManager和CLBeaconRegion。我的问题是didRangeBeacons回调仅每秒被调用一次。
尽管我还没有找到任何特定于信标的代码示例，但我是否认为CoreBluetooth可以让我对我的应用扫描信标的频率有更多控制，这是正确的吗？
我的想法是，如果我可以以更高的速率(例如200毫秒)扫描信标，则可以在过滤功能中使用更多的rssi值，从而获得更准确的接近度，而无需花费太长时间。我认为正确吗？
谁能指出我有关将CoreBluetooth与信标一起使用的任何示例代码/教程(如果值得付出额外的努力)？
最佳答案
如果使用CoreBluetooth而不是CoreLocation来扫描信标，则对于检测到的每个广告包，将获得一个回调，而对于CoreLocation，则每秒获得一个回调。 两种方法都有优点和缺点，因此准确了解每种方法如何做出正确的选择非常重要。信标的广告费率极大地影响了优缺点，标准iBeacon广告费率为10 Hz。
使用范围为的CoreLocation
以下方法每秒将获取一次回调，但仅适用于与iBeacon布局匹配且与该布局中的ProximityUUID匹配且已注册为CLBeaconRegion对象一部分的BLE广告。满足这些条件时，无论在该时间间隔内检测到多少个信标包，每秒都会调用以下回调:locationManager(_ manager: CLLocationManager, didRangeBeacons beacons: [CLBeacon], in region: CLBeaconRegion)。CLBeacon数组中的每个beacons对象都有一个rssi字段。该字段包含过去一秒间隔内检测到的所有信标数据包的平均值rssi。
如果信标以10 Hz的频率进行广告发布，则该rssi读数将为过去一秒内接收到的8-10个数据包的平均值(由于 radio 噪声，冲突和干扰，通常仅接收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 Hz的频率进行广告转换，则此方法每秒将收到8-10个回调(同样，不会接收到100％的数据包)，您可以根据自己的喜好平均或过滤rssi。这使您可以对使用rssi进行细粒度的控制，并且可以在任意平均间隔内进行距离估计。
上述动机促使我开发了开源iOS Beacon Tools，它允许使用CoreBluetooth检测培根，并基于在任意指定的平均间隔内收集的rssi计算距离估计值。
但是，使用CoreBluetooth有几个缺点:
关于ios - 信标的CoreBluetooth，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/41737833/