Ios 核心蓝牙在发送数据包时会变慢

我遇到一个问题，即使用

[peripheral writeValue:dataPacket forCharacteristic:writeChar type:CBCharacteristicWithResponse]

而iOS设备实际发送蓝牙数据包的时间越来越长

调试器的以下输出说明了这一点：

2013-10-23 14:12:17.510 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:17.595 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:17.598 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:17.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:17.656 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:17.657 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:22.601 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:23.123 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:23.125 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:27.601 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:28.111 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:28.113 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:32.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:34.595 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:34.597 Test App iOS[1561:60b] Packet response received


2013-10-23 14:12:37.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:39.582 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:39.585 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:42.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:44.570 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:44.573 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:47.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:49.558 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:49.560 Test App iOS[1561:60b] Packet response received

// Several packets omitted...

2013-10-23 14:13:07.610 Test App iOS[1561:60b] Packet sent
2013-10-23 14:13:09.508 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:13:09.511 Test App iOS[1561:60b] Packet response received

2013-10-23 14:13:12.610 Test App iOS[1561:60b] Packet sent
2013-10-23 14:13:14.496 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:13:14.498 Test App iOS[1561:60b] Packet response received

//等等

数据包发送消息在writeValue命令后立即输出，以将数据包写入特征

发送确认的数据包在didWriteValueForCharacteristic委托方法的第一行中输出

接收到的数据包响应消息以didUpdateValueForCharacteristic输出，该特征在BTLE设备发送响应数据包（通过第二通知特征）以确认收到我发送的数据包时调用

从一开始可以看出，从调用WriteValueForCharacteristic方法到确认数据包已在didWriteValueForCharacteristic中发送的回调之间的时间最初为85毫秒（这已经很慢，但可以承受）。我大约每5秒发送一次这些数据包，仅发送少量数据包后，这会增加到~2秒，之后似乎会在2秒时持续保持静态。从BTLE设备发送回的响应数据包总是在确认发送数据包后~2ms

我不明白为什么在调用writeValue和确认回调didWriteValueForCharacteristic之间的CoreBluetooth库中会出现这种延迟

在所有其他方面，代码都工作得很好（BTLE设备完全按照指示执行，并且没有数据包丢失）

我有一个由BT4.0模块制造商（包括源代码）提供的示例应用程序，它没有经历这种不断增长的延迟-不幸的是，示例应用程序设计用于处理模块的大量实现，不仅仅是我们的具体实现，因此它非常复杂，包含了许多与我们的实现无关的代码——我在示例中的每个函数中都放置了断点，并手动逐步确定它们发出的命令，我相信我正在完美地复制它们（但显然不是这样）

我看不出他们在做什么，而我没有做什么，反之亦然。我能指出的两个项目之间的唯一区别是，我的项目使用ARC，而他们的项目使用手动引用计数

其他资料： 一切都在主线程上运行（与模块制造商示例应用程序一样） 我使用主队列创建中央管理器（类似于模块制造商示例应用程序） 当我的应用程序运行时，iOS设备上的CPU负载仅为3%，似乎没有任何东西因CPU负载等原因而延迟

我正为此而焦头烂额，如果有人能为这个问题提出任何可能的原因或解决方案，我将万分感激

谢谢，

---

里奇

我在这方面取得了一些进展，但消息并不好。原来我对这个问题最初的描述是不正确的。我认为（总是做坏事）模块供应商生产的示例应用程序是正确的，但其报告的计时数字是错误的-当他们报告~3ms发送数据包并检索响应时，他们只是从-didWriteValueForCharacteristic中计时，不包括调用writeValueForCharacteristic和didWriteValueForCharacteristic——这一次我把他们的应用程序包括进来后，他们的应用程序和我的一样慢

经过进一步调查，似乎iOS CoreBooth库造成了请求发送数据包和实际开始发送数据包之间的延迟-这些任意延迟可能在80毫秒到2秒之间。有人知道为什么iOS库在发送实际数据包时如此缓慢吗？我们在Android下运行的等效代码或多或少是即时的

---

如果我戴上我的愤世嫉俗的帽子，我会说苹果故意这样做是为了防止需要快速响应的应用程序使用BTLE开发，从而迫使硬件开发人员使用需要苹果安全芯片的Bluetooth 3，从而在生产的设备上实际招致苹果的许可成本…

首先在所有检查中，检查您得到了什么：

-(void) peripheral:(CBPeripheral *)peripheral didWriteValueForCharacteristic:(CBCharacteristic *)characteristic
 error:(NSError *)error {

}

如果错误代码为0，则表示您在未确认的情况下向外围设备发送值。 检查您的外围设备是否实施了此方法：

//assuming 
@property (strong, nonatomic) CBPeripheralManager       *peripheralManager;

- (void)peripheralManager:(CBPeripheralManager *)peripheral didReceiveWriteRequests:(NSArray *)requests
{
    NSLog(@"WRITE REQUEST!!! %lu",(unsigned long)requests.count);
    //check if there are data

   for (CBATTRequest * req in requests) {
   //send reposnse to Central that you recivied write value and eg / accept / reject the write request
    [self.peripheralManager respondToRequest:req
                                          withResult:CBATTErrorSuccess];
   }


}

---

非常非常有趣的是，他们的示例应用程序没有显示这种延迟，而您的示例应用程序却显示了这种延迟。我没有什么好的理由。这是伏都教，但要排除它，你能试着制作一个简单的手动保留计数应用程序，看看ARC是否影响它吗？这是我一直在考虑的事情。我以前从未遇到过ARC的任何问题，但由于我排除了其他可能性，我得出的结论是，我必须证明这不是问题的根源，并按照你的建议行事。对此，我有另一个想法：可能值得对你的CoreBooth应用程序和带有仪器的示例应用程序进行评测，以查看什么时候创建了什么对象。如果你的应用程序在创建从未发布过的资源方面存在一个微妙的缺陷，那么CoreBluetooth可能会花更多的时间更新不再使用的对象，这可能是速度放缓的原因。我建议使用数据包嗅探器（这里的廉价嗅探器：）来查看物理层发生了什么。通过这种方式，您可以排除数据包丢失作为问题的可能来源。另一个问题来源可能是，您的外围设备发送连接参数更新请求，通过增加连接间隔来减慢未来的连接。我也有同样的问题。你还发现了什么吗？我在iOS 9上也遇到了同样的问题。有人发现过什么吗？