如何在CBPeripheralManager处于活动状态时提高CBCentralManager的性能

Question

我们创建了一个iOS应用程序,它实现了一个CBCentralManager来连接我们创建的设备,以10Hz的频率传输数据.这些数据通过并快速显示非常重要,因此我们围绕此建立了严格的延迟检查,如果错过了太多的点,或者如果本地时钟检测到传入值减慢,我们将会出错并断开连接.

客户端已经要求我们顶级实现第二个iOS应用程序,它将观察第一个.我们在原始应用程序中实现了一个CBPeripheralManager,它可以广告,可以连接,并定期将其数据发布到一些传出特性.

我们发现我们似乎无法将观察者iOS应用程序连接到原始iOS应用程序(即,原始iOS应用程序同时具有与设备的CBCentral连接和同时活动的观察者应用程序的CBPeripheral连接),绊倒我们对来自设备的传入数据的延迟检查.

我已经尝试了我能想到的一切,我为CBPeripheralManager和CBCentralManager使用了单独的队列,如下所示:

    q = dispatch_get_global_queue(QOS_CLASS_UTILITY, 0);
    ptr_CBPeriphMgr = [[CBPeripheralManager alloc] initWithDelegate:self queue:q];

也,

• 我记录并记录了所有内容,验证我的代码没有花太长时间
• 我将几乎所有的代码都移出了BLE处理程序,使它们非常轻巧而不会阻塞,
• 我尝试了低优先级的单独队列(上面显示的例子)
• 我已经尝试将我的CBPeripheralManager数据速率降低到涓流,一秒钟更新几次
• 我已经尝试在建立CBPeripheralManager连接后暂停延迟检查三秒钟(这非常不理想),但问题似乎是随机发生的,而不仅仅是在连接之后.

似乎无论我尝试什么,在外围设备和中央连接都处于活动状态4-5分钟后(我们有一个循环,其中第二个应用程序每隔五秒重复连接并断开连接,以挑战设备连接)我的传入值更新自中央设备减速到大约1/4或1/5速度,或者它们停止一整秒,然后几乎同时进行三到四次更新 - 这两次更新都会延迟我们的延迟检查.这就像是一些队列被填满并且表现平坦,但正如我上面提到的,我认为我正在使用单独的队列.

我在我的智慧结束...有没有人想过如何在iOS应用程序中优先考虑我的中心功能而不是我的外围功能,或以某种方式提高性能以防止这成为一个问题并保持我的应用程序响应10Hz来自设备的更新,即使被视为外围设备？

(编辑说我们正在重复连接/断开第二个应用程序...也许我在正确断开连接后没有清理,垃圾堆积并搞砸了BLE？这可以解释为什么问题似乎发生在4之后无论第二次连接的数据更新频率如何,均为-5分钟.)

Answer 1

以下是一些建议：

• 尝试使用QOS_CLASS_USER_INITIATED或更高版本而不是创建队列QOS_CLASS_UTILITY。
• 确保-[CBCentralManager stopScan]在不需要扫描外围设备以及-[CBPeripheralManager stopAdvertising]不需要为传入连接做好准备时（可能是在已连接时）拨打电话。
• 来电-[CBPeripheralManager setDesiredConnectionLatency:forCentral:]预约更多资源。

但是，如果您可以针对 iOS 11+，我建议使用 L2CAP 通道来减少延迟并提高速度。虽然 CoreBluetooth 的 L2CAP 支持没有很好的记录，但这里是可用 API 的列表。