3

我的 BLE 外围设备的 Android 应用程序写入 2 个不同的设备特征并接收来自其他 2 个的通知。该RxAndroidBle库的开发人员告诫不要在同一个RxBleConnection实例上进行多个订阅，但我看不到任何将所有这些 I/O 操作组合成一个的现实方法.subscribe()，特别是因为其中一个通知是一个相当恒定的数据“消防软管”。

不知道更好，我只是将 存储RxBleConnection在一个变量中并在多个.subscribe()s 中使用它。据我所知，这一切正常。我已经调查了RxAndroidBle图书馆ConnectionSharingAdapter，但是，虽然我已经分析了代码，但我不明白它比我的简单方法有什么好处（尽管我很想知道）。

一般来说，详细说明多个.subscribe()s 如何引入状态以及潜在的陷阱会有所帮助。问题：

  1. 存储RxBleConnection在变量中并将其用于多个.subscribe()s 有什么问题？
  2. 如果这是一个问题，如何ConnectionSharingAdapter解决？
  3. 说多个订阅“引入状态”是什么意思，这怎么会导致问题？
  4. 是否有任何干净的方法将所有四个特征 I/O 操作组合成一个.subscribe()（不会降低性能）？
4

1 回答 1

4

存储RxBleConnection在变量中并将其用于多个.subscribe()s 有什么问题？（...）说多个订阅“引入状态”是什么意思，这怎么会导致问题？

这两个问题几乎是一样的。AnRxBleConnection是对 BLE 客户端与 BLE 服务器交换一些握手数据包的状态的抽象，之后客户端和服务器都被认为是连接的。不幸的是，由于各种原因，这种连接几乎在任何时候都可能被破坏（而且这种情况经常发生），单个存储的变量RxBleConnection无法以反应方式轻松表达。

另一方面RxBleDevice.establishConnection()，一旦连接断开，观察将向订阅者传播错误。尽管RxBleConnection一旦连接断开，发出的任何功能都不会起作用 - 保存的连接变量不会在问题发生时通知问题。

因此，如果用户将 an 保存RxBleConnection到变量中 - 它会引入变量可能处于的状态，并且用户负责传播（清除变量）稍后可能发生的错误。作为相反的订阅.establishConnection()将在无法使用连接时发出异常。

正如许多程序员在实践中可能已经注意到的那样 - 管理状态是应用程序中最常见的错误来源。减少状态是降低错误风险的一种方法。

Jake Wharton 的 Devoxx 有一个出色的（但相当高级的）演讲：Jake Wharton的用 RxJava 管理状态

如果这是一个问题，如何ConnectionSharingAdapter解决？

由于.establishConnection()BLE 连接和通信的状态特性（请求-响应是一种众所周知的模式），observable 不允许同时拥有多个订阅，并且拥有多个.subscribe()使用相同连接的连接可能会在没有清除代码中的痕迹。这就是BleAlreadyConnectedException为不遵循代码中所有使用RxBleConnection. ConnectionSharingAdapter被引入作为有意识地决定在多个交互者之间共享单个连接的用户的帮助器。如果RxBleConnection被破坏，ConnectionSharingAdapter会将错误传播到所有Subscribers。

是否有任何干净的方法将所有四个特征 I/O 操作组合成一个.subscribe()（不会降低性能）？

在大多数情况下，可以干净地组合许多 I/O。上面提到的谈话涉及这个话题。正确组合多个 I/O 会带来额外分配的成本，但在处理 BLE 时很少会出现问题，因为此通信通道的速度较低。

于 2017-06-19T20:33:51.980 回答