【问题标题】:Is there a way to discover BLE peripheral service faster?有没有办法更快地发现 BLE 外围服务?
【发布时间】:2023-03-17 11:40:01
【问题描述】:

我发现我在 iOS7 中实现的 BLE 协议在启动阶段非常缓慢。在我的应用程序中,启动顺序约占整个执行时间的 68%。

我该怎么做才能让它更快?

我已经计时了,这就是我得到的。

     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    

如您所见,在发现服务之前存在巨大的瓶颈。

我的启动代码简化了:

- (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 上进行了测试。

【问题讨论】:

  • 我很好奇您花了多长时间发现外围设备。我的猜测是发现外设及其服务的时间与它们的硬件实现有关。
  • 根据我的经验,以较高速率宣传自己的外围设备将花费更短的时间来发现服务。不过可能是巧合,因为我只有几个外围设备可以玩。此外,我发现外设服务的最长时间约为 0.5 秒,这对我来说是可以接受的。
  • 我再次测试了两个完全不同(硬件方面)的外围设备,结果是相同的(给或需要 50 毫秒)。我不确定如何在发现外围设备之前测量时间?发现外围设备和发现服务之间的增量时间仍然非常重要,因为它使应用程序感觉比它可能的更迟钝。
  • 您使用什么类型的设备..?我尝试使用 CiragoBLE BT8000 加密狗.. 但它没有检测到.. 请列出一些用于在 ios 中检测的蓝牙加密狗。提前致谢!
  • 我没有使用加密狗,我使用的是专门为与 BLE 设备(不仅是 iOS 设备)通信而构建的单独的 BLE 外设。您是否尝试过使用 LightBlue 检测您的加密狗? itunes.apple.com/gb/app/lightblue-bluetooth-low-energy/…

标签: objective-c ios7 bluetooth-lowenergy


【解决方案1】:

当您加密连接时,iOS 应该缓存 GATT 数据库。因此,第一个发现调用之后的后续发现调用应该立即发生。

从 iOS 7 开始,甚至特征值也会被缓存,这意味着您可以通过特征的 value 属性读取静态值,例如“设备名称”。如果您想更新它们,您仍然需要发出读取特征值请求。

有关缓存行为的详细信息,请查看幻灯片 48 中的WWDC 2013 session 703(应该可以观看视频中的相应部分)。

对于连接和发现时间,主要是广告间隔。为了在Bluetooth Accessory Design Guidelines For Apple Products 中获得最佳性能,Apple 推荐了几个广告间隔(第 3.5 节广告间隔)。此外,您应该在连接时禁用扫描,因为扫描会使连接过程减慢大约 55 倍。

请注意,基于 iOS 的对每个连接事件发送的数据包数量的限制不应显着影响发现时间(除非您有一个巨大的 GATT 数据库并且正在查询整个事物)。根据 LE 协议设计,这些限制应该只对“无响应写入”和“特征值通知”可见。

【讨论】:

【解决方案2】:

没有用于提高发现速度的框架级 API。 BTLE 与 Classic Bluetooth(在系统框架层面)和 Wi-Fi(在天线层面)共存,因此天线上的最长时间受系统限制。

【讨论】:

  • 那么这取决于硬件吗?那么这就解释了更快的 Android 应用程序。
  • 或多或少,是的。我想,在 Android 手机中,您可能还会看到响应能力的一些变化:不同的芯片组和天线布局将决定不同的共存要求。
猜你喜欢
  • 1970-01-01
  • 2014-10-16
  • 1970-01-01
  • 1970-01-01
  • 2021-03-21
  • 1970-01-01
  • 2017-03-26
  • 1970-01-01
  • 2020-01-18
相关资源
最近更新 更多