Android EventBus框架学习笔记

主要经过某大拿的文章进行学习，作一下本身理解的记录：

http://www.cnblogs.com/angeldevil/p/3715934.html

 

总的来讲eventbus是这么一个实现思路：

1.订阅者注册event：把订阅者以“onEvent”开头的方法，经过参数类型、运行方式区分，保存到map里。

2.发布者：经过参数类型取出全部运行方式、全部订阅者的对应方法，把参数传入并执行。

*运行方式主要有三种：主线程、后台、异步任务

 

主要逻辑：

一.findSubscriberMethods：找到类里的全部方法（包括继承自基类的），比较方法名，取出符合命名规则要求的，以list形式插入到methodCache里，

key为类名+".onEvent"(若是默认)。

二.subscribe：1. eventType为实例化SubscriberMethod时传入，为方法的第一个参数类型；
     　　　　　 2.SubscriberMethod对象包含三个关键信息，method、threadMode、eventType
                    3.subscriptionsByEventType里存放eventType与Subscription的映射，Subscription关键参数为订阅者和SubscriberMethod
                    4.typesBySubscriber里放的是订阅者和eventType的list的映射,意义是一个订阅者能够有多个事件（多个方法参数）
                    5.注册的过程就是把订阅者和方法组成一个实体，放到一个map里，以便发送时只经过发送的参数类型，就能找到全部订阅者及其应该执行哪个方法（
                       由于方法的线程模式不一样因此同种参数类型同个订阅者可能存在多个方法）

三：postToSubscription：经过不同的运行方法发送消息。管理一系列的HandlerPoster对象来实现发送队列的管理。

 

其余在转载来的原文里有详细说明就再也不复制。

 

总结：

1.因为eventbus框架是别人带进来的，因此按照他的用发主要用来页面间传递一些参数，看过源码后发现应该主要是用来实现事件的发送和接受，参数只是附加的。二者的区别在：若是只是传一些值，就会碰到不少参数类型冲突。好比带进这个框架的小子的用发，传一个用户信息的实体，在订阅者那边接受这个实体来进行ui的更新，那若是其余地方须要传递用户信息来进行用户的添加呢？因为eventbus的发送至认参数类型（也就是事件），因此显然最初不是被设计为来解决传递值的问题的。这个例子里的作法应该是定义两个事件：更新用户信息、添加用户信息。

2.在订阅者类里除了注册eventbus，主要经过方法名来接受消息，好比onEventMainThread就是接受在主线程发出的消息。eventbus是经过反射来实现这些订死了的方法名的比较。这就致使开发上的不方便，像我这种记性极差的人，常常须要到其余地方把方法名copy过来。

此次研究的主要目的也是为了实现经过重写基类方法、或者调用统一入口来往eventbus的执行队列里面插对象，接口就不考虑了，增长了耦合性。结果发现没那么好整。

首先若是经过重写基类，那就是要在基类里写上3个方法等待子类重写，这个时候若是在订阅者类里register了eventbus，会把子类、父类的方法所有插入队列，也就是假如我只须要实现主线程接受，其余两个方法依然会插入队列，会对他们发送消息。虽然对效果没影响，可是显然不是最好的实现方法。

而后就是统一路口这个方式了，个人思路是往eventbus里面传一些参数为interface的对象，而后模仿他维护几个队列进行这些接口的执行。后来研究了一下发现这样估计时间成本还比较大。

 

没有完美的方案，那仍是等有时间的时候再来仔细把源码吃透后再改。

此次的学习中也涉及到了aop的一些概念和实现思路，也算是受益不浅。