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

Question

我们已经创建了一个iOS应用程序，它实现了一个CBCentralManager来连接到我们创建的设备，该设备以10 at的频率传输数据。至关重要的是，这些数据能够快速通过并显示，因此我们已经建立了严格的延迟检查，如果漏掉了太多的点，或者本地时钟检测到传入值的速度减慢，我们就会出错并中断连接。

客户已经要求我们实现第二个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连接之后，我尝试将延迟检查挂起3秒(这是非常不理想的)，但问题似乎是随机出现的，而不仅仅是在连接之后。

无论我如何尝试，在4到5分钟的外围连接和中央连接都处于活动状态(我们有一个循环，第二应用程序每5秒重复连接和断开连接，以挑战设备连接)，我从设备到中心的传入值更新速度减慢到大约1/4或1/5的速度，或者它们停止了整整一秒钟，然后三到四次更新几乎同时出现--这两种更新都影响了我们的延迟检查。就像某些队列被填满，性能平行线，但正如我前面提到的，我认为我使用的是单独的队列。

我快疯了.有没有人想过如何将我的中心功能优先于iOS应用程序中的外围功能，或者以某种方式提高性能，以防止这成为一个问题，并使我的应用程序能够响应设备的10 as更新，即使是作为外围设备被观察到？

(编辑如下:我们正在反复连接/断开第二个应用程序.也许在断电后我没有清理干净，垃圾堆积如山，把BLE搞砸了？这就可以解释为什么问题出现在4-5分钟之后，而不管第二个连接中数据更新的频率如何。)

Answer 1

以下是一些建议：

• 尝试使用QOS_CLASS_USER_INITIATED或更高版本而不是QOS_CLASS_UTILITY创建队列。
• 确保在不需要扫描外围设备时调用-[CBCentralManager stopScan]，在不需要为传入连接做准备时调用-[CBPeripheralManager stopAdvertising] (可能是在连接的时候)。
• 调用-[CBPeripheralManager setDesiredConnectionLatency:forCentral:]以保留更多资源。

但是，如果您可以针对iOS 11+，我建议您使用L2CAP通道来减少延迟和提高速度。尽管Core蓝牙的L2CAP支持并没有得到很好的记录，但这里有一个可用API列表。