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

做了很久的面试专题，不知道对各位需要面试和有跳槽想法的小伙伴有没有帮助，今天收集一篇关于LiveDataBus方面的文章，面试方面的收集，后续我还会持续更新如果觉得有用可以点个关注

Android四大组件和线程间通信方式有很多，比如Handler管道、广播、接口回调、rxBus、EventBus等，但是这些方式都存在一些瑕疵，（比如EvebtBus可能现在用的人比较少了，个人见解可以能算半个过时性的~个人见解不喜勿喷)具体的优缺点如下：

那么有没有一种通信方式可以集以上所有框架的优点于一身，并且避免以上缺点呢？答案就是作者今天要分享的livedatabus，livedatabus是基于原生的livedata实现的通信框架，它拥有以下的优点：

首先我们来看一下LiveDataBus的整体架构，消息总线用来保存所有的消息通道，然后订阅者订阅其中任意的通道，发布者向通道发布消息

一.LiveDataBus核心原理是什么？

LiveDataBus原理其实就是发布-订阅模式+liveData，接下来作者会一一道来。首先说说发布-订阅模式，这个模式和观察者模式有些类似，甚至在有的设计模式书籍里也认为这2个模式是等同的。我个人觉得仔细分析的话还是有一些不同的地方，最大的地方在于在观察者模式中观察者和被观察者是互相知道对方的，但是发布-订阅模式中订阅者并不知道发布者是谁。所以在需要对二者进行解耦时最好使用发布-订阅模式，发布者不需要知道订阅者的存在，二者只是共用一个信息通道。一般是在单线程中使用观察者模式，但是如果是在不同线程中通信就用发布-订阅模式会更适合。观察者模式和发布-订阅者模式对比

观察者模式：

发布-订阅者模式：

在客车里乘客相当于观察者，上车时乘务员通过买票知道了每位乘客到站信息，所以乘客只需要时刻观察乘务员的指示，当到站点时乘务员会给出当面指示，到站点的乘客可以根据乘务员的当面提示执行下车操作。但是在火车上乘务员不可能一个一个人去通知到站，只能通过发送广播的方式，而且乘客并不知道是哪个乘务员发送的广播。接下来说说LiveData，

首先看一下LiveData的定义：

LiveData是一个数据持有类，持有数据并且这个数据可以被观察被监听，和其他Observable(被观察者)不同的是，它是和Lifecycle绑定的，在生命周期内使用有效，减少内存泄漏和引用问题。

适合的使用场景这里举个例子，我们通过网络下载数据需要耗时一般放在子线程中，但是并不知道什么时候会下载完成，如果我们不使用LiveData，那么就有可能出现等数据回来时主线程的界面已经被销毁的情况，这样就有可能出现问题了。这里如果使用LiveData，就不需要管数据什么时候回来，回来后界面是否存在了，因为LiveData是自带生命周期监测的。接下来我们来简单使用一下

二.LiveData步骤一 获取MutableLiveData对象

NameViewModel mModel = ViewModelProviders.of(this).get(NameViewModel.class);

这个获取方式比较奇怪，首先NameViewModel是我们的一个自定义类，内容非常简单，就是获取到了一个系统的MutableLiveData对象而已，不过需要注意的是这个类一定要继承ViewModel，不然是要报错的，获取不到MutableLiveData，具体代码如下：

public class NameViewModel extends ViewModel {    
       private MutableLiveData mCurrentName;    
       public MutableLiveData getCurrentName() {        
              if (mCurrentName == null) {            
                       mCurrentName = new MutableLiveData<>();        
              }       
               return mCurrentName;    
       }
}

三.步骤二 新建观察者类

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是一个官方支持的高效率、无内存泄漏、简单的优秀通信框架。