响应式编程在Android-中的一些探索

1. 响应式编程思想
2. 响应式的实现手段：订阅发布模式、LiveData、RxJava
3. 响应式的应用：MVVM、事件总线
4. 总结

1.响应式编程思想

概念：响应式编程是一种通过异步和数据流来构建事物关系的编程模型。

如何更加通俗易懂的理解？

其实我们的业务开发中本身蕴含着各种各样的事物关系，以加载一个列表为例，列表数据为空时展示怎样的界面，列表有数据时如何展示，数据加载失败时怎么展示，这就是列表数据与列表界面之间的事物关系。

而我们通常编码模式，“人”在其中扮演了过重的角色，我们既要负责去取数据，取完数据还要负责把数据传送给界面展示，操碎了心。某种意义上这是一种顺序性思维的编程，我要做什么，然后做什么，最后做什么，按部就班编写就好了。具体如下图：

而响应式编程，则从一开始就明确构建了事物与事物之间的关系，解脱了"人"，之后一个事物发生变化另一个事物就自动响应。提前构建好事物与事物之间的关系，减轻"人"的角色。画个图，如下：

2.实现响应式的手段

上面说的响应式主要还是一种编程思想，而如何来实现这样一种思想呢？当然订阅发布模式是基础，而像RxJava、LiveData等的出现，让响应式编程的实现手段变得更加的丰富。

一. 订阅发布模式

订阅发布模式是实现响应式的基础，这种模式我们都很熟悉了，主要是通过把观察者的回调注册进被观察者来实现二者的订阅关系，当被观察者notify的时候，则所有的观察就会自动响应。这种模式也实现了观察者和被观察者的解耦。

二.LiveData

LiveData是google发布的lifecycle-aware components中的一个组件，除了能实现数据和View的绑定响应之外，它最大的特点就是具备生命周期感知功能，这使得他具备以下几个优点：

• 解决内存泄漏问题。由于LiveData会在Activity/Fragment等具有生命周期的lifecycleOwner onDestory的时候自动解绑，所以解决了可能存在的内存泄漏问题。之前我们为了避免这个问题，一般有注册绑定的地方都要解绑，而LiveData利用生命周期感知功能解决了这一问题。
• 解决常见的View空异常。我们通常在一个异步任务回来后需要更新View，而此时页面可能已经被回收，导致经常会出现View空异常，而LiveData由于具备生命周期感知功能，在界面可见的时候才会进行响应，如界面更新等，如果在界面不可见的时候发起notify，会等到界面可见的时候才进行响应更新。所以就很好的解决了空异常的问题。

LiveData的实现上可以说是订阅发布模式+生命周期感知,对于Activity/Fragment等LifecycleOwner来说LiveData是观察者，监听者生命周期，而同时LiveData又是被观察者，我们通过观察LiveData，实现数据和View的关系构建。

LiveData是粘性的,这是你在使用前需要知道的，以免因为粘性造成一些问题，使用EventBus的时候我们知道有一种事件模式是粘性的，特点就是消息可以在observer注册之前发送，当observer注册时，依然可接收到之前发送的这个消息。而LiveData天生就是粘性的，下面会讲解为什么他是粘性的，以及如果在一些业务场景上不想要LiveData是粘性的该怎么做。

LiveData的实现原理

单纯的贴源码，分析源码可能比较枯燥，所以下面就尽量以抛出问题，然后解答的方式来解析LiveData的原理。

1.LiveData是如何做到感知Activity/Fragment的生命周期？

lifecycle-aware compents的核心就是生命周期感知，要明白LiveData为什么能感知生命周期，就要知道Google的这套生命周期感知背后的原理是什么，下面是我基于之前lifeycycle这套东西刚出来时候对源码进行的一个分析总结（现在的最新代码可能和之前有点出入，但是原理上基本是一样的）：

首先Activity/Fragment是LifecycleOwner（26.1.0以上的support包中Activity已经默认实现了LifecycleOwner接口）,内部都会有一个LifecycleRegistry存放生命周期State、Event等。而真正核心的操作是，每个Activity/Fragment在启动时都会自动添加进来一个Headless Fragment(无界面的Fragment)，由于添加进来的Fragment与Activity的生命周期是同步的，所以当Activity执行相应生命周期方法的时候，同步的也会执行Headless Fragment的生命周期方法，由于这个这个Headless Fragment对我们开发者来说是隐藏的，它会在执行自己生命周期方法的时候更新Activity的LifecycleRegistry里的生命周期State、Event, 并且notifyStateChanged来通知监听Activity生命周期的观察者。这样就到达了生命周期感知的功能，所以其实是一个隐藏的Headless Fragment来实现了监听者能感知到Activity的生命周期。

基于这套原理，只要LiveData注册了对Activity/Fragment的生命周期监听，也就拥有了感知生命周期的能力。从LiveData的源码里体现如下：

@MainThread
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer observer) {

owner.getLifecycle().addObserver(wrapper);//注册对Activity/Fragment生命周期的监听
}

下面附一张当时对Google lifecycle-aware原理进行源码分析随手画的图：

所以到这里我们基本上已经知道了生命周期感知这套东西的原理，接下来我们就可以来看看LiveData的实现原理了，下我把LiveData的源码抽象为一张流程图来展示，下面的其他问题都可以在这张图中找到答案：

可以看到，在LiveData所依附的Activity/Fragment生命周期发生改变或者通过setValue()改变LiveData数据的时候都会触发notify，但是触发后，真正要走到最终的响应（即我们注册进去的onChanged()回调）则中间要经历很多判断条件，这也是为什么LiveData能具有自己那些特点的原因.

2.LiveData为什么可以避免内存泄漏？

通过上面，我们可以知道，当Activity/Fragment的生命周期发生改变时，LiveData中的监听都会被回调，所以避免内存泄漏就变得十分简单，可以看上图，当LiveData监听到Activity onDestory时则removeObserve,使自己与观察者自动解绑。这样就避免了内存泄漏。 源码上体现如下：

@Override
public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
if (mOwner.getLifecycle().getCurrentState() == DESTROYED) {
removeObserver(mObserver);
return;
}
activeStateChanged(shouldBeActive());
}

3.LiveData为什么可以解决View空异常问题？

这个问题很简单，看上图，因为LiveData响应（比如更新界面操作View）只会在界面可见的时候，如果当前见面不可见，则会延迟到界面可见的时候再响应，所以自然就不会有View空异常的问题了。

那么LiveData是如何实现:

1. 只在界面可见的时候才响应的
2. 如果当前界面不可见，则会延迟到界面可见的时候再响应

关于问题1，因为LiveData是能感知到生命周期的，所以在它回调响应的时候会加一个额外的条件，就是当前的生命周期必须是可见状态的，才会继续执行响应，源码如下：

private void considerNotify(ObserverWrapper observer) {
//如果界面不可见，则不进行响应
if (!observer.mActive) {
return;
}
if (!observer.shouldBeActive()) {
observer.activeStateChanged(false);
return;
}
//如果mVersion不大于mLastVersion,说明数据没有发生变化，则不进行响应
if (observer.mLastVersion >= mVersion) {
return;
}
observer.mLastVersion = mVersion;
//noinspection unchecked
observer.mObserver.onChanged((T) mData);
}

@Override
boolean shouldBeActive() {
return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
}

关于问题2，在LiveData中有一个全局变量mVersion，而每个observer中有一个变量mLastVersion。当我们每次setValue()修改一次LiveData的值的时候，全局的mVersion就会+1，这样mVersion就大于mLastVersion：

@MainThread
protected void setValue(T value) {
assertMainThread(“setValue”);
mVersion++;
mData = value;
dispatchingValue(null);
}

而当界面重新可见的时候，只要判断到mVersion大于mLastVersion，则就会进行响应刷新View，响应后才会更新mLastVersion=mVersion。

4.LiveData为什么是粘性的？

所谓粘性，也就是说消息在订阅之前发布了，订阅之后依然可以接受到这个消息，像EventBus实现粘性的原理是，把发布的粘性事件暂时存在全局的集合里，之后当发生订阅的那一刻，遍历集合，将事件拿出来执行。

而LiveData之所以本身就是粘性的，结合上面的原理图我们来分析一下，比如有一个数据（LiveData）在A页面setValue()之后，则该数据（LiveData）中的全局mVersion+1,也就标志着数据版本改变，然后再从A页面打开B页面，在B页面中开始订阅该LiveData,由于刚订阅的时候内部的数据版本都是从-1开始，此时内部的数据版本就和该LiveData全局的数据版本mVersion不一致，根据上面的原理图，B页面打开的时候生命周期方法一执行，则会进行notify，此时又同时满足页面是从不可见变为可见、数据版本不一致等条件，所以一进B页面，B页面的订阅就会被响应一次。这就是所谓的粘性，A页面在发消息的时候B页面是还没创建还没订阅该数据的，但是一进入B页面一订阅，之前在A中发的消息就会被响应。

那么有些业务场景我们是不想要这种粘性的，我们希望只有当我们订阅了该数据之后，该数据的改变才通知我们，通过上面的分析，这一点应该还是比较好办到的，只要我们订阅的时候将全局的mVersion同步到内部的数据版本，这样订阅时候就不会出现内部数据版本与全局的mVersion不一致，也就去除了粘性。我这里自定义了一个可以控制是否需要粘性的LiveData。

具体代码见： CustomStickyLiveData

三. RxJava

RxJava是可以实现响应式编程的另外一个手段，Rxjava也是热度非常高的一个开源库，当然我们都知道RxJava一个是有订阅发布模式解耦的优点，还有其线程模型、链式写法都是其优点。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

最后

题外话，我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在IT学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多程序员朋友无法获得正确的资料得到学习提升，故此将并将重要的Android进阶资料包括自定义view、性能优化、MVC与MVP与MVVM三大框架的区别、NDK技术、阿里面试题精编汇总、常见源码分析等学习资料。

【Android思维脑图（技能树）】

知识不体系？这里还有整理出来的Android进阶学习的思维脑图，给大家参考一个方向。

【Android进阶学习视频】、【全套Android面试秘籍】

希望我能够用我的力量帮助更多迷茫、困惑的朋友们，帮助大家在IT道路上学习和发展

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

7vq-1711948995137)]

【Android进阶学习视频】、【全套Android面试秘籍】

希望我能够用我的力量帮助更多迷茫、困惑的朋友们，帮助大家在IT道路上学习和发展

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！