问题描述
我发现我在iOS7中实现的BLE协议在启动阶段非常慢。启动顺序相当于我应用程序整个执行时间的68％。
I find that my implementation of the BLE protocol in iOS7 to be very slow in the start up phase. The startup sequence amounts to ~68% of the whole execution time in my app.
我能做些什么才能让它更快？
What can I do to make it faster?
我已经计时了，这就是我得到的。
I've timed it, and here's what I get.
t dt
37.598 [BLE] Discovered peripheral at RSSI -27 with UUID:XYZ
37.599 0.001 [BLE] Connecting to peripheral
37.602 0.003 [BLE] Scanning stopped
37.685 0.083 [BLE] Peripheral connected
38.48 0.795 [BLE] Discovered service
38.599 0.119 [BLE] Discovered characteristic
尽可能在发现服务之前看到一个巨大的瓶颈。
As you can see there's a huge bottle neck before discovering the service.
我的启动代码简化：
- (void)centralManagerDidUpdateState:(CBCentralManager *)central {
switch (central.state) {
case CBCentralManagerStatePoweredOn:
[central scanForPeripheralsWithServices:@[[CBUUID UUIDWithString:kServiceUuid]]
options:@{CBCentralManagerScanOptionAllowDuplicatesKey : @YES}];
break;
case CBCentralManagerStatePoweredOff:
[central stopScan];
break;
default:
break;
}
}
- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary *)advertisementData RSSI:(NSNumber *)RSSI {
if (self.discoveredPeripheral != peripheral) {
self.discoveredPeripheral = peripheral; // Save a local copy of the peripheral, so CoreBluetooth doesn't get rid of it
[central connectPeripheral:peripheral options:nil];
[central stopScan];
}
}
- (void)centralManager:(CBCentralManager *)central didConnectPeripheral:(CBPeripheral *)peripheral {
[peripheral discoverServices:@[[CBUUID UUIDWithString:kServiceUuid]]];
}
- (void)peripheral:(CBPeripheral *)peripheral didDiscoverServices:(NSError *)error {
for (CBService *service in peripheral.services) {
[peripheral discoverCharacteristics:@[array of characteristics]
forService:service];
}
}
- (void)peripheral:(CBPeripheral *)peripheral didDiscoverCharacteristicsForService:(CBService *)service error:(NSError *)error {
...
}
编辑
我已经了解到Android上的类似应用程序的速度提高了十倍（让Android应用程序感觉更快 - >更好的用户体验）所以我很好奇它是我的实现，BLE层还是硬件瓶颈。它在iPhone 4S上进行了测试。
I've learned that similar apps on Android does this ten times faster (making the Android app feel snappier -> better user experience) so I'm curious if it's my implementation, BLE layer or hardware that's the bottleneck. It's tested on an iPhone 4S.
推荐答案
加密连接时，iOS应该缓存GATT数据库。因此，在第一个应该在瞬间发生之后的后续发现调用。
When you encrypt the connection, iOS should cache the GATT database. Therefore, subsequent discovery calls after the first one should happen instantaneously.
从iOS 7开始，即使是特征值也会被缓存，这意味着您可以通过特征的value属性读取静态值，如设备名称。如果要更新它们，则仍需要发出读取特征值请求。
Since iOS 7, even characteristic values are cached, meaning that you can read static values like a "Device name" through the characteristic's value property. If you want to update them, you still have to issue a Read Characteristic Value request.
有关缓存行为的详细信息，请检查（可能应该观看视频中的相应部分）。
For details regarding the caching behavior, check WWDC 2013 session 703 from slide 48 (should probably watch the corresponding part in the video).
对于连接和发现时间，它主要是广告间隔。 Apple推荐了几个广告时段，以便在（第3.5节广告时间间隔）。此外，您应该在连接时禁用扫描，因为扫描会使连接过程减慢大约55倍。
For connection and discovery time, it's mainly the advertisement interval. There are a couple of advertisement intervals that are recommended by Apple for best performance in the Bluetooth Accessory Design Guidelines For Apple Products (section 3.5 Advertising Interval). Also, you should disable scanning when you connect, as scanning slows down the connection process by about 55x.
请注意，基于iOS的每个连接发送的数据包数限制事件不应该明显影响发现时间（除非你有一个巨大的GATT数据库并且正在查询整个事情）。根据LE协议设计，这些限制只应在无响应写入和特征值通知中可见。
Note that the iOS based limitations on the number of packets sent per connection event should not affect discovery time noticeably (unless you have a giant GATT database and are querying the whole thing). Those limitations should only become visible for "Write Without Response" and "Characteristic Value Notification", as per the LE protocol design.
这篇关于有没有办法更快地发现BLE外围服务？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！