android bound service,BoundService LiveData ViewModel在新的Android推荐架构中的最佳实践

最新推荐文章于 2025-07-12 15:30:47 发布

转载最新推荐文章于 2025-07-12 15:30:47 发布 · 216 阅读

文章标签：

这篇博客探讨了在Android推荐架构中如何合理放置Android服务的问题。作者面临选择将服务置于ViewModel之上还是与Activity/Fragments同级的困境。内容涉及到服务与ViewModel的交互，以及在LiveData和SharedViewModel等不同架构方案下的实现。博客强调了服务作为Android框架一部分的特性，并引用了避免在ViewModel中使用Android依赖的原则。作者列举了多个可能的架构选项，并提出了关于服务作为数据源的考虑。文章寻求关于服务在架构中的最佳位置以及与其它组件交互方式的建议。

我一直在努力思考在新的Android recommended Architecture中放置Android服务的位置 . 我提出了许多可能的解决方案，但我无法决定哪一个是最好的方法 .

我做了很多研究，我找不到任何有用的指导方针或教程 . 我发现关于将服务放在我的应用程序架构中的唯一提示就是这个，来自@JoseAlcerreca Medium post

理想情况下，ViewModels不应该对Android有任何了解 . 这提高了可测试性，泄漏安全性和模块化 . 一般的经验法则是确保ViewModel中没有android . *导入(例如android.arch . *) . 这同样适用于演示者 .

根据这一点，我应该将我的Android服务放在我的Architecture Components层次结构的顶部，与我的Activities和Fragments处于同一级别 . 这是因为Android服务是Android框架的一部分，所以ViewModels不应该知道它们 .

现在，我将简要介绍一下我的场景，但只是为了让全景更清晰，而不是因为我想要这个特定场景的答案 .

我有一个Android应用程序，其中包含MainActivity，其中包含许多片段，所有这些片段都绑定在BottomNavBar中 .

我有一个绑定到myActivity的蓝牙服务及其中一个片段(因为我希望服务与Activty具有相同的生命周期，但我也想直接从我的片段与它进行交互) .

片段与BluetoothService交互以获取两种类型的信息：

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

来自蓝牙设备的数据(在这种情况下，它是比例，因此重量和身体构成) . 需要坚持下去 .

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

LiveData inside AndroidService

具有连接状态和来自蓝牙设备的重量测量值的LiveData位于BluetoothService内 .

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

片段观察LiveData有关连接的状态并相应地调整UI(例如，如果状态已连接，则启用按钮) .

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

Shared ViewModel between fragment and AndroidService

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

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

Fragment在自己的ViewModel中观察LiveData .

Service ViewModel

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

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

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

我非常确定我应该将它们置于架构之上并将它们视为活动/片段，因为BoundServices是Android Framework的一部分，它们由Android操作系统管理，并且绑定到其他活动和片段 . 在这种情况下，我不知道与LiveData，ViewModels和Activities / Fragments交互的最佳方式是什么 .

有些人可能会认为它们应该被视为一个数据源(因为在我的情况下，它认为这是一个好主意，因为我在前一段中所说的所有内容，特别是because of what it says here：

避免将应用程序的入口点(如活动，服务和广播接收器)指定为数据源 . 相反，它们应该只与其他组件协调以检索与该入口点相关的数据子集 . 每个应用程序组件都是相当短暂的，具体取决于用户与其设备的交互以及系统的整体当前运行状况 .

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

Where should we place our Android (Bound) Services and what is their relation with the other architectural components? Is any of these alternatives a good approach?