0x5、见招拆招 → 手写一个更轻量级的广播

① 观察者模式常规写法 → 先写个雏形

不了解观察者模式的可以看：把书读薄 | 《设计模式之美》设计模式与范式（行为型-观察者模式），直接开敲：

// 传递数据类
data class Entity(
    val key: String,
    var value: Any
)
// 更新回调接口
interface IUpdate {
    fun updateData(entity: Entity)
}
// 观察者抽象类
abstract class Observer: IUpdate
// 被观察者
object Subject {
    private val observerList = arrayListOf<Observer>()
    fun register(observer: Observer) {
        this.observerList.add(observer)
    }
    fun unregister(observer: Observer) {
        this.observerList.remove(observer)
    }
    fun postMessage(entity: Entity) {
        observerList.forEach { it.updateData(entity) }
    }
}

简单如斯，接着可以写个简单的实例验证下，A → B → C → D，D发送消息，ABC接收消息(页面一样~)：

class ATestActivity : AppCompatActivity() {
    // 观察者回调
    val mObserver: Observer = object : Observer() {
        override fun updateData(entity: Entity) {
            tv_content.text = entity.value.toString()
        }
    }
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_index)
        tv_title.text = "页面A"
        bt_test.setOnClickListener {
            startActivity(Intent(this, BTestActivity::class.java))
        }
        // 注册事件
        Subject.register(mObserver)
    }
    override fun onDestroy() {
        super.onDestroy()
        // 取消事件注册
        Subject.unregister(mObserver)
    }
}
class DTestActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_index)
        bt_test.setOnClickListener {
            // 发送事件
            Subject.postMessage(Entity("back_data", "页面D的返回数据~"))
            finish()
        }
    }
}

运行效果如下：

网络异常，图片无法展示

D发送了广播，然后ABC都收到，且进行了页面更新，可以，雏形有了，开始着手优化。

② 只关注想关注的广播 → 数据结构优化

被观察者Subject的postMessage()直接对列表里的所有观察者进行了遍历，有点过于粗暴了，毕竟 观察者不一定要关注被观察者的所有行为，以这个为切入点，引入key，同时优化下存储的数据结构：

object Subject {
    private val observerMap = hashMapOf<String, ArrayList<Observer>>()
    fun register(key: String, observer: Observer) {
        val observerList = observerMap[key]
        if (observerList.isNullOrEmpty()) {
            observerMap[key] = arrayListOf()
        }
        observerMap[key]!!.add(observer)
    }
    fun unregister(key: String, observer: Observer) {
        if (observerMap[key].isNullOrEmpty()) return
        observerMap[key]!!.remove(observer)
    }
    fun postMessage(key: String, entity: Entity) {
        if (observerMap[key].isNullOrEmpty()) return
        observerMap[key]!!.forEach { it.updateData(entity) }
    }
}

通过不同的key对订阅者进行区分，减少了无效遍历，但是也带来了一个问题，注册、解注册、发送广播都要传多一个key。

Subject.register("back_data", mObserver)
Subject.unregister("back_data", mObserver)
Subject.postMessage("back_data", Entity("back_data", "页面D的返回数据~"))

嗯，传两个参数看着不是很优雅，发送广播可以把Key整到Entity里，注册和解注册可以搞到Observer类中，改动代码如下：

// 抽象观察者
abstract class Observer: IUpdate {
    abstract val key: String
}
// 观察者回调
val mObserver: Observer = object : Observer() {
    override val key = "back_data"
    override fun updateData(entity: Entity) {
        tv_content.text = entity.value.toString()
    }
}
// 被观察者
object Subject {
    private val observerMap = hashMapOf<String, ArrayList<Observer>>()
    fun register(observer: Observer) {
        val observerList = observerMap[observer.key]
        if (observerList.isNullOrEmpty()) {
            observerMap[observer.key] = arrayListOf()
        }
        observerMap[observer.key]!!.add(observer)
    }
    fun unregister(observer: Observer) {
        if (observerMap[observer.key].isNullOrEmpty()) return
        observerMap[observer.key]!!.remove(observer)
    }
    fun postMessage(entity: Entity) {
        if (observerMap[entity.key].isNullOrEmpty()) return
        observerMap[entity.key]!!.forEach { it.updateData(entity) }
    }
}

③ FBI WARNING：警惕内存泄漏的风险

上面的代码，看上去好像没啥问题，是吧？但...真的没问题吗？

上面我们偷懒用的匿名内部类，它存在这样的问题：

匿名内部类会持有外部类的引用，此处的外部类是Activity，如果忘记解绑(移除集合)，会导致onDestory()后，Subject中的集合依旧持有Activity引用。当Subject遍历执行到此回调时，BOOM！内存泄漏就来了~~

验证方法很简单，build.gradle依赖下LeakCanary：

debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.7'

然后页面故意漏掉某个Observer的解绑，然后此页面finish()掉后，在另一个页面发起一个事件，尝试几次后会发现：

网络异常，图片无法展示

所以，切记解绑 ！！！一种比较无脑的解绑方式(笨，但是稳健~)：

在页面基类里定义一个集合，把每个Observer实例都加入其中，在onDestory()中遍历取消注册

示例如下：

protected val mObserverList = arrayListOf<Observer>()
// 直接将观察者加入列表
mObserverList.add(object : Observer() {
    override val key = "other_data"
    override fun updateData(entity: Entity) {
        tv_content.text = entity.value.toString()
    }
})
// 遍历列表注册
mObserverList.forEach { Subject.register(it) }
override fun onDestroy() {
    super.onDestroy()
    // 遍历取消事件注册
    mObserverList.forEach { Subject.unregister(it) }
}

④ 谁是卧底 → 谁才是真正的观察者

知道要规避内存泄漏风险后，继续优化，在使用过程中不难发现这样的问题：

一个观察者可能对观察者的多种行为进行观察，行为有多少种，就要实例化多少个Observer

em...好像有点不对劲，这TM是把行为作为了观察者啊，观察者应该包裹各种行为的回调，明显 页面才是观察者，简单，页面直接实现IUpdate接口，重写更新数据的方法。

class ATestActivity : AppCompatActivity(), IUpdate {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_index)
        tv_title.text = "页面A"
        bt_test.setOnClickListener {
            startActivity(Intent(this, BTestActivity::class.java))
        }
        Subject.register(this)
    }
    override fun updateData(entity: Entity) {
        when(entity.key) {
            "back_data" -> tv_content.text = entity.value.toString()
        }
    }
    override fun onDestroy() {
        super.onDestroy()
        Subject.unregister(this)
    }
}
// 变回原样的被观察者
object Subject {
    private val observerList = arrayListOf<IUpdate>()
    fun register(observer: IUpdate) {
        observerList.add(observer)
    }
    fun unregister(observer: IUpdate) {
        observerList.remove(observer)
    }
    fun postMessage(entity: Entity) {
        observerList.forEach { it.updateData(entity) }
    }
}

可以是可以，但postMessage()又变回之前的无脑遍历状态了，因为页面传这个Key有点麻烦，毕竟实现的IUpdate接口。如果在页面中定义额外的key属性，在Subject里拿到观察者还得做下类型强转拿Key。

简单点说：被观察者还得知道观察者具体的类型，这又耦合了...

这个问题先放一放，等下会解决，这里思考另一个问题：

既然暂时没法有脑遍历了，那广播Entity里的Key还有必要吗？

没有，直接定义不同的广播类型，观察者直接判断类型执行对应操作就好了，改动后的代码：

interface IUpdate {
    fun updateData(any: Any)
}
object Subject {
    private val observerList = arrayListOf<IUpdate>()
    fun register(observer: IUpdate) {
        observerList.add(observer)
    }
    fun unregister(observer: IUpdate) {
        observerList.remove(observer)
    }
    fun postMessage(entity: Any) {
        observerList.forEach { it.updateData(entity) }
    }
}
// 传递数据
data class DataEntity(var data: String)
// 刷新页面
object RefreshEntity
// 测试页面
class ATestActivity : AppCompatActivity(), IUpdate {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_index)
        tv_title.text = "页面A"
        bt_test.setOnClickListener {
            startActivity(Intent(this, BTestActivity::class.java))
        }
        Subject.register(this)
    }
    // 对应不同的广播执行不同的处理
    override fun updateData(any: Any) {
        when (any) {
            is DataEntity -> tv_content.text = any.data
            is RefreshEntity -> Toast.makeText(this, "收到更新广播", Toast.LENGTH_SHORT).show()
        }
    }
    override fun onDestroy() {
        super.onDestroy()
        Subject.unregister(this)
    }
}
class BTestActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_index)
        tv_title.text = "页面B"
        bt_test.setOnClickListener {
            Subject.postMessage(DataEntity("回传数据"))
            Subject.postMessage(RefreshEntity)
            finish()
        }
    }
}

看到这里，有用过EventBus的童鞋，肯定会哔一句：这TM不就是EventBus吗？

像，但还不是，你用EventBus，Activity和Fragment需要实现接口吗？所以接下来想办法让观察者不用实现接口。

⑤ 巧用反射 → 少写一个接口

假设我们约定成俗，只要类中定义了 updateData(any: Any) 方法，我们就把它当做观察者的回调方法。

所以要做的就是获取观察者类所有的方法，遍历匹配 方法名和参数个数，符合的方法就是回调方法，用 反射 实现一波。修改后的被观察者：

object Subject {
    private val observerMap = hashMapOf<Any, Method?>()
    fun register(any: Any) {
        var method: Method? = null
        try {
            // 反射获得此方法
            method = any.javaClass.getDeclaredMethod("updateData", Any::class.java)
            observerMap[any] = method
        } catch (e: NoSuchMethodException) {
            e.printStackTrace()
        }
    }
    fun unregister(any: Any) {
        observerMap[any] = null
        observerMap.remove(any)
    }
    fun postMessage(entity: Any) {
        observerMap.forEach { (key, value) ->
            value?.invoke(key, entity)
        }
    }
}

把观察者类：实现IUpdate接口和updateData(any: Any)前override标识干掉，运行验证一波，效果一致。

⑥ 巧用运行时注解 → 规避方法名写错

上面通过反射省去了实现一个接口，但也带来了隐患，方法不能自动生成，只能手敲或复制粘贴，就有可能出现函数名拼写错误的问题，毕竟人是容易犯错的。

能不能显式地告诉编译器：这函数就是观察者的回调方法，你不用理他叫啥？

还真可以，利用 注解 就可以实现，有些朋友可能对注解有些陌生(没用过)，没关系，简单过一波~

Java里都见过 @Override 吧，在重写方法时要加上此注解，否则编译器直接爆红，无法编译。这里的@Override就是注解，用于告知编译器正在重写一个方法，这样，当父类方法被删除或修改时，编译器会提示错误信息。

注解可用来修饰类、方法、参数等，有下述三种使用场景：

编译器提示信息：给编译器用来发现错误，或清除不必要的警告；
编译时生成代码：利用编译器外的工具(如kapt)根据注解信息自动生成代码；
运行时处理：在运行时根据注解，通过反射获得具体信息，然后做一些操作；

限于篇幅就不讲解注解相关的姿势了，可自行搜索资料学习，或参见《Kotlin实用教程 | 0x9 - 注解与反射》，Java 和 Kotlin 的注解规则有点不一样哈~

此处应用注解正是第三种场景，先定义一个注解类：

// 与Java用 @interface 声明注解不同，kotlin使用 annotation class 进行声明
@Target(AnnotationTarget.FUNCTION)  // 修饰函数
@Retention(AnnotationRetention.RUNTIME) // 函数的保留存活时间
annotation class Subscribe

接着获取订阅者类所有的方法，判断修饰符及是否包含Subscribe注解，然后加入集合：

// 修改后的被观察者
object Subject {
    private const val BRIDGE = 0x40
    private const val SYNTHETIC = 0x1000
    private const val MODIFIERS_IGNORE = Modifier.ABSTRACT or Modifier.STATIC or BRIDGE or SYNTHETIC
    private val observerMap = hashMapOf<Any, Method?>()
    fun register(any: Any) {
        try {
            val methods = any.javaClass.declaredMethods
            methods.forEach {
                val modifiers = it.modifiers
                // 判断方法修饰符是否为public，不是Static、ABSTRACT等修饰符
                if (modifiers and Modifier.PUBLIC != 0 && modifiers and MODIFIERS_IGNORE == 0) {
                    // 获取参数列表
                    val parameterTypes = it.parameterTypes
                    // 判断参数是否只有一个
                    if (parameterTypes.size == 1) {
                        // 获取SubScribe注解
                        val subscribeAnnotation = it?.getAnnotation(Subscribe::class.java)
                        // Subscribe注解不为空的，把回调方法加入集合
                        subscribeAnnotation?.let { _ -> observerMap[any] = it }
                    }
                }
            }
        } catch (e: NoSuchMethodException) {
            e.printStackTrace()
        }
    }
    fun unregister(any: Any) {
        observerMap[any] = null
        observerMap.remove(any)
    }
    fun postMessage(any: Any) {
        observerMap.forEach { (key, value) ->
            value?.invoke(key, any)
        }
    }
}
// 为观察者回调方法添加@Subscribe注解，并修改为别的函数名
@Subscribe
fun onMainEvent(any: Any) {
    when (any) {
        is DataEntity -> tv_content.text = any.data
        is RefreshEntity -> Toast.makeText(this, "收到更新广播", Toast.LENGTH_SHORT).show()
    }
}

运行效果一致，而且又想到了一个好玩的东西，还记得上面②那里写的：观察者不一定要关注被观察者的所有行为，利用注解，我们可以对不同的 广播类型 进行区分，观察者按需关注对应广播~

换个姿势，更好地参透EventBus（中）