0x1、引言
EventBus(事件总线)，跟之前写的 Handler 一样，老生常谈，教程早已烂大街，面试官偶尔会让你：
官方仓库 greenrobot/EventBus 看下Commit记录，最早可追溯到2012.7，作者大大已经好几年没有大的代码更新了，可能是库已趋于稳定 + 有其他更好的替代品(LiveData、Rx)。
写 把书读薄 | 《设计模式之美》设计模式与范式（行为型-观察者模式） 时，顺带过了一下它的大体源码，了解了初始化、订阅、取消订阅、发送普通事件、发送粘性事件的 大概调用流程和原理。但总感觉并没完全参透，想再仔细地摸索下，遂有此文，记录自己摸索着实现EventBus的过程。在此之前，我们先过一过没有EventBus前是如何处理数据传递问题的。
0x2、套娃 → 最原始的页面数据传递
最原始的页面数据传递
可以把Android页面笼统地分为两类：Activity 和 Fragment，数据传递还包括 数据回传，常见的三种传递如下：
① Activity <=> Activity
简单场景：
/* ====== 单向传递 ====== */ // OriginActivity 给 TargetActivity传递数据 val intent = Intent(this, TargetActivity::class.java) intent.putExtra("info", "Some Data") startActivity(intent) // TargetActivity 解析 OriginActivity 传递过来的数据 val data = getIntent().getStringExtra("info") /* ====== 数据回传 ====== */ // 传递Intent实例的同时，传递请求码 startActivityForResult(intent, 0x123) // OriginActivity重写此方法，在此解析回传数据，TargetActivity销毁时会回调此方法 override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) { super.onActivityResult(requestCode, resultCode, data) if (requestCode == 0x123) { val backData = intent?.getStringExtra("back_info") } } // TargetActivity 在finish()前调用此方法设置回传数据： setResult(0x123, Intent().putExtra("back_info", "Some Back Data")) finish()
来点复杂点的场景，如这样的页面打开顺序：A → B → C → D，然后有下面这样的需求：
- ① 在A里执行了一个耗时操作，执行完后，通知D做页面刷新：
解法：D采用singleTask模式，A要传参直接 startActivity(intent)，D重写 onNewIntent(intent) 对传递过来的数据进行解析。
- ② D回传数据给A
直接回传给A，A得用 startActivityForResult(intent)，但用了它会导致 singleTask启动模式 失效，创建多一个新的D，只能用③里的套娃解法；
如果是D只能有一个的场景，就有些尴尬了...在说说另一个常见的场景：注册填写资料流程
- ③ 假设A是登录页，BCD是填写资料页，D填完后点击完成，关闭DCB，同时把注册信息传递给A
解法：startActivityForResult(intent) 套娃，D把信息传给C，C传给B，B再传给A
- ④ 再来个奇葩场景，D先传信息给B，让其 finish()，然后再调起一个新的B，此时的Activity栈：A → C → D → B
闲着无聊的童鞋可以向下怎么搞？真实的故事，不要怀疑产品经理的脑洞！接着到Activity和Fragment的数据传递。
② Activity <=> Fragment
// Fragment未添加到FragmentManger前 TargetFragment targetFragment = TargetFragment() targetFragment.setArguments(Intent()) supportFragmentManager.beginTransaction().add(targetFragment, "TargetFragment").commit() // 已添加到FragmentManager中 // ① 接口回调，Fragment实现接口，Activity调用对应回调传入数据； // ② Fragment定义公共方法，Activity直接通过Fragment实例调用方法传入； // 数据回传Activity // ① 接口回调，Activity实现接口，Fragment调用对应回调回传； // ② Activity定义公共方法，Fragment获取getActivity()获取Activity实例，类型强转，调用此方法传入；
上述是Fragment与 宿主Activity 的数据传递，与非宿主Activity的数据传递，则是在宿主Activity与非宿主Activity上再套一层，这样明显暴露了耦合的问题。而且 宿主Activity的任务太重了 ，既要处理Activity间的数据传递问题，又要处理子Fragment的数据传递问题。
③ Fragment <=> Fragment
同宿主Activity
- 目标Fragment中定义设置数据的方法，发起Fragment调用
getActivity().getSupportFragmentManager().findFragmentByTag() + 强转获取目标Fragment实例，然后调用设置数据的方法；
- 接口回调 → 定义接口，Activity实现接口(定义更新目标Fragment的方法)，传入发起Fragment，传入Fragment要传数据时调用此方法；
不同宿主Activity
发起Fragment → 宿主Activity → 目标宿主Activity → 目标Fragment
不难看出，使用上述这种数据传递机制，页面间的耦合太严重了，而且如果子Fragment有多个，或者一堆子Fragment嵌套，Activity摇身一变 超大类，谁顶得住啊，所以得想写法子来解耦。
0x3、临时应付 → 数据暂存 + 生命周期回调
即使用内存或硬盘，暂存要传递的数据，然后在Activity、Fragment对应的生命周期回调中去读取。简单示例如下：
// 数据暂存类 object DataTempUtils { private val tempDataSet = hashMapOf<String, Any>() fun getTempDataByKey(key: String) = tempDataSet[key] fun updateTempData(key: String, any: Any) { this.tempDataSet[key] = any } } // 解析回传数据的页面 override fun onResume() { super.onResume() val backData = DataTempUtils.getTempDataByKey("${this.javaClass.name}") Log.e("Test", backData.toString()) } // 传递回传数据的页面 DataTempUtils.updateTempData("com.example.test.IndexActivity", "Some Back Data")
相比起原始的数据传递方式，简单了一些，要传的时候就写入，要读的时候就在生命周期函数回调里读，但存在下述问题：
- ① key的问题：怎么生成一个唯一标识？谁负责管理？页面自己、还是另外写一个工具类？
- ② 可能做了一些无效操作：每次都在生命周期回调处主动拉取，无论数据是否有更新都要执行；
- ③ 引入了额外的处理逻辑：比如要在onResume中判断是否第一次进入，数据有效性得判断等；
- ④ 可能会引入一些奇怪的BUG：比如有人在别的地方更新了此数据，但你不知道，导致拿到的数据一直错误等；
0x4、前车之鉴 → 本地广播
数据缓存的方法不太稳健，试试另一个方案 → Broadcast(广播) ， Android四大组件之一，可用作进程内部通信，也可用于进程内部某些组件间的信息/数据传递。可以用，但直接用的话，太重了！怎么说？看下发起一个广播，经历的内部流程：
- ① sendBroadcast 发起广播
- ② 将广播信息告知system_server
- ③ system_server查找到对应receivers
- ④ 广播进入分发队列等待分发
- ⑤ 调用App进程receiver的onReceiver()回调
就自己的APP内部使用，得经历两次Binder Call，而且发送的广播别人也能收到(存在被劫持风险)，甚至可以伪造广播欺骗我们的Receiver。当然，可以通过配置权限进行规避：
- 发送时：指定接受者必须具备的permission，或intent.setPackage()设置仅对某个程序生效；
- 接收时：动态注册的指定发送者必须具备的permission，静态注册的设置android:exported="false"；
针对上述问题，Android v4包引入了轻量级的本地广播 → LocalBroadcast，用法很简单：在Activity、Fragment中 动态注册 需要监听的广播并绑定，当发送了广播时，注册了此类型广播的接收者，就会回调对应的onReceiver()方法，还要注意页面销毁时取消广播注册！使用代码示例如下：
// ============ 动态注册广播 ============ // 实例化广播接收者实例(此处用匿名内部类偷懒，不然还得自己定义一个广播接收者类) private var mReceiver = object : BroadcastReceiver() { override fun onReceive(context: Context?, intent: Intent?) { Log.e("Test", "收到返回数据") } } // 注册广播 LocalBroadcastManager.getInstance(this).registerReceiver(mReceiver, IntentFilter("index_action")) // 销毁时要取消注册广播，防止内存泄漏 override fun onDestroy() { super.onDestroy() LocalBroadcastManager.getInstance(this).unregisterReceiver(mReceiver) } // ============ 发送广播 ============ LocalBroadcastManager.getInstance(this).sendBroadcast(Intent("index_action")) // 注：androidx里，使用本地广播要另外添加下述依赖，不然会提示找不到类： // implementation 'androidx.localbroadcastmanager:localbroadcastmanager:1.0.0'
调用方法简单，进一步解耦了，观摩下源码，了解具体的实现原理，先跟 LocalBroadcastManager:
定义了两个类：ReceiverRecord 和 BroadcastRecord，看下构造方法和 getInstance() 方法：
跟下注册广播的方法 registerReceiver()：
有点懵？没事，先看下定义mReceivers和mActions的定义：
接着看下取消广播注册的方法 unregisterReceiver() ：
再看下发送广播的方法 sendBroadcast() ：
就是根据Action信息，生成了一个广播记录列表(Action，接收者列表)，然后利用handler发起一个广播类型的空信息。回到构造方法处：
判断是广播类型的信息，走 executePendingBroadcasts()：
还有一个立即执行的方法：sendBroadcastSync()
以上就是本地广播的实现逻辑，通过这种方式解耦：
- 要传出数据的页面：直接发广播，不用管谁接收；
- 要接收数据的页面，注册广播，收到广播自动执行对应回调；
这种玩法妥妥滴是 观察者模式，虽然不是常规实现方式。核心是：自行维护广播(被观察者)和接收者(观察者)的集合，配合Handler完成事件分发，可以的~
但！还是不够轻量，数据传递的依赖系统的 BroadcastReceiver，里面糅合了很多跟我们业务无关的东西，违反了 迪米特原则。
So，基于观察者模式的思想，借鉴 LocalBroadcast，来探索着实现一个更轻量级的广播~
