我在其中一个应用中启用了 CoreBluetooth。有一个中央 iOS 设备,最多可以连接 2 个外围 iOS 设备。
我已经通过使用中央订阅的外围设备上的一个特性实现了上游通信,并且我已经通过使用中央存储和写入的外围设备上的另一个特性实现了下游通信 writeValue:forCharacteristic:type :
这些在外围设备中设置如下:
upstream = [[CBMutableCharacteristic alloc] initWithType:pipeUUID properties:CBCharacteristicPropertyNotify value:nil permissions:0];
downstream = [[CBMutableCharacteristic alloc] initWithType:downstreamUUID properties:CBCharacteristicPropertyWrite value:nil permissions:CBAttributePermissionsWriteable];
向下游发送数据时,通常如下所示:
NSData* data = [[NSString stringWithFormat"%d,%d", AppStateID, SomeValue] dataUsingEncoding:NSUTF8StringEncoding];
[_peripheral1 writeValue:data forCharacteristic:_peripheral1Downstream type:CBCharacteristicWriteWithResponse];
这个实现确实有效,而且效果很好,但我注意到有时会有一些阻碍。
当我通过上游特性从外围设备向中央设备发送数据时,中央设备几乎会立即接收数据,通常是在同一帧上。但是,当我通过下游特性从中心向外围设备发送数据时,外围设备接收数据可能需要 0.5 秒到 5 秒。
这不是一个大问题,但如果他们不花这么长时间进行交流,这对用户体验肯定会更好。
所以我的问题是:
- 首先我的实现有什么问题吗?
- 如果是,正确的方法是什么?
- 如果没有,是否有任何方法可以优化从中央到外围的通信,或者是否有类似的通知特性可以用来向下游而不是上游发送数据?
如果它是相关的,我会注意到我确实从写请求中得到了一个反复出现的错误,即使它们确实成功了。
Write error: Error Domain=CBATTErrorDomain Code=241 "Unknown ATT error." UserInfo={NSLocalizedDescription=Unknown ATT error.}
Best Answer-推荐答案 strong>
您的实现看起来不错,但在外围端代码中,您需要成功响应写入请求,否则中央将超时并在 5 秒左右后给出错误 - 您正在上面的那个。该值仍会在 Peripheral 上更新,但中央无法知道这一点,除非您像 (Swift) 一样响应:
self.peripheralManager.respondToRequest(request, withResult: CBATTError.Success)
关于ios - 为什么 CBCharacteristics 接收写入值比更新值需要更长的时间?,我们在Stack Overflow上找到一个类似的问题:
https://stackoverflow.com/questions/33299794/
|