前言
当前市面上, 比较常用的事件总线, 仍然是EventBus
和RxBus
, 早期我曾经写过EventBus源码解析,这两个框架不论是哪个, 开发者都需要去考虑生命周期的处理.而美团给出了个解决方案, 通过LiveData来实现自带生命周期感知能力的事件总线框架. 本篇我们自己撸一个事件总线框架.
LiveData的原理
我们要用LiveData
做事件总线, 总需要知道它是什么, 为什么可以用它来实现事件总线.
LiveData可对数据进行观测, 并具有生命周期感知能力, 这就意味着当liveData只会在生命周期处于活跃(inActive)的状态下才会去执行观测动作, 而他的能力赋予不能脱离LifeCycle的范围.
首先我们可以看下LiveData
的UML图, 便于对他有个大概的理解
这里我们需要注意的是,LiveData
内维护的mVersion
表示的是发送信息的版本,每次发送一次信息, 它都会+1, 而ObserverWrapper
内维护的mLastVersion
为订阅触发的版本号, 当订阅动作生效的时候, 它的版本号会和发送信息的版本号同步.他们初始值都为-1
订阅
LiveData
内部存在一个mObservers
用来保存相关绑定的所有观察者, 通过LiveData#observe
以及LiveData#oberveForever
方法, 我们可以进行订阅动作.如果需要与生命周期绑定, 则需要传入LifecycleOwner
对象, 将我们的LiveData数据观测者(Observer)包装注册到生命周期的观测者中, 得以接收到生命周期的变更, 并做出及时的对应更新活动, 我们可以看下LiveData的订阅的方法代码
1 | 复制代码@MainThread |
针对我们需要监测生命周期的观察者, LiveData
将其包装成了LifecycleBoundObserver
对象, 它继承于ObserverWrapper
, 并最终实现了GenericLifecycleObserver
接口, 通过实现GenericLifecycleObserver#onStateChanged
方法获取到生命周期状态变更事件.
发送信息
LiveData#setValue
和LiveData#postValue
的区别在于一个是在主线程发送信息, 而post是在子线程发送信息, post最终通过指定主线程的Handler执行调用setValue, 所以这里主要看下LiveData#setValue
1 | 复制代码@MainThread |
当调用setValue的时候, 就相当于是LiveData
内部维护的可观测数据发生变化, 则直接触发事件分发
1 | 复制代码void dispatchingValue(@Nullable ObserverWrapper initiator) { |
最终, 会走到considerNotify
方法, 在保证观察者活跃, 并且他的订阅生效数小于发送数的情况下, 最终触发到我们实现的观察方法.
1 | 复制代码private void considerNotify(ObserverWrapper observer) { |
要注意的是, LiveData#dispatchingValue
除了在我们主动更新数据的时候会触发, 在我们的观察者状态变更(inactive->active)的时候, 也会通知到, 这就导致了LiveData
必然支持粘性事件
1 | 复制代码class LifecycleBoundObserver extends ObserverWrapper implements GenericLifecycleObserver { |
原理总结
我们概括下来, 关于LiveData
可以了解如下:
LiveData
的观察者可以联动生命周期, 也可以不联动LiveData
的观察者只能与一个LifecycleOwner
绑定, 否则会抛出异常- 当观察者的active状态变更的时候
- active->inactive : 如果LiveCycler通知OnDestroy, 则移除对应的观察者, 切当所有观察者都非活跃的状态下时, 会触发onInactive
- inactive->active: 会通知观察者最近的数据更新(粘性消息)
- 除了观察者状态变更时, 会接收到数据更新的通知外, 还有一种就是在活跃的情况下, 通过开发者主动更新数据, 会接收到数据更新的通知.
基于LiveData的事件总线的实现
可以看出, LiveData
本身就已经可观测数据更新, 我们通过维护一张eventName-LiveData的哈希表, 就可以得到一个基础的事件总线
1 | 复制代码class LiveDataBus { |
但是除了粘性事件以外, 我们还需要非粘性事件的支持, 这里有两种做法.
美团是根据覆写observe方法, 反射获取ObserverWrapper.mLastVersion
, 在订阅的时候使得初始化的ObserverWrapper.mLastVersion
等于LiveData.mVersion
, 使得粘性消息无法通过实现(详细可以看下参考1的文章内容)
这里我用了另外一种做法,粘性消息最终会调到Observer#onChanged
, 那么我们就干脆将其再进行一层包装, 内部维护实际的订阅消息数, 来判断是否要触发真正的onChanged
方法
1 | 复制代码internal open class ExternalObserverWrapper<T>(val observer: Observer<in T>, val liveData: ExternalLiveData<T>): Observer<T>{ |
我们需要覆写observe方法, 将我们包装的观察者传进去
1 | 复制代码internal class ExternalLiveData<T>(val key: String) : MutableLiveData<T>(){ |
需要注意的是, LiveData维护的观察者集合变为我们包装后的观察者集合后, 那么对应的移除观察者方法, 我们也需要重新包装传入, 并且需要额外维护一份真正的观察者和包装后的观察者的对应hash表对象, 并在观察者被移除的时候删除对应的内存对象, 防止内存泄漏的产生, 最终的代码如下
1 | 复制代码internal class ExternalLiveData<T>(val key: String) : MutableLiveData<T>(){ |
事件的约束
正如美团后期讨论的改进文章内所说, 当前的事件总线(不论是EventBus还是LiveEventBus)都没有对事件进行约束, 假如A同学以”event1”字符串定义事件名并发送事件, 而B同学勿写成”eventl”字符串订阅事件, 那么这个事件就永远都接收不到了. 另外当上游删除发送的事件相关代码, 订阅方也无从感知到.
基于此, 参考了Retrofit针对于请求的动态代理的做法, 将事件的定义由事件总线框架本身通过动态代理去实现
1 | 复制代码class LiveDataBus { |
开发者需要先定义一个事件, 才可以对它进行相关的发送和订阅的工作.
1 | 复制代码interface LiveEvents { |
然后开发者可以通过以下方式去发送和订阅
1 | 复制代码private fun sendEvent(){ |
参考
本文转载自: 掘金