手写消息总线LiveDataBus，让你永无后顾之忧

}

####三.步骤二 新建观察者类

final Observer nameObserver = new Observer() {
@Override
public void onChanged(String s) {
nameText.setText(s);
}
};

####四.步骤三 将观察者类传入LiveData

mModel.getCurrentName().observe(this, nameObserver);

注意，这里的mModel.getCuttentName其实就是MutableLiveData对象，这个this就是当前activity的引用，也就是说将当前activity引用传入了observe方法，这个其实就是LiveData能监测到当前Activity生命周期的原因所在，具体怎么监测下面会详细讲到。

####五.步骤四 发送消息给观察者

mModel.getCurrentName().postValue(anotherName);

注意，这里的anotherName是在NameViewModel中设置好的泛型，详见第一步中MutableLiveData的对象获取，指定了anotherName只能传递String过去。另外postValue方法是使用在异步线程中，setValue使用在主线程中，都是发送消息。

• LiveData是如何做到监测页面的生命周期的？

这个就必须从源码着手了，我们首先看一下将Activity传进去的MutableLiveData中的observe方法

发现在这个方法中，将Activity对象和观察者对象传入了LifecycleBoundObserver中，所以我们点进去看一下LifecycleBoundObserver是一个什么样的类，然后它接收到了这2个对象以后都做了一些什么操作

我们看到LifecycleBoundObserver实现了GenericLifecycleObserver，然后GenericLifecycleObserver又继承了LifecycleObserver,而这个类正是系统检测页面生命周期改变相关的类。根据lifecycle的用法，实现了LifecycleObserver并且将观察者传入就可以在生命周期改变时通知该观察者。另外在其中我们发现在onStateChanged中，如果当前页面状态是destroy的话，就移除我们的观察者，这样观察者就收不到回调了。

• LiveData是不是就足够解决业务中的问题了？

根据上面LiveData的基本使用，每更新一个控件就需要定义一个NameViewModel，因为需要不同的LiveData，原因是观察者的接口回调决定的，因为一个LiveData会执行一个onChange方法，但是一次只能带来一个参数，所以不能让所有的控件都获取到想要的值，所以我们必须想办法进行优化，那就是LiveDataBus。

• LiveDataBus应该如何构建？

LiveDataBus其实就是用map保存所有的LiveData,以唯一字符串作为key，在使用的地方进行传入key，获取到map中保存的MutableLiveData

但是，我们接下来做一个尝试，在A页面发送消息给B页面，若此时B页面还没启动。过一段时间后启动B页面还会收到消息，这是不合理的，因为发送消息的时候B页面还没启动，所以那个时候发送的消息不应该被收到。当然这里如果想做得更好可以让使用者进行设置，让自定义的LiveDataBus支持粘性事件，这里可以参考一个第三方的LiveEventBus的实现。这次我们主要讲解一下如何通过hook技术取消这个粘性消息的接收，即在页面未打开时，就算后面打开了也不接收消息。

想要解决这个问题就要从源码入手了，我们首先从调用的源头MutableLiveData类中的setValue开始研究

我们看到，这个setValue其实就是调用了父类LiveData中的setValue，所以我们找到看下

可以看到这里面调用了dispatchingValue，所以我们点进去看看

这里面核心是condiderNotify方法，所以我们当然要进去看看了

最后一行是不是很眼熟？没错，这就是观察者的接口回调方法。大家要是不信可以反过来看也可以，首先到观察者的接口回调方法，然后find useages一样可以看到是这个方法。那么应该如何让这个消息第一次订阅Livedata的时候，这个onChange方法不执行呢？这个就必须用到修改系统代码执行流程的hook技术了。

从上面代码可以看出，上面有3个判断，只要其中有一个判断执行了那么都不会跑到最后的onChange方法，经过详细分析这里最好改的是第三个判断。在第三个判断中只要让observer.mLastVersion >= mVersion就不会执行onChanged了，那么应该如何让这两者符合要求呢？

首先看一下这个mLastVersion和mVersion是在哪里赋值的，先看mLastVersion吧，mLastVersion赋值总共有3个地方，前两个是将mLastVersion赋值成和mVersion相等，这个不用考虑，因为这就是我们想要的结果，最后那一次是赋值成一个变量，而且是在初始化的时候赋值的，这个地方是在private abstract修饰的一个内部类中，没法进行修改。所以我们只能寄希望于mVersion身上了，我们看到mVersion的赋值处第一个是赋值为变量，这个是在LiveData的成员属性中赋值的，在类加载的时候就会创建，这里就算修改也会被mLastVersion复制过去，所以关键不在这里。我们把目标看向mVersion++，没错就是这里打破了二者的平衡，让mVersion+1，最后的结果就是observer.mLastVersion<mVersion，导致那个判断没有进去，最后执行到了onChanged方法。那么这个mVersion++是在哪里执行的呢？这个是在setValue方法中执行的。所以经过分析，我们利用好给为初始化的页面发送消息是先发送后注册这个特点。只需要在判断observer.mLastVersion>=mVersion之前将二者赋值为相等即可，换句话说，我们需要在setValue后的某个地方将这二者赋值为相同即可。


mLastVersion是在observer对象中，而observer对象时considerNotify方法的参数传进来的，而considerNotify方法是在dispatchingValue方法中调用的，进入dispatchingValue中可以看到，实际上传下去的值是mObservers这个map中的值，也就是说我们只需要对当前页面对应的Observer进行修改即可

修改的方式就是反射，首先拿到LiveData中的mObservers这个map，接下来获取到当前页面对应的Observer，然后调用其中的get方法获取到Entry，然后调用set方法将其设置成mVersion的值，实际代码如下

核心原理：当进入一个新页面时，会执行对observers的初始化，其中调用hook方法对mLastVersion进行修改，导致系统流程走不到onChanged方法。当再次发消息时，由于已经初始化过了，所以不会走到hook方法，就是正常流程，mLastVersion值为-1，mVersion执行了++以后值变为了0，这样就会走入onChange方法了，所以可以正常跑起来。

####六.总结：
本节我们分析了很多跨线程、页面通信的方法，总结了它们的优缺点，并且介绍了发布-订阅模式和观察者模式的区别。经过对比很多通信方式我们最终选择了LiveDataBus，并且进行了模仿手写，解决了其中发现的问题。总而言之，LiveDataBus是一个官方支持的高效率、无内存泄漏、简单的优秀通信框架。

手写消息总线LiveDataBus，让你永无后顾之忧
链接: https://pan.baidu.com/s/1P_LYQkBvnhBnHMz4qzRpuQ 提取码: h7ib 复制这段内容后打开百度网盘手机App，操作更方便哦

最后

由于文章篇幅原因，我只把面试题列了出来，详细的答案，我整理成了一份PDF文档，这份文档还包括了还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 ，帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！**