5

我们创建了一个 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 分钟，无论第二次连接上的数据更新频率如何。）

4

1 回答 1

2

以下是一些建议：

  • 尝试使用QOS_CLASS_USER_INITIATED或更高版本而不是QOS_CLASS_UTILITY.
  • 确保-[CBCentralManager stopScan]在不需要扫描外围设备以及-[CBPeripheralManager stopAdvertising]不需要为传入连接做好准备时（可能是在连接时）进行呼叫。
  • 来电-[CBPeripheralManager setDesiredConnectionLatency:forCentral:]预留更多资源。

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

于 2018-08-29T14:53:46.863 回答