本机Android BLE实现本质上是同步的吗？

我记得在-doc中读到：

三星F/W和stack最重要的概念之一是 它的同步性。就是比如说打电话,，

writeCharacteristic

用于特定特征，如果返回

true

，对任何

BluetoothGatt

或

BluetoothGattServer

方法的下一次调用 应在收到

onCharacteristicRead

回调后执行。 这是因为堆栈设计为只支持和处理一个 关贸总协定一次打电话，如果你打电话

writeCharacteristic

或

readCharacteristic

在任何特征上 在第一个之后，它被忽略

这是否也适用于BLE的本机实现 在安卓4.3中

三星API一次也只支持一个连接的GATT设备。 这在本机API中发生了变化吗

不是。大多数函数调用都是异步的

我不知道。官方文档没有提到它，但也没有说它只支持一种设备。我相信这是可能的。检查这篇文章：

---

它说（我不知道它的来源是什么）多个外围设备可以连接到一个安卓中央设备

三星最近在我问题中链接的同一页上发布了一份“迁移”文档。在比较新的本机BLE API和三星BLE API时，他们准确地回答了我的问题：

堆栈和F/W的同步性质没有受到影响。 也就是说，如果我们为特定的 特征，如果返回true，则下一次调用任何

BluetoothGatt

或

BluetoothGattServer

方法应在收到

onCharacteristicRead

回调后执行。这是因为堆栈是经过设计的 一次只支持和处理一个关贸总协定请求，如果 例如，在第一个

特征

后不久调用任何

特征

的

writeCharacteristic

或

readCharacteristic

，它将被忽略

---

三星ble API在某种程度上也是异步的。您在回调中得到了答案（顺便说一句，API非常类似），但是，如果您在短时间内发出2个请求，而第一个请求没有完全进行，那么第一个请求可能会被取消。所以问题是，如果本机API也有这种行为。啊，好的，现在我明白了。我不知道本地API是否遵循这种行为。我认为是这样。如果你发射了2个扫描，前一个会被取消，但我不确定。我真的很高兴我发现了这个问题。谷歌并没有特意把这一点说清楚。当一个读/写请求实际上被忽略时返回true是非常令人困惑的。有人能确认android.bluetooth.BluetoothGatt是否只能处理每个设备、每个进程或周期（即：所有进程）的一个挂起的GATT操作吗。我认为这是每个设备的问题，但这个问题是如此混乱，如果不是这样的话，我也不会感到惊讶。如果限制仅限于每个设备，那么能够同时处理多个操作的操作系统/设备就是确凿的证据，证明这个问题纯粹是由于BluetoothAdapter实例中的一些薄弱的幼稚实现造成的，操作系统负责每个进程（我曾假设所有进程都是单例）。这是每个BluetoothGatt对象的一个挂起操作。@Emil我刚刚回滚了您在该问题上的更改。请不要修改三星工程师的报价。如果你对它的内容有问题，请加上评论。这是一个明显的打字错误。在写入请求之后等待写入响应。写请求后，您不必等待读取响应……Google的问题跟踪器上有一个与API的同步性质相关的线程正在运行：我刚刚为所有写入实现了一个队列，到目前为止似乎运行良好。@根据三星提供的文档，behavoir不限于写入操作。是的，使用队列是解决这个问题的常用方法到目前为止运行良好：很难测试和再现另一个命令的取消。当BLE代码变得更复杂时，您常常会遇到问题，因为您根据以前的调用做了更多的工作。我只在前一个BLE操作完成（收到应答）后或前一个BLE操作未能在适当时间完成后执行下一个BLE操作。顺便说一句，你的评论更适合作为这个问题的答案。@Ash你能分享你的实现吗？@Ewoks