####前言
EventBus到了3.0版本,使用Apt注解处理器来在编译期通过读取@Subscribe()注解并解析生成java类来保存订阅者关于的信息,比在之前使用反射来获得这些订阅者的信息速度要快。但是事件触发依然是使用method.invoke来调用。纵观EventBus的源码，还是有大量使用反射的地方。
然而，尽管反射非常强大，但也不能随意大量使用。如果一个功能可以不用反射完成，那么最好就不用。由于反射允许代码执行一些在正常情况下不被允许的操作（比如访问私有的属性和方法），所以使用反射可能会导致意料之外的副作用，使用反射相对来说不安全 －－代码有功能上的错误，降低可移植性。反射代码破坏了类的封装性抽象性，因此当平台发生改变的时候，代码的行为就有可能也随着变化。而且使用反射的性能较低。
反射这个异教徒，并不属于OOP的范畴，简直就是代码界的IS，强行蹂躏对象，破坏原有结构，对面向对象的世界观进行残(危)酷(言)肢(耸)解(听)。好了，进入正题：
我眼中EventBus的缺点：
一，不够简洁：需要手写大量register和unregister的垃圾代码，这对我来说是致命的缺点
二、不够高效：虽然用了Apt和METHOD_CACHE来优化了反射，单仍然不够完美理想化
三、不够专注：事件传递的框架，就不需要关心线程切换什么的吧，你这么牛逼RxJava知道吗
好了，话不多说，开车。
先看效果：
对，没错，触发事件一句代码：
|
|
支持粘连事件(先触发后注册)
OkBus.getInstance().onStickyEvent(EventTags.FLASH_INIT_UI, null);
什么？注册和反注册？这些代码全部都是插件自动生成，不用再手动写啦！
Javassist在编译期间通过插件，已经帮你自动生成注册、反注册、事件分发的代码并且帮你加上啦！如果没有这样的方法，会自动生成并加上，如果本来就有，就更简单了，直接在方法里面追加就可以了。
来看build/intermediates/transforms下的源代码
Activity(Fragment)有onCreate(onActivityCreated)，onDestroy可以自动加，想在别的地方用怎么办？
请看Presenter中用法：
即使没有那样的时机让插件自动插入，那只要吱个声(加个注解)，插件也会自己自动帮你加。
添加后的代码：
需要在哪个方法里注册就加上@BusRegister注解，反注册就加@BusUnRegister，现在你可以在任何地方使用了。
那要是忘加注解了怎么办？
别急，插件依然会在编译期间提醒你：
所有一切都是编译期间所做的，零反射零代理。实现的方式，不过一类，一插件，一注解，百余行代码而已。
##1、OkBus类
######OkBus属性：
主要就是基本信息的存储和单例的实现
######OkBus register方法：
注册的时候放入回调列表，如果是粘连事件，注册时就去已分发的粘连事件库存去拿参数并触发回调。
######OkBus反注册和触发事件方法：
反注册就直接remove回调，触发时分普通事件和粘连事件，粘连事件就存库里备用
OK，以上就是全部代码。这里直接用回调实现事件通知，没有什么复杂的逻辑，现在考虑的情况也比较简单
##2、插件代码
剩下的都是插件代码：
######BusInfo类：
存储事件的相关的信息，便于生成代码逻辑：
######transform操作
然后在transform中，根据源代码创建BusInfo，处理BusInfo、利用BusHelper操作源代码进行方法和代码的插入，
######BusHelper生成代码
BusHelper里面有一些模版代码：
处理BusInfo：
获取初始化OkBus方法的代码
生成event事件分发的逻辑代码
生成取消事件注册的代码
Ok，以上便是全部代码，百十行而已(Log占了一大部分)，Gradle插件虽然是使用用groovy，我真的完全没看过任何博客学过groovy，因为groovy完全兼容java，闭着眼睛当java写好像并没有什么不对(不要喷我，，，)。
Javassist实现逻辑插入的部分，说高深点叫操作修改字节码，说简单点就是字符串拼接，插入代码或者方法。相比ASM，真的太适合java开发者来使用了。
以上代码在T-MVP可以看到，TMVP本来想做成库，现在已经彻底沦为实验室，欢迎各位客官前来把玩。
OK，车已到站，下车请刷卡
![T-MVP项目结构])X{FRT]K9SMSZ}CY.jpg](http://upload-images.jianshu.io/upload_images/751860-281b2b0198b49042.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
