关于使用 Android MVVM + LiveData 模式的一些建议，ffmpeg 音视频同步

1. 远程：网络或云

2. 本地：数据库或文件

3. 内存缓存

在你的应用中拥有数据层是一个好主意，展示层完全注意不到。保留缓存、同步数据库和网络的算法都是无关紧要的。拥有一个完全隔离的仓库类作为一个单一的入口来处理这些复杂的事情是非常推荐的。

如果你有多种并且不同的数据模型，考虑添加多种仓库。

? 添加一个数据仓库作为访问数据的单一入口。

处理数据状态

考虑这个场景：你正在观察 ViewModel 中暴露的 LiveData，它包含一个展示项目的列表。那么在数据加载，网络错误或者空列表时，视图该如何呈现这些变化呢？

• 你可以在 ViewModel 中暴露一个 LiveData<MyDataState>。例如，MyDataState 应该包含那些数据是否正在加载，或者加载成功或加载失败的信息。

你可以把数据包裹在一个保存了状态或其他元数据（例如一条错误消息）的类中。看看我们样例中的 [Resource](

) 类。

? 使用一些包裹类或另一个 LiveData 来暴露你数据的信息。

保存 Activity 状态

Activity 状态是一些当 Activity 消失时（意味着被回收或进程被杀死）你需要重新恢复屏幕的信息。旋转屏幕是一个最显著的案例，还好我们有 ViewModel。状态保存在 ViewModel 中是安全的。

然而在某些场景中，当 ViewModel 也消失时，你可能也需要恢复状态。比如当操作系统的资源紧缺时，可能会杀死你的进程。

为了高效地保存和恢复 UI 状态，需要结合持续性，onSaveInstanceState() 以及 ViewModels。

看看例子：[ViewModels：持续，onSaveInstanceState()，恢复 UI 状态和装载器](

)

事件

一个事件指发送一次的动作。ViewModels 暴露了数据，但什么是事件呢？例如，导航事件或者展示 Snackbar 消息都是应该只执行一次的动作。

事件的概念并不能很好的展示 LiveData 是如何存储和恢复数据的。来看一下下面的 ViewModel：

LiveData<String> snackbarMessage = new MutableLiveData<>();

一个 Activity 开始观察这个数据，并且 ViewModel 完成了一个操作之后它需要更新这条消息：

snackbarMessage.setValue("Item saved!");

Activity 收到这条消息，并展示在 Snackbar 中。这显然没毛病。

然而，如果用户旋转手机，创建了新的 Activity 并开始观察。当 LiveData 观察发生后，Activity 立即收到了旧的值，这时消息再次展示了！

我们扩展了 LiveData，并创建了一个类叫 [SingleLiveEvent](

)，作为刚刚问题的解决方案。它仅仅发送订阅之后出现的更新。注意它只支持一个观察者。

? 为像导航或 Snackbar 消息等事件使用可观察的行为如 _[SingleLiveEvent](

)。_

泄露 ViewModels

反应式范例在 Android 中工作得很好，因为它允许在 UI 和应用的其他层次建立方便的连接。LiveData 是这个结构中的关键组件，因此通常情况下你的 Activities 和 Fragments 都会观察一个 LiveData 实例。

ViewModels 和其他组件是如何沟通的取决于你，但要注意泄露和边界情况。下图中展示层使用了观察者模式，数据层使用了回调：

如果用户退出了应用，View 将会消失，因此 ViewModel 不再被观察。如果仓库是一个单例，或者应用范围的，那么仓库将不会回收直到进程被杀死。这只会在操作系统需要资源或者用户手动杀死应用时才会发生。如果仓库保留了 ViewModel 中回调的引用，那么 ViewModel 就会暂时泄露。

如果 ViewModel 存活或者被分配的操作很快就完成了，那么这个泄露没什么。然而，不是所有的时候都这样。理想情况下，ViewModels 应该在没有任何 Views 观察它们时回收：

你可以采取以下选项来达到这个目的：

• 使用 ViewModel.onCleared() 你可以告诉仓库扔掉 ViewModel 的回调。

• 在仓库中你可以使用弱引用或者 EventBus（这两者都容易滥用甚至有害）

? 考虑边界情况，泄露以及长时间的操作如何影响你架构中的实例。

? 不要把保存清除状态或者相关的关键逻辑放在 ViewModel 中。任何你从 ViewModel 中的调用都可能是最后一次。

在仓库中的 LiveData

为了避免 ViewModels 的泄露和回调地狱，仓库可以这样观察：

当 ViewModel 被清除时或者当 View 的生命周期结束时，订阅也被清除了：

如果用这种方式的话有个 catch：如果你不访问 LifecycleOwner，那么你怎么从仓库订阅 ViewModel 呢？使用 [Transformations](

) 可以很方便地解决这个问题。Transformations.switchMap 让你可以创建一个新的 LiveData，可以对其他 LiveData 实例做出反应。它也同样允许你通过链来携带观察者的生命周期信息：

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

在这个例子中，当触发更新时，函数就会被调用并将结果向下分发。一个 Activity 可以观察 repo 并且随着repository.loadRepo(id) 的调用相同的 LifecycleOwner 会被使用。

? 无论何时，当你考虑在 [ViewModel](

) 中使用 [生命周期](

)_对象时，[Transformation](

) 都可能是个解决方案。_

继承 LiveData

LiveData 最普遍的用例就是在 ViewModels 中使用MutableLiveData 并且将它们作为 LiveData 暴露出去，使得它们在其他观察者中不可改变。

如果你需要更多功能，继承 LiveData 可以让你知道何时观察者正在活动。当你想要开始监听

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

定位或者传感器服务时这将会很有用。例如：

public class MyLiveData extends LiveData<MyData> {

public MyLiveData(Context context) {// Initialize service}

@Overrideprotected void onActive() {// Start listening}