在今年（2021 年）的 Google I/O 大会中的 Jetpack Q&A 环节，Android 团队被问了一个很有意思的问题：LiveData 是要被废弃了吗？
问题不是瞎问的
大家好，我是扔物线朱凯。今天来聊个轻松的，不那么硬核的——LiveData。
LiveData 是 Android 官方在 2017 年推出的一系列架构组件中的一个，跟它一起的还有 ViewModel 和 Lifecycle 等等，以及这几年陆续出现的一个个新成员。这些组件后来有了统一的名字：Jetpack；而 Jetpack 的各个组件也越来越被 Android 开发者接受。LiveData 作为 Jetpack 的架构组件的元老级成员，发展势头也一直不错，可是——它从今往后要开始往下走了。就像你在视频开头看到的，有人问 Android 团队「你们是要废弃 LiveData 了吗？」这个问题可不是瞎问的。
那是咋问的呢？这还得从当年的 RxJava 说起。
从 RxJava 说起
LiveData 在 2017 年刚一面世，就受到了很大的关注，其中一个原因是它让很多人想到了 RxJava。LiveData 是一个以观察者模式为核心，通过让界面对变量进行订阅来实现自动通知刷新的组件，而 RxJava 最核心的关键词就是观察者模式和事件流，所以当时很多人拿它去和 RxJava 做比较：有人说它比 RxJava 好用，有人说它没有 RxJava 强大，还有人说它俩根本就不是一个东西，放在一起比较是没有意义的。
至于我的观点嘛……这就说。
RxJava 是在 2014、2015 年这个时间火起来的，国内晚一些，大概在 2016 年开始爆火。当时全世界的劳动人民用 RxJava 一般是做两件事：网络请求，以及 event bus。网络请求这个就不用说了，RxJava 配合 Retrofit 来做网络请求，各种复杂操作和线程切换，谁用谁知道——现在用协程就可以了，比 RxJava 方便；而 event bus，当时比较火的是两个开源库：GreenRobot 的 EventBus——同名库——，和 Square 的 Otto，在 RxJava 流行起来之后，大家发现，哎，这 RxJava 稍微定制一下也能实现 event bus 的功能啊？那既然我都用 RxJava 了，我为啥不把 event bus 也交给它做？就这样，一种叫做 RxBus 的模式就流行了起来，后来也有人开源了这样的库。
就在这样的时代背景下，LiveData 在 2017 年发布了。它的功能是让变量可以被订阅。跟一般的订阅比起来，LiveData 有两个特点：一是它的目标非常直接，直指界面刷新，所以它的数据更新只发生在主线程；二是它借助了另一个架构组件——Lifecycle——的功能，让它可以只在界面到了前台的时候才通知更新，在后台的时候就闷不吭声，避免浪费性能，也避免了 bug。
为什么不用 RxJava？
很方便，很好用。但是这里就会有一个问题：变量的订阅，用 RxJava 不能做吗？为什么要搞一个新库出来呢？RxJava 就是专门做事件订阅的呀？
- 是因为…… LiveData 的数据更新发生在主线程？RxJava 也可以啊，一个操作符的事（
observeOn(AndroidSchedulers.MainThread))），安排。 - 那……是因为它结合了 Lifecycle，对生命周期的支持比较到位？RxJava 也可以啊，改吧改吧就能支持了，总比写一个新库容易吧？
所以 LiveData 的功能，用 RxJava 可以实现吗？是完全可以的，没有任何问题。那 Android 官方为什么要做一个 LiveData 出来，而不是直接推荐大家去用 RxJava 来实现这样的功能？或者退一步，用 RxJava 来做 LiveData 的底层实现也行啊？为什么都没有？——因为 RxJava 太大了，而且它还不是 Android 自己官方的东西，而是别人的。
这个倒不是说 Google 小心眼子，只许宣传我自己的东西，不许壮大别人，而是 Android 作为一个平台方，它肯定要考虑开发者们的普遍水平的。RxJava 说实话虽然好用，但是太复杂了，上手成本忒高，所以如果 Android 要用 RxJava 来实现 LiveData，或者推荐开发者们用 RxJava 来自己实现 LiveData 的功能，那么它就需要考虑怎么让我们开发者学会 RxJava。怎么让我们学会？就只能自己教呗！写文档、出视频，教大家用 RxJava。那这个动作就有点大了，就把事情变复杂了。再加上 RxJava 还既不是 Android 体系里的东西，也不是 Google 体系里的东西，那么如果 Android 团队就为了一个 LiveData 的功能要去全网推广和教学 RxJava，这个逻辑就有点不对了，事情不是这么玩的。所以 RxJava 太大了，并且是第三方的，这两个原因结合起来，就让 Android 的 LiveData 没有使用 RxJava。这并不是一个竞争或胸怀的问题，而是一个「不要把事情变复杂」的问题。——当然这是我自己的观点啊。
2017 - 2021 的变化
但！这只是当时的情况。当时是什么时候？2017 年。2017 是 Android 的大年，这一年发生了好几件大事：
- 官方发布了几个架构组件；
- 官方宣布对 Kotlin 的支持；
HenCoder 发布（假）。
HenCoder 是我乱讲的啊。我要说的是 Kotlin，Kotlin 在 2017 得到了 Android 官方的公开支持，在接下来这几年里，Kotlin 自身越来越完善，它的协程也越来越完善。2017 年之前，事件订阅大部分人是用 EventBus 或者 Otto，并且在 RxJava 流行起来之后，EventBus 和 Otto 的使用开始持续下降；2017 之后，对于简单场景大家慢慢过渡到了 LiveData，复杂场景还在用 RxJava，因为 LiveData 不适合复杂场景；而现在，我们有了 Flow。协程的 Flow 和 RxJava 的功能范围非常相似——其实我觉得就是一样的——但是 Flow 是协程里必不可少的一部分，而协程是 Kotlin 里必不可少的一部分，而 Kotlin 是 Android 开发里必不可少的一部分——哦这个说的不对，重新说——而 Kotlin 又是 Android 现在主推的开发语言以及未来的趋势，这样的话，Flow 一出来，那就没 LiveData 什么事了。别说 LiveData 了，以后 RxJava 也没什么事了。不过这个肯定需要一个过程的，LiveData 和 RxJava——尤其是 RxJava——肯定会继续坚挺一段时间的，只是趋势会是这么一个趋势。
「不会废弃 LiveData」……吗？
视频（文章）开头那个问题，Yigit 的回答是：LiveData 不会被废弃，因为两个原因：
- 用 Java 写 Android 的人还需要它——Flow 是协程的东西，所以如果你是用 Java 的，那其实没办法用 Flow；
- LiveData 的使用比较简单，而且功能上对于简单场景也是足够的，而 RxJava 和 Flow 这种东西学起来就没 LiveData 那么直观。
简单说就是，为了 Java 语言的使用者和不想学 RxJava 或者 Flow 的人，LiveData 会被保留。不过你如果用发展的眼光去看他这番话……你懂我意思吧？
那我走？
那……对于不会 LiveData 的人，还有必要学 LiveData 吗？以及已经在用 LiveData 的项目，需要快点移除 LiveData 吗？
如果你不会 LiveData，对于当下（2021 年）来说，还是很有必要学一下的，因为 LiveData 现在的应用率还是很高的，所以你就算你现在不用，你未来工作的团队也可能会用，反正这东西很简单，学一下不费事。另一方面，在用 LiveData 的人，确实可以考虑摘除它了；但也不是着急忙慌地把它拿走，它不是毒药不是地雷，只是协程的 Flow 现在可以做这件事了，而未来 Flow 一定是会成为主流的，就像现在的 Kotlin 一样；在项目里用两样东西来做同一件事（事件订阅）不如只用一样，因此你可以考虑摘除 LiveData，是这么个逻辑。所以你就算是着急，也应该去着急学 Flow，而不是着急地把 LiveData 拆掉，它没有毒，等以后你觉得它给你带来不方便了，你自然会把它拆掉。
好，今天就是这样，如果你喜欢我的内容，别忘了点赞订阅关注。我是扔物线，我不和你比高低，我只助你成长，我们下期见。
