为什么有些人还在jetpack compose中使用viewmodel？

Question

我在 YouTube 上观看了一些教程项目，其中一些制作了 viewmodel 文件并编写了一些代码，只是为了使用 viewmodel！

我们有

remember

和

rememberSavable

和

state

和

recomposition

和......在喷气背包中组成。那么为什么还有人使用 viewmodel 呢？！ 这是更多的代码，使我们初学者更难以理解该项目。

我猜他们几乎没学过 XML 的视图模型，而且他们不能就这样忘记它！

在jetpack compose中是否可以以我们不需要使用viewmodel的方式编写代码？

Answer 1

ViewModel 对于在屏幕之间传递数据或更改可组合项（如 xml 中的另一个可组合项）仍然很有用。

假设您有一个要更改 TopAppBar 的 Cart 可组合项，或者其他彼此不相关但会更改 TopAppbar 颜色或文本的可组合项。您可以使用共享 ViewModel 从各个位置进行设置并侦听 TopAppBar 可组合项中的 mutableState。

此外，remember是通过重组来存储数据的，rememberSaveable在remember之上添加了配置更改。当您移至下一个屏幕并返回时，如果您的可组合项未组合，这些将被重新实例化，但只要您的应用程序处于活动状态，您就可以将数据保留在 ViewModel 中。您可以通过多种方式使用 ViewModel。

最后但并非最不重要的一点是，请记住使您的可组合项具有状态，而不是使用状态托管使您的可组合项更易于维护。

如果您在有状态可组合项的顶部构建层，则当子项或父项中的任何 MutableState 更改时，您的可组合项将进入状态排列。

跟踪从父级到子级的状态变化可能很困难。当我

Modifier.pointerInput(keys)

状态未按预期改变时，我有时会遇到此问题。

在我看来，状态管理是 Compose 最困难的方面之一。因此，状态较少的可组合项可以更轻松地管理可组合项的内部更改

Answer 2

使用ViewModel的建议仍然存在，因为我们应该尽可能在ViewModel中进行计算，除了那些需要在像素空间中计算的情况。

另一方面，我们必须使用ViewModel来调用Domain层特定的接口方法。

建议我们的表示层逻辑和代码不要依赖于 Compose 或 XML。

使用 ViewModel 进行测试也是合乎逻辑的

Answer 3

在开发除最琐碎的应用程序之外的所有应用程序时，牢记“关注点分离”非常重要。 我们一直有能力将所有代码放在一个地方 - 早期的 Android 开发通常只是将所有代码放在一个整体活动中。这给代码复杂性、维护/支持和增强带来了噩梦。

将所有内容都放入组合中基本上会退回到早期的黑暗日子。 ViewModel（以及 Presenters/Controllers/Coordinators/etc）迫使您以遵循 SoC 原则的方式构建应用程序。您的虚拟机包含屏幕关心的数据，您的控制器类包含与视图无关的屏幕逻辑等。

SoC 非常重要 - 我认为了解它的重要性的最彻底方法是忽略它，然后必须忍受你的决定，因为你将来必须处理你的代码！但如果你愿意避开职业生涯中痛苦的部分，那么就可以向前人学习。