我们是否应该使用ViewModels在单个活动AppArchitecture中的2个不同片段或捆绑软件之间进行通信？

场景1-如果我们ViewModels用来在片段之间进行通信，则ViewModel必须通过活动引用来创建，因此必须将其保留在内存中，直到活动被销毁为止。

方案2-在主从流程ViewModel中使我们的生活更轻松，但内存使用问题仍然存在。

场景3- viewModelScope在新版本的Arch库中，我们将取消具有Fragment / Activity生命周期的作业，但是如果ViewModel使用活动引用创建了作业，则它将停留在那里直到活动被销毁为止。因此，该作业仍可以执行并且片段已经消失。

您可以使用ViewModels在两个不同的片段（也称为SharedViewmodels）之间进行通信，因为它很简单，但并不完美。

如您所知，SharedViewModels必须处于活动状态，直到第一个联合父级（活动或片段）处于活动状态。

可是等等 ...

ViewModels的目的是什么？

我们是否只为片段之间的通信创建ViewModels？绝对不。

使用ViewModels是否违背ViewModels的目的？不，我说将它们用于片段之间的通信不是完美的，但是如果您有一个小型项目，则可以使用它们，因为它很简单。

那么我该怎么办，而不是使用ViewModels在片段之间进行通信？您可以构建独立的UI组件，并将它们用于片段之间的通信。

构建这个怪异的独立UI组件有什么优势？这样，每个组件都有其自己的ViewModel（或Presenter），并且它们之间没有任何父/子关系。取而代之的是，它们从相同的业务逻辑进行更新，或者在响应式编程中，它们只是遵循相同的模型。

构建独立的UI组件是什么意思，以及如何构建它们？如果您已经熟悉反应式编程，那么我建议您阅读Hannes Dorfmann的这篇很棒的博客文章。如果您不这样做，我只是建议使用EventBus库在片段之间进行通信，但是您很快就会意识到该库的过多使用会导致产生意大利面条式代码。