Android轻量级事件通信方案

开发过程中，总会遇到一些需要通信的场景。
如果逻辑比较简单，通过常规的传参，回调，返回值等即可实现。
而如果调用层次较深(如跨模块，跨线程等)，光靠传参和回调等手段，耦合度较高，
对于需要主动通知，通知多个组件等场景，更是捉襟见肘。
为解耦事件的发布与订阅主体，简化组件间通信，可引入事件通信机制。

事件通知包含哪些内容？
事件的定义，注册/注销，通知。
事件框架如何实现？
一个接口，一个事件管理类，足矣。
代码不足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