ViewModels 和 LiveData:模式 +反模式

原文链接 ViewModels and LiveData: Patterns + AntiPatterns。

Views 和 ViewModels

分配职责

 

ViewModels 和 LiveData:模式 +反模式_第1张图片

使用 Architecture Components 构建的 app 中实体的典型交互

理想情况下,ViewModels 不应该知道任何关于 Android 的事情。这提高了可测试性、泄漏安全性和模块性。一般的经验法则是确保在您的 ViewModels 中没有 android.* imports(android.arch.*除外)。这同样适用于 presenters。

❌  不要让 ViewModels(和 Presenters)知道 Android 框架类

条件语句,循环和一般决策应在 ViewModels 或 app 的其他层中完成,而不是在 Activities 或 Fragments 中完成。View 通常不经过单元测试(除非你使用 Robolectric)所以代码行越少越好。Views 应该只知道如何显示数据并将用户事件发送到 ViewModel(或Presenter)。这称为 Passive View(被动视图)模式。

✅ 将 Activities 和 Fragments 中的逻辑保持在最低限度

ViewModels 中的 View 引用

ViewModels 与 activities 或 fragments 具有不同的作用域。当 ViewModel 处于活动状态并正在运行时,activity 可以处于任何 lifecycle states(生命周期状态)。Activities 和fragments 可以在 ViewModel 不知情的情况下被销毁并重新创建。

 

ViewModels 和 LiveData:模式 +反模式_第2张图片

ViewModels 在配置更改时仍会留存

将 View(activity 或 fragment)的引用传递给 ViewModel 是一个严重的风险。让我们假设 ViewModel 从网络请求数据,并且数据会在一段时间后返回。此时,View 引用可能会被破坏,或者可能是一个不再可见的旧 activity,从而导致内存泄漏,并可能导致崩溃。

❌ 避免在 ViewModels 中引用 Views。

ViewModels 和 Views 之间通信的推荐方法是使用其他库中的 LiveData 或 observables 的观察者模式。

观察者模式

 

ViewModels 和 LiveData:模式 +反模式_第3张图片

在 Android 中设计表示层的一个非常方便的方法是让 View(activity 或 fragment)观察(订阅更改来自)ViewModel。因为 ViewModel 不知晓 Android,所以它不知道 Android 是多么喜欢频繁地杀死 Views。这有一些优势:

  1. ViewModels 在配置更改时保持不变,因此在旋转发生时无需重新查询外部数据源(如数据库或网络)。
  2. 当长时间运行的操作完成时,ViewModel 中的可观察对象将被更新。数据是否被观察并不重要。尝试更新不存在的 View 时不发生空指针异常。
  3. ViewModels 不引用视图,因此内存泄漏的风险较小。
private void subscribeToModel() {
  // 观察 product 数据
  viewModel.getObservableProduct().observe(this, new Observer() {
      @Override
      public void onChanged(@Nullable Product product) {
        mTitle.setText(product.title);
      }
  });
}

来自 activity 或 fragment 的典型订阅。

✅ 不要将数据推送到 UI,而是让 UI 观察数据的更改。

臃肿的 ViewModels

无论什么,只要让你的关注点分离,就是好主意。 如果你的 ViewModel 持有太多代码或承担太多责任,请考虑:

  • 将一些逻辑移到与 ViewModel 具有相同作用域的 presenter。它将与 app 的其他部分进行通信,并更新 ViewModel 中的 LiveData 持有者。
  • 添加一个Domain 层,并采用 Clean Architecture。这导致了一个非常可测试和可维护的架构。它也有助于快速脱离主线程。 Architecture Blueprints 中有一个 Clean Architecture 示例。
✅ 分配职责,必要时添加 domain(域) 层。

使用数据仓库

如 应用程序架构指南 所示,大多数 apps 都有多个数据源,例如:

  1. Remote(远端): 网络或云
  2. Local(本地): 数据库或文件
  3. 内存缓存

在你的 app 中有一个数据层是一个好主意,它完全不知道您的表示层。保持缓存和数据库与网络同步的算法并不简单。建议将单独的仓库(repository)类作为处理此复杂性的单一入口点。

如果您有多个差异较大的数据模型,请考虑添加多个仓库。

✅ 添加数据仓库作为你的数据的单一入口点

处理数据状态

请考虑以下情况:您正在观察由 ViewModel 公开的 LiveData,该 ViewModel 包含要显示的条目列表。View 如何在正在加载数据,网络错误和空列表之间进行区分?

  • 您可以从 ViewModel 公开 LiveData。 例如,MyDataState 可以包含有关数据当前是否正在加载,是否已成功加载或失败的信息。

 

ViewModels 和 LiveData:模式 +反模式_第4张图片

您可以将数据包装在一个具有状态和其他元数据(如错误消息)的类中。参见示例中的 Resource 类。

✅ 使用包装器或其他 LiveData 公开有关数据状态的信息。

保存 activity 状态

Activity 状态是 activity 消失后(意味着 activity 已被销毁或进程被终止)重新创建屏幕所需的信息。旋转是最明显的情况,我们已经用 ViewModels 覆盖了它。如果状态保存在 ViewModel 中,则状态是安全的。

但是,您可能需要在 ViewModels 也消失的其他场景中恢复状态:例如,当操作系统资源不足并导致您的进程终止时。

要有效地保存和恢复 UI 状态,请使用 onSaveInstanceState() 和 ViewModels 的持久化组合。

有关示例,请参阅:ViewModels: Persistence, onSaveInstanceState(), Restoring UI State and Loaders

事件

一次事件只发生一次。ViewModels 公开数据,但事件呢? 例如,导航事件或显示 Snackbar 消息是应该只执行一次的操作。

事件(Event)的概念与 LiveData 存储和恢复数据的方式不完全吻合。考虑具有以下字段的 ViewModel:

LiveData snackbarMessage = new MutableLiveData<>();

activity 开始观察此操作,ViewModel 完成操作,因此需要更新消息:

snackbarMessage.setValue("Item saved!");

activity 接收该值并显示 Snackbar。很明显,它起作用了。

但是,如果用户旋转手机,则会创建新的 activity 并开始观察。当 LiveData 观察开始时,activity 立即收到旧值,这将导致消息再次显示!

不要试图通过库或对 Architecture Components 的扩展来解决这一问题,而是将其作为设计问题来面对。我们建议您将事件视为状态的一部分

✅ 将事件设计为你的状态的一部分。有关更多详细信息,请阅读  LiveData with SnackBar, Navigation and other events (the SingleLiveEvent case)。

泄漏的 ViewModels

反应式范式在 Android 中运行良好,因为它允许 UI 与 app 的其他层之间的便捷连接。LiveData 是此结构的关键组件,因此通常您的 activities 和 fragments 将观察 LiveData 实例。

ViewModels 如何与其他组件通信取决于您,但要注意泄漏和边缘情况。考虑这个图表,其中 Presentation 层使用观察者模式,Data 层使用回调:

 

ViewModels 和 LiveData:模式 +反模式_第5张图片

UI 中的观察者模式和数据层中的回调

如果用户退出 app,View 将消失,因此 ViewModel 也将不再被观察。如果仓库是单例的或是以其他方式被限定到应用程序范围内的,则仓库在进程终止之前不会被销毁。这只会在系统需要资源或用户手动杀死 app 时发生。 如果仓库持有对 ViewModel 中回调的引用,则 ViewModel 将暂时泄露

 

ViewModels 和 LiveData:模式 +反模式_第6张图片

activity 已经 finished,但 ViewModel 仍然存在

如果 ViewModel 很轻量或者保证操作很快完成,那么这个泄漏就不是什么大问题。然而,情况并非总是如此。理想情况下,当 ViewModels 没有任何观察它们的 Views 时,它们应该可以自由行动:

 

ViewModels 和 LiveData:模式 +反模式_第7张图片

您有许多选择来实现这一点:

  • 使用ViewModel.onCleared() 可以告诉仓库删除对 ViewModel 的回调。
  • 在仓库中,您可以使用 WeakReference ,也可以使用 Event Bus(两者都容易滥用甚至被视为有害)。
  • 以在 View 和 ViewModel 之间使用 LiveData 的相似方式,在 Repository 和 ViewModel 之间使用  LiveData 通信。
✅ 考虑边缘情况,泄漏以及长时间运行的操作如何影响架构中的实例。
❌ 不要在 ViewModel 中放置对保存干净状态或与数据相关的关键逻辑。您从 ViewModel 进行的任何调用都可能是最后一个。

仓库中的 LiveData

为了避免泄漏 ViewModels 和回调地狱,可以像这样观察仓库:

 

ViewModels 和 LiveData:模式 +反模式_第8张图片

ViewModel 被清除或 view 的生命周期被 finished 后,也将订阅清除:

 

ViewModels 和 LiveData:模式 +反模式_第9张图片

如果您尝试这种方法,有一个问题:如果您无法访问 LifecycleOwner,您如何从 ViewModel 订阅 Repository ? 使用 Transformations 是解决此问题的一种非常方便的方法。Transformations.switchMap 允许您创建一个新的 LiveData,以响应其他 LiveData 实例的更改。它还允许在整个链中携带观察者生命周期信息:

LiveData repo = Transformations.switchMap(repoIdLiveData, repoId -> {
        if (repoId.isEmpty()) {
            return AbsentLiveData.create();
        }
        return repository.loadRepo(repoId);
    }
);

Transformations 示例[资源]

在此示例中,当触发器获得更新时,将应用该函数并在下游调度结果。一个 activity 将观察 repo ,并且相同的 LifecycleOwner 将用于repository.loadRepo(id)调用。

✅ 每当您认为在 ViewModel 中需要  Lifecycle 对象时, Transformation 可能就是解决方案。

继承 LiveData

LiveData 最常见的用例是在 ViewModels 中使用 MutableLiveData 并将它们作为 LiveData 公开,以使它们从观察者中不可变。

如果您需要更多功能,继承的 LiveData 会在有活跃的观察者时通知您。例如,当您想要开始监听位置或传感器服务时,这非常有用。

public class MyLiveData extends LiveData {

    public MyLiveData(Context context) {
        // 初始化服务
    }

    @Override
    protected void onActive() {
        // 开始监听
    }

    @Override
    protected void onInactive() {
        // 停止监听
    }
}

什么时候不继承 LiveData

您还可以使用 onActive() 来启动一些加载数据的服务,但除非您有充分的理由,否则您无需等待 LiveData 被观察。一些常见的模式:

  • 将一个 start() 方法添加到 ViewModel 并尽快调用它[参见 Blueprints example]
  • 设置启动加载的属性[参见 GithubBrowserExample]。
❌ 您通常不会继承 LiveData。 让您的活动或片段告诉 ViewModel 什么时候开始加载数据。

 

你可能感兴趣的:(android,翻译)