一年时间过去了，LiveData 真的被 Flow 代替了吗? LiveData 会被废弃吗？

作者：编程的平行世界

2022 年 7 月 21 日
本文字数：2820 字
阅读完需：约 9 分钟

前言：在去年的这个时候，谷歌官方推荐使用 Flow 替代 LiveData，一年时间过去了，我相信还是有很多 android 开发的朋友和我一样有以下几个问题：Android 开发人员需要从 LiveData 迁移到 Kotlin Flows 吗？LiveData 现在是否已弃用？

🌟官方文档：https://developer.android.google.cn/kotlin/flow

🌟推荐阅读：https://zhuanlan.zhihu.com/p/139582669

🌟推荐阅读：https://juejin.cn/post/6979008878029570055

通过阅读本文你能了解到或学到什么：

① Flow, Shared flow & State flow的使用(具体操作本文就不多说了，给大家推荐好文)
② SharedFlow 和 StateFlow，它们也有自己的可变类型——MutableSharedFlow 和 MutableStateFlow，对比LiveData我到底用哪一个？
③我们已经有了Flow，为啥还会有SharedFlow、StateFlow，Flow不够用吗？
④我要迁移到Flow吗？

有人问：LiveData 是不是真的快要被废弃了。LiveData：你是故意找茬？

我要迁移到 Flow 吗？

我们先来回答这个大家最关心的问题

🚀结论：如果 LiveData 满足您的需求，那么就不急于替换它，如果是一个新项目，推荐在 UI 中用 LiveData，在 Repo 层中用 Flow。

下面请欣赏RxJava与LiveData&Flow的爱恨情仇：

在 2017 年之前，大家都是使用RxJava去配合Retrofit实现网络请求，RxJava 实现事件订阅。但是，谁用谁知道 (真的复杂，各种线程的切换，头脑爆炸，不过，现在用协程就可以啦😻) 。因为是真的复杂，对大部分开发者不是很友好，于是在 2017 年那样的环境下，谷歌推出了LiveData。但是LiveData的功能却完全可以使用RxJava来实现，那么谷歌为啥还要费那么大劲整这么个库出来呢？当然是因为LiveData比较简单啦~(而且RxJava不是谷歌自己的东西，谷歌：我可不想当大冤种😂)。于是在之后的一段时间中，对于简单场景大家开始使用LiveData了，对于复杂的场景大家还是在使用RxJava。因为LiveData驾驭不了复杂场景啊。(LiveData:我太难了😭)。不过好在，Flow 出现了。Flow：LiveData 老弟别怕，大哥给你撑腰来啦！(其实我来代替你来了，嘿嘿）至今，它们之间的爱恨情仇还在继续.....

引用扔物线（朱凯）大佬的话：协程的 Flow 和 RxJava 的功能范围非常相似——其实我觉得就是一样的——但是 Flow 是协程里必不可少的一部分，而协程是 Kotlin 里必不可少的一部分，而 Kotlin 是 Android 开发里必不可少的一部分——哦这个说的不对，重新说——而 Kotlin 又是 Android 现在主推的开发语言以及未来的趋势，这样的话，Flow 一出来，那就没 LiveData 什么事了。别说 LiveData 了，以后 RxJava 也没什么事了。

LiveData 会被废弃吗？

LiveData会因为Flow而被废弃吗？虽然官方一直在推荐使用Flow代替LiveData，但是在 GDG 的社区中的答案和多位国内外的 GDE 口中的答案是：不会被废弃！

原因有两点：

在简单的场景下使用LiveData已经够了，而且LiveData比较简单，上手快，RxJava学习成本真的很高😭，Flow也相对没有那么简单。
Flow 是协程的东西，如果你用的是Java来开发Android，那么你没有办法使用Flow。而且现在招聘平台至少有 50%以上的 Android 岗位还在使用 Java，所以LiveData不会被废弃!

总结：如果不需要使用到 Kotlin 数据流的强大功能，就用 LiveData。Flow是比LiveData更好，但是在特定的场景下LiveData更合适！

SharedFlow 和 StateFlow，对比 LiveData 我到底用哪一个？

核心：LiveData 适用于 MVVM，但不适用于 MVI

在MVI中，View通过触发事件与ViewModel通信，然后在ViewModel的内部处理完这些事件后，发出新的 ViewState 并更新 UI。而且使用LiveData处理视图状态非常简单，可以同时用于MVVM和MVI，但是当我们想要像以前一样显示一个简单的Snackbar时问题就来了。如果我们使用LiveEvent类，那么整个单向状态流就会受到干扰，因为我们只是在ViewModel中触发了一个事件来与UI交互，但它应该是相反的。而使用StateFlow和SharedFlow则可以解决这个问题。

StateFlow 和 LiveData 有相似之处，两者都是可观察的数据持有者类，它们的不同在于StateFlow需要将初始状态传递给构造函数，而 LiveData 不需要。当视图进入 STOPPED 状态时，LiveData.observe() 会自动取消注册消费者，而 StateFlow不会自动停止收集。如果想要实现相同的功能的话，需要在Lifecycle.repeatOnLifecycle中收集流。

SharedFlow 和 StateFlow 之间的主要区别在于，StateFlow 通过构造函数获取一个默认值，并在有人开始收集时便立即发出，而 SharedFlow 不接受任何值，默认情况下什么也不发出。

我们已经有了 Flow，为啥还会有 SharedFlow、StateFlow。Flow 不够用吗？

StateFlow 和 SharedFlow 是 Flow API，它们使流能够以最佳的方式发出状态更新，并向多个消费者发出消息。

单单一个 Flow 当然是不够的啦

Flow是无状态的，它没有 .value 属性。它只是一个可以收集的数据流。
Flow是声明性的（冷流）。它仅在收集时实现，并且对于每个新收集器都会创建一个新流。对于访问数据库和其他不必每次都重复的操作，这不是一个好的选择。
Flow本来是不知道Android的生命周期，但是后来可以通过向LifecycleCoroutineScope添加扩展方法launchWhenStarted来解决，但大多数人不知道如何正确使用它。而且因为Flow有一个订阅计数属性，当Lifecycle.Event达到ON_STOP时该属性不会改变。这意味着Flow将在内存中仍然处于活动状态，就会可能导致内存泄漏！