开发过程中,总会遇到一些需要通信的场景。
如果逻辑比较简单,通过常规的传参,回调,返回值等即可实现。
而如果调用层次较深(如跨模块,跨线程等),光靠传参和回调等手段,耦合度较高,
对于需要主动通知,通知多个组件等场景,更是捉襟见肘。
为解耦事件的发布与订阅主体,简化组件间通信,可引入事件通信机制。
事件通知包含哪些内容?
事件的定义,注册/注销,通知。
事件框架如何实现?
一个接口,一个事件管理类,足矣。
代码不足50行,名副其实的“轻量级”。
方案实现
定义接口
interface Observer {
fun onEvent(event: Int, vararg args : Any?)
fun listEvents(): IntArray
}
接口定义了两个方法:
listEvents: 返回关注的事件;
onEvent: 发生事件时回调此接口并返回事件和参数(可缺省)。
事件管理
object EventManager {
private val HANDLER = Handler(Looper.getMainLooper())
private val OBSERVER_ARRAY = SparseArray<LinkedList<Observer>>(16)
@Synchronized
fun register(observer: Observer?) {
observer?.listEvents()?.forEach { event ->
var observerList = OBSERVER_ARRAY.get(event)
if (observerList == null) {
observerList = LinkedList()
OBSERVER_ARRAY.put(event, observerList)
}
if (observer !in observerList) {
observerList.add(observer)
}
}
}
@Synchronized
fun unregister(observer: Observer?) {
observer?.listEvents()?.forEach { event ->
OBSERVER_ARRAY.get(event)?.removeLastOccurrence(observer)
}
}
@Synchronized
fun notify(event: Int, vararg args: Any?) {
OBSERVER_ARRAY.get(event)?.forEach { observer ->
HANDLER.post { observer.onEvent(event, *args) }
}
}
}
HANDLER:事件通知器,使事件接口统一在UI线程回调;
OBSERVER_ARRAY:关联事件和观察者的容器。
SparseArray> 等价于 Map>,其key为事件, value为关注此事件的观察者。
register: 将Observer放入其所关注的事件对应的list;
notify: 遍历指定事件对应的list, 回调Observer的onEvent()。
如下图所示,将其展开,是一个多对多的十字结构:
简而言之,就是:一个事件可被多个观察者关注,一个观察者可关注多个事件。
使用方法
以一个简单的登录/注销场景为例:
1、定义事件
object Events {
const val LOGIN = 1
const val LOGOUT = 2
}
2、注册/注销
abstract class BaseActivity : AppCompatActivity(), Observer {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
EventManager.register(this)
}
override fun onDestroy() {
super.onDestroy()
EventManager.unregister(this)
}
override fun onEvent(event: Int, vararg args: Any?) {
}
override fun listEvents(): IntArray {
return IntArray(0)
}
}
像 Activity 和 Fragment 这种有固定生命周期的类,可以在Base添加注册和注销代码;
但并非每个子类都需要注册事件,所以可以先实现空方法,需要注册的子类自行重载即可。
3、订阅事件&处理回调
class MainActivity : BaseActivity() {
public override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
val switchAccountBtn: Button = findViewById(R.id.switch_account_btn)
switchAccountBtn.setOnClickListener {
if (!AccountManager.isLogin) {
startActivity(LoginActivity::class.java)
} else {
AccountManager.logout()
}
}
}
private fun setViews(account: String?) {
// update views
}
override fun listEvents(): IntArray {
return intArrayOf(Events.LOGIN, Events.LOGOUT)
}
override fun onEvent(event: Int, vararg args: Any?) {
when (event) {
Events.LOGIN -> setViews(args[0] as String?)
Events.LOGOUT -> setViews(null)
}
}
}
由于事件是在UI线程回调,所以可以直接更新UI;若需要做耗时处理,需要另起线程。
4、发送事件
object AccountManager {
fun login(account: String, password: String) {
// process login
EventManager.notify(Events.LOGIN, account)
}
fun logout() {
// process logout
EventManager.notify(Events.LOGOUT)
}
}
发送事件可以只发送事件,也可以同时携带参数。
参数类型,最初尝试用Bundle, 但是Bundle传参需要封装和拆解;
后来换用vararg,所以可以添加任意参数,使用也相对方便。
原理分析
从各种事件框架,到系统广播,到View的listener回调,思路都是类似的,但有各种不同的形式,从各种各样名字就可见一斑。
其中被对比的最多的是 观察者模式 和 事件监听模式。
若非要分类,该方案应该是后者。
作为对比,我们以 《JAVA与模式》之观察者模式 中介绍的个例子为参考,其类图如下:
其中,Subject为被观察对象,有的地方也用Observable。
被观察对象的状态(state)变化改变时, attach到此对象的观察者的update()会被回调。
前面举例的方案,结构图如下:
两者的共性在于,都是“订阅->通知”的一种模式。
两者的区别在于:一个关注物的变化,一个关注事的发生。
上面的例子中,大概流程如下:
整体还是比较简单的,页面创建时订阅消息,销毁时取消订阅;
从MainActivity到LoginActivity,再到AccountManager, 既跨页面也跨线程,
但由于EventManager持有MainActivity引用,所以可以方便地通知。
不单是Activity, Fragment等UI组件,任何对象都可以通过实现Observer接口成为观察者,然后通过EventManager订阅自己感兴趣的事件。
其他事项
生命周期
引用观察者的是个静态对象,所以观察者生命周期结束时需要确保取消订阅,以免内存泄漏。
如果观察者也是静态对象,则不用取消订阅。
如果不确定对象生命周期结束前是否可以取消订阅,可借助弱应用来防止内存泄漏:
class WeakObserver(target: Observer) : Observer {
private val reference: WeakReference<Observer> = WeakReference(target)
private val events: IntArray = target.listEvents()
override fun onEvent(event: Int, vararg args: Any?) {
reference.get()?.onEvent(event, *args)
}
override fun listEvents(): IntArray {
return events
}
}
WeakObserver和WeakHandle类似,都是通过实现接口以及弱应用来进行包装。
重复检查
当事件定义变多后,有可能一个不小心,事件的value就重复了。
object Events {
const val LOGIN = 1
const val LOGOUT = 2
// ...
const val SOMETHING = 2
}
若重复定义,可能会相互干扰。
为此,可编写单元测试检查事件的value是否重复:
fun testDuplicate() {
val fields = Events::class.java.declaredFields
val events = fields.filter { it.type == Int::class.java }
val eventSet = events.map { it.getInt(Events::class.java) }.toSet()
Assert.assertEquals(events.size, eventSet.size)
}
如上定义, 单元测试会报错:
junit.framework.AssertionFailedError: expected:<3> but was:<2>
查看事件
通过“Find Usages”快捷键,可以查看所有订阅者和事件发送的地方。
结语
说到事件框架,大家可能会想到EventBus。
相比而言,EventBus有粘性事件,可指定回调线程等特性;
而此方案则是轻量,以及清晰的事件管理。
本文主要是介绍事件通信的思想和一些实现技巧,旨在抛砖引入,欢迎各位读者批评指正。
附上演示Demo, 感兴趣的读者可以下载回来Run一下。
github地址: LigntEvent