android - BoundService + LiveData + ViewModel 新安卓推荐架构最佳实践

Question

我一直在苦苦思索在新版 Android recommended Architecture 中放置 Android 服务的位置。 .我想出了很多可能的解决方案，但我无法决定哪一种是最好的方法。

我做了很多研究，但找不到任何有用的指南或教程。我发现的关于在我的应用程序架构中放置服务的位置的唯一提示是来自@JoseAlcerreca Medium post 的提示。

Ideally, ViewModels shouldn’t know anything about Android. This improves testability, leak safety and modularity. A general rule of thumb is to make sure there are no android.* imports in your ViewModels (with exceptions like android.arch.*). The same applies to presenters.

据此，我应该将我的 Android 服务放在我的架构组件层次结构的顶部，与我的 Activity 和 fragment 处于同一级别。这是因为 Android 服务是 Android 框架的一部分，所以 ViewModel 不应该知道它们。

现在，我将简要解释我的场景，但只是为了让全景图更清晰，而不是因为我想要这个特定场景的答案。

我有一个 Android 应用程序，它有一个包含许多 fragment 的 MainActivity，所有这些 fragment 都 bundle 在一个底部导航栏中。

我有一个绑定(bind)到 myActivity 及其 fragment 之一的 BluetoothService(因为我希望该服务具有与 Activty 相同的生命周期，但我也想直接从我的 fragment 与其交互)。

该 fragment 与 BluetoothService 交互以获取两种类型的信息:

有关蓝牙连接状态的信息。不需要坚持。

来自蓝牙设备的数据(它是一个体重秤，在这种情况下是体重和 body 成分)。需要坚持。

以下是我能想到的 3 种不同的架构:

AndroidService 中的 LiveData

带有连接状态和权重的 LiveData
来自蓝牙设备的测量值位于蓝牙服务内部。

Fragment可以触发BluetoothService中的操作(例如scanDevices)

Fragment 观察有关连接状态的 LiveData
并相应地调整 UI(例如，如果
状态已连接)。

Fragment 观察新重量测量的 LiveData。如果新的重量测量值来自 BluetoothDevice，则 Fragment 会告诉它自己的 ViewModel 保存新数据。它是通过 Repository 类完成的。

fragment 和 AndroidService 之间共享 ViewModel

Fragment可以触发BluetoothService中的操作(例如scanDevices)

BluetoothService 更新共享 ViewModel 中与蓝牙相关的 LiveData。

Fragment 在自己的 ViewModel 中观察 LiveData。

服务 View 模型

Fragment可以触发BluetoothService中的操作(例如scanDevices)

BluetoothService 在其自己的 ViewModel 中更新与蓝牙相关的 LiveData。

Fragment 在自己的 ViewModel 和 BluetoothService ViewModel 中观察 LiveData。

我很确定我应该将它们放在体系结构的顶部并将它们视为 Activity/Fragment，因为 BoundServices 是 Android 框架的一部分，它们由 Android 操作系统管理并且它们绑定(bind)到其他 Activity 和 fragment 。在这种情况下，我不知道与 LiveData、ViewModels 和 Activity/fragment 交互的最佳方式是什么。

有些人可能认为它们应该被视为数据源(因为在我的情况下它是使用蓝牙从秤中获取数据)，但我认为这不是一个好主意，因为我在上一段中说过特别是 because of what it says here :

Avoid designating your app's entry points—such as activities, services, and broadcast receivers—as sources of data. Instead, they should only coordinate with other components to retrieve the subset of data that is relevant to that entry point. Each app component is rather short-lived, depending on the user's interaction with their device and the overall current health of the system.

所以，最后，我的问题是:

我们应该在哪里放置我们的 Android(绑定(bind))服务，它们与其他架构组件的关系是什么？这些替代方案中的任何一个是一个好方法吗？

Answer 1

更新:
在得到@Ibrahim Disouki 的建议后(谢谢你)，我深入挖掘并发现了一些有趣的东西!这是背景。
OP 寻求解决方案“考虑到 Android 架构组件，Android 框架的服务组件在哪里”。所以，这是开箱即用的(SDK)解决方案。
与Activity/Fragment处于同一水平.怎么样？如果您要扩展 Service 类而不是那样，请开始扩展 LifecycleService .这背后的原因很简单，以前我们必须依赖 Activity/Fragment 生命周期才能接收更新/对 Service 执行一些上下文操作。但现在情况并非如此。LifecycleService现在有自己的生命周期注册表/维护器，名为 ServiceLifecycleDispatcher它负责服务的生命周期，这也使它LifecycleOwner .
它让我们处于这样的状态，从现在开始，您可以拥有 ViewModel至 LifecycleService为自己做操作，如果您遵循正确的应用程序架构并且拥有存储库模式，那么您将获得单一的事实来源!
在 O.P. LifecycleService 的上下文中，现在可以维护它的 ViewModel做与存储库层相关的业务逻辑，然后是另一个生命周期感知组件，如 Activity/Fragment 也可以使用/重用相同的 ViewModel有他们的具体操作。
请注意，通过这样做，您将拥有两个不同的 LifecycleOwner s (Activity & LifecycleServie) 这意味着你不能在 LifecycleService 之间共享 View 模型和其他生命周期感知组件。如果你不喜欢这种方法，那么最好使用旧的回调方法，当数据准备好提供服务时回调到 Activity/Fragment 等。

过时:
(我建议不要通读)
在我看来，服务应该与 处于同一级别 Activity/fragment ，因为它是框架组件而不是 MVVM .但正因为如此 Service 没有实现 LifecycleOwner 并且它是 Android 框架组件，不应将其视为 数据源因为它可以是应用程序的入口点。
因此，这里的困境是有时(在您的情况下)，Service 充当数据源，将一些长时间运行的任务的数据提供给 UI。
那么它应该是什么 Android 架构组件 ?我想你可以把它当作 LifecycleObserver .因为，无论你在后台做什么，你都需要考虑 的生命周期。生命周期所有者 .
为什么？因为，我们通常会将它绑定(bind)到 生命周期所有者 (Activity/Fragments) & 在 UI 之外执行长时间运行的任务。所以，它可以被当作 生命周期观察者 .通过这种方式，我们将我们的服务作为“生命周期感知组件”!

How you can implement it?

参加您的服务类(class)并实现 生命周期观察者 它的接口(interface)。

当您将服务绑定(bind)到 Activity/Fragment 时, 在您的服务类的服务连接期间，通过调用方法 getLifecycle().addObserver(service class obj) 将您的服务作为 LifecycleObserver 添加到您的 Activity 中

现在，在服务类中使用一个接口(interface)来提供从服务到 UI 的回调，每次数据更改时，请检查您的服务是否至少有生命周期事件 create或 resume提供回调。

这样，我们就不需要 LiveData更新到服务，甚至没有 ViewModel (为什么我们需要它来服务？我们不需要更改配置来在服务生命周期中生存。VM 的主要任务是在生命周期之间整合数据)。

旁注:如果你认为你有长时间运行的后台操作，那么考虑使用 WorkManager .使用此库后，您会觉得现在应该将服务标记为已弃用! (只是一个随意的想法)