android - Android MVVM 设计 - 我应该将我的视图模型类一分为二吗？

Question

我有一个具有 2 种截然不同的模式的应用程序（设置和运行计时器）。

该应用程序允许用户在一个片段上进行多因素输入，一旦用户想要启动计时器，应用程序就会切换到正在运行的片段以显示有关其正在运行的计时器及其设置的信息。我为此设计了一个 MVVM 架构，使用我自己的扩展类ViewModel，我的共享视图模型有两种截然不同的逻辑类型，设置逻辑（检查、解析和修改不适当的用户输入）和运行计时器逻辑（管理所有来自用户输入的运行定时器的逻辑、数据和状态）。

我的共享视图模型类并不小，因为检查用户输入的所有排列的过程很复杂。我想知道将所有这些逻辑放入一个视图模型类中是不是一个坏主意？设置部分设计得很简单，所有设置状态都被保存（因此用户设置计时器似乎需要 10-20 秒），而计时器被设计为允许运行数小时，主要是在屏幕关闭的情况下。我是否应该将 viewmodel 逻辑拆分为两个不同的 viewmodel 类以使正在运行的计时器更节省内存？

我看到了清晰的关注点，一旦我设计和编程了 Room 数据库，只有运行计时器会将数据保存到数据库中。我想让片段类尽可能轻量级。如果这是一个明智的设计选择，那么就需要小心两种状态之间的内存泄漏，否则我就达不到目的了。

编辑以区分 ViewModel 对象和共享视图模型的想法

标签： androidviewmodelandroid-mvvm

Answer 1

正如a_local_nobody所说，由您决定如何设计您的应用程序并分配职责。

如果您正在寻找我们对您的哲学疑问的看法，我不得不说，虽然共享视图模型的概念非常普遍，但我不是一个大粉丝。

在我的项目中，最常见和最合乎逻辑的事情是每个 ViewModel 管理单个视图的逻辑。我总是将共享视图模型视为规则的一个例外，因为滥用它们通常会导致代码耦合非常紧密，很难测试并且会产生意想不到的副作用。