深入浅出，详解LiveData的这些事 _LiveData

文章插图

引言关于LiveData,在2022尾声的今天，从事 Android 开发的小伙伴一定不会陌生。相应的，关于 LiveData 解析与使用的文章更是数不胜数，其中不乏优秀的创作者，在众多的文章以及前辈面前，本篇也不敢妄谈能写的多么深入,易懂。
本篇主要想着重聊聊 LiveData 的实现思想，以及与之相关联的一些问题,试着从另一角度告诉你这些答案，或者说是个人的浅薄理解。
在我的认知里，如果你了解完这些，那么对于 LiveData ,我想就也就不会再有疑问 :)
在阅读本文前，建议读者有以下前置知识储备：

熟悉并会使用 LiveData；理解 Lifecycle 的设计；

导航本篇将从以下几个方面解析 LiveData:

LiveData 简要快析;
LiveData 源码简析；
LiveData 设计思想；
LiveData 与 Lifecycle 的关联；
LiveData 用作事件通知时的隐患；
LiveData 与 EventBus 的区别是什么；
LiveData 和 Flow 我该怎么选；

好了，让我们开始吧!

LiveData简要快析在官方的描述中， LiveData 如下所示：

LiveData 是一种可观察的数据存储器类。与常规的可观察类不同， LiveData 具有生命周期感知能力，意指它遵循其他应用组件（如 activity、fragment 或 service）的生命周期。这种感知能力可确保 LiveData 仅更新处于活跃生命周期状态的应用组件观察者。

说简单就是 LiveData 是一个可观察的数据存储类,内部借助了 Lifecycle,从而实现了生命周期感知，同时，这个可观察指的是，在其存储的数据更新时，它会去通知观察者。又因为生命周期感知的存在，所以可以做到何时通知、何时解绑，从而做到安全无泄漏,就是如此:)
LiveData与Lifecycle的关联说一句比较夸大的话，没有 Lifecycle,自然也不会存在 LiveData,或者说应该改名为 ObserveData 。LiveData 作为作为生命感知型组件一部分，自诞生之初其，就离不开 Lifecycle 这个基石。
而 LiveData 规定了，当我们开发者订阅数据通知(调用observe())时，必须传递相应的 lifecycle 对象，其内部自然就是为了注册相应的观察者，从而做到生命周期感知，不然它怎么能自己解绑呢？
当我们的观察者生命周期处于 STARTD 或者 RESUMED 状态， LiveData就会认为当前观察者处于活跃状态，此时就会触发相应的更新通知，而非活跃的观察者自然不会收到通知。也正是因为 Lifecycle 的原因，所以 LiveData 做到了自动解绑，从而避免内存泄漏。
关于 Lifecycle ,这里也顺便再提一下：

说到Lifecycle,在sdk26以后， Lifecycle已经被写入了我们 Androidx 基础组件，默认会在 ComponentActivity 及 Fragmeent 中初始化,并且支持开发者自行调用lifecycle 对象，从而添加相应的生命周期观察者，从而免除模版代码。相应的， Lifecycle 将生命周期划分为了如下几个阶段：
【深入浅出，详解LiveData的这些事】DESTROYEDINITIALIZEDCREATEDSTARTEDRESUMED
这几个阶段与我们开发者其实并不相关，开发者往往关注的是其对应的Event 。即 Lifecycle 将生命周期划分为多个状态，当生命周期改变时，就会触发生命周期事件通知(比如 onResume() 等) ，从而同步当前的状态，而状态相当于一个事件集，其代表了当前 lifecycle 的状态，从而不拘泥于现在 Event 到底处于什么。

LiveData设计思想其实，要理解 LiveData 的设计思想，最简单的方式就是手动实现一遍，所以本小节将完整叙述一遍 LiveData 的整体设计流程。‍