EventBus的使用之重复早轮子

概述

  • EventBus是Android和Java的发布/订阅事件总线。
  • 简化了组件之间的通讯;
    • 将事件发送者和接收者分开;
    • 与Activity,Fragment和后台线程之间调度很是好;
    • 避免了复杂和容易出错的依赖和生命周期问题;
  • 让你的代码变得更简单易懂;

如何使用

EventBus 4 部曲(官方3步): 一、引入依赖:java

Grdle:
compile 'org.greenrobot:eventbus:3.1.1'
复制代码

若是你的项目须要混淆记得加入:android

-keepattributes *Annotation*
 -keepclassmembers class ** {
@org.greenrobot.eventbus.Subscribe <methods>;
}
-keep enum org.greenrobot.eventbus.ThreadMode { *; }
# Only required if you use AsyncExecutor
-keepclassmembers class * extends     org.greenrobot.eventbus.util.ThrowableFailureEvent {
<init>(java.lang.Throwable);
}
复制代码

二、定义一个消息类,该类不继承任何基类也不要实现任何接口。如:git

public  class MessageEvent 
{  
    public String message;
    public MessageEvent(String message){
                this.message = message;
      }
}
复制代码

三、定义事件回调方法,threadMode是可选:github

@Subscribe(threadMode = ThreadMode.MAIN)  
public void onMessageEvent(MessageEvent event) {/* Do something */};
复制代码

四、在须要订阅事件的地方注册事件(必需要先注册,否则没法收到消息):缓存

EventBus.getDefault().register(this);
复制代码

五、发送消息函数

EventBus .getDefault().post(new  MessageEvent());  
复制代码

六、处理消息,即接受到MessageEvent消息作出反应:post

@Subscribe(threadMode = ThreadMode.PostThread)
public void XXX(MessageEvent messageEvent) {
    ...
}
复制代码

在3.0以前,EventBus尚未使用注解方式。消息处理的方法也只能限定于onEvent、onEventMainThread、onEventBackgroundThread和onEventAsync,分别表明四种线程模型。而在3.0以后,消息处理的方法能够随便取名,可是须要添加一个注解@Subscribe,而且要指定线程模型(默认为PostThread),四种线程模型,下面会讲到。 注意,事件处理函数的访问权限必须为public,不然会报异常。 七、取消消息订阅:性能

EventBus.getDefault().unregister(this);
复制代码

#EventBus有何优势 采用消息发布/订阅的一个很大的优势就是代码的简洁性,而且可以有效地下降消息发布者和订阅者之间的耦合度; 举个例子,好比有两个界面,ActivityA和ActivityB,从ActivityA界面跳转到ActivityB界面后,ActivityB要给ActivityA发送一个消息,ActivityA收到消息后在界面上显示出来,我能够告诉你,这样也能够,就是代码过于臃肿;ui

#经常使用API介绍this

线程模型

在EventBus的事件处理函数中须要指定线程模型,即指定事件处理函数运行所在的想线程。在上面咱们已经接触到了EventBus的四种线程模型。那他们有什么区别呢? 在EventBus中的观察者一般有四种线程模型,分别是PostThread(默认)、MainThread、BackgroundThread与Async。

  • PostThread:若是使用事件处理函数指定了线程模型为PostThread,那么该事件在哪一个线程发布出来的,事件处理函数就会在这个线程中运行,也就是说发布事件和接收事件在同一个线程。在线程模型为PostThread的事件处理函数中尽可能避免执行耗时操做,由于它会阻塞事件的传递,甚至有可能会引发ANR。

  • MainThread:若是使用事件处理函数指定了线程模型为MainThread,那么不论事件是在哪一个线程中发布出来的,该事件处理函数都会在UI线程中执行。该方法能够用来更新UI,可是不能处理耗时操做。

  • BackgroundThread:若是使用事件处理函数指定了线程模型为

  • BackgroundThread,那么若是事件是在UI线程中发布出来的,那么该事件处理函数就会在新的线程中运行,若是事件原本就是子线程中发布出来的,那么该事件处理函数直接在发布事件的线程中执行。在此事件处理函数中禁止进行UI更新操做。 Async:若是使用事件处理函数指定了线程模型为Async,那么不管事件在哪一个线程发布,该事件处理函数都会在新建的子线程中执行。一样,此事件处理函数中禁止进行UI更新操做。

    @Subscribe(threadMode = ThreadMode.PostThread)
    public void onMessageEventPostThread(MessageEvent     messageEvent) {
    Log.e("FY", Thread.currentThread().getName());
      }
    
    @Subscribe(threadMode = ThreadMode.MainThread)
    public void onMessageEventMainThread(MessageEvent messageEvent) {
      Log.e("FY", Thread.currentThread().getName());
    }
    
    @Subscribe(threadMode = ThreadMode.BackgroundThread)
    public void onMessageEventBackgroundThread(MessageEvent messageEvent) {
      Log.e("FY", Thread.currentThread().getName());
    }
    
    @Subscribe(threadMode = ThreadMode.Async)
    public void onMessageEventAsync(MessageEvent messageEvent) {
      Log.e("FY", Thread.currentThread().getName());
    }
    复制代码

分别使用上面四个方法订阅同一事件,打印他们运行所在的线程。首先咱们在UI线程中发布一条MessageEvent的消息,看下日志打印结果是什么。 打印结果以下:

postEvent﹕ main
PostThread﹕ main
Async﹕ pool-1-thread-1
MainThread﹕ main
BackgroundThread﹕ pool-1-thread-2
复制代码

从日志打印结果能够看出,若是在UI线程中发布事件,则线程模型为PostThread的事件处理函数也执行在UI线程,与发布事件的线程一致。线程模型为Async的事件处理函数执行在名字叫作pool-1-thread-1的新的线程中。而MainThread的事件处理函数执行在UI线程,BackgroundThread的时间处理函数执行在名字叫作pool-1-thread-2的新的线程中。

再看看在子线程中发布一条MessageEvent的消息时,会有什么样的结果。

打印结果以下:

postEvent﹕ Thread-1
PostThread﹕ Thread-1
BackgroundThread﹕ Thread-1
Async﹕ pool-1-thread-1
MainThread﹕ main
复制代码

从日志打印结果能够看出,若是在子线程中发布事件,则线程模型为PostThread的事件处理函数也执行在子线程,与发布事件的线程一致(都是Thread-1)。BackgroundThread事件模型也与发布事件在同一线程执行。Async则在一个名叫pool-1-thread-1的新线程中执行。MainThread仍是在UI线程中执行。

#黏性事件

除了上面讲的普通事件外,EventBus还支持发送黏性事件。卧槽,黏性事件?简单讲,就是在发送事件以后再订阅该事件也能收到该事件,一些事件在事件发布后携带有兴趣的信息。例如,一个事件表示一些初始化完成。或者若是您有一些传感器或位置数据,而且想要保留最新的值。而不是实现本身的缓存,你可使用粘性事件。因此EventBus将最后一个特定类型的粘滞事件保存在内存中。而后粘性事件能够传递给订阅者或者显式查询。所以,您不须要任何特殊的逻辑来考虑已有的数据。跟黏性广播相似。具体用法以下: 订阅黏性事件:

EventBus.getDefault().register(StickyModeActivity.this);
复制代码

黏性事件处理函数:

@Subscribe(sticky = true)
public void XXX(MessageEvent messageEvent) {
......
}
复制代码

发送黏性事件:

EventBus.getDefault().postSticky(new MessageEvent("test"));
复制代码

#手动获取和删除粘性事件

MessageEvent stickyEvent =   EventBus.getDefault().getStickyEvent(MessageEvent.class);
// Better check that an event was actually posted before
if(stickyEvent != null) {
// "Consume" the sticky event
EventBus.getDefault().removeStickyEvent(stickyEvent);
// Now do something with it
}
复制代码

removeStickyEvent方法被重载:当你传入类时,它将返回之前持有的粘性事件。使用这个变体,咱们能够改进前面的例子:

MessageEvent stickyEvent = EventBus.getDefault().removeStickyEvent(MessageEvent.class);
// Better check that an event was actually posted before
if(stickyEvent != null) {
// Now do something with it
}
复制代码

处理消息事件以及取消订阅和上面方式相同。 建议看官方文档

####开始造轮子 看过EventBus的源码应该知道,EventBus的实现使用了观察者模式。代码以下:

public void register(Object object) {
    List<SubscriberMethod> subscribes = mCacheMap.get(object);
    if (subscribes == null) {
        synchronized (SimpleEventBus.class) {
            subscribes = findSubscribeMethod(object);
            mCacheMap.put(object, subscribes);
        }
    }
}


private List<SubscriberMethod> findSubscribeMethod(Object object) {
    List<SubscriberMethod> subscriberMethods = new CopyOnWriteArrayList<>();
    Class<?> clazz = object.getClass();

    while (clazz != null) {
        String name = clazz.getName();
        //排除系统的类或接口,不能是系统的类或接口,由于咱们的订阅方法只能是咱们本身的类或接口
        if (name.startsWith("java") || name.startsWith("javax") || name.startsWith("android")) {
            break;
        }

        //该类定义的Method
        Method[] methods = clazz.getDeclaredMethods();
        for (Method method : methods) {
            Annotation annotation = method.getAnnotation(Subscribe.class);
            if (annotation == null) continue;
            Class<?>[] parameterTypes = method.getParameterTypes();
            if (parameterTypes.length != 1) throw new RuntimeException("只能有一个参数");

            Class<?> methodParameterType = parameterTypes[0];
            ThreadMode threadMode = ((Subscribe) annotation).threadMode();
            subscriberMethods.add(new SubscriberMethod(method, threadMode, methodParameterType));
        }
        clazz = clazz.getSuperclass();
    }

    if (subscriberMethods.size() <= 0) {
        throw new RuntimeException("必须有一个订阅方法");
    }

    return subscriberMethods;
}
复制代码

看到当EventBus开始register的时候经过解析注解,拿到注解标识的接收事件的方法,而后解析注解并将解析到的Method和Method Param type以及ThreadMode保存到内存中,在来看看那post方法,代码以下:

/**
 * 其实是根据订阅方法的参数和发布传进来的对象进行对比
 *
 * @param eventMessage
 */
public void post(Object eventMessage) {
    Set<Object> objects = mCacheMap.keySet();
    for (Object obj : objects) {
        List<SubscriberMethod> subscriberMethods = mCacheMap.get(obj);
        if (subscriberMethods == null) continue;

        for (SubscriberMethod subMethod : subscriberMethods) {
            Class<?> aClass = subMethod.getEventType();
            Class<?> bClass = eventMessage.getClass();
            //aClass 的class是是否是bClass的的父类或者接口
            if (aClass.isAssignableFrom(bClass)) {
                invoke(subMethod, obj, eventMessage);
            }
        }
    }
}



private void invoke(SubscriberMethod subscriberMethod, Object obj, final Object eventObj) {
    EventTask eventTask = new EventTask(subscriberMethod.getMethod(), obj, eventObj, subscriberMethod.getThreadMode());
    ScheduleRouterExecutor.getInstance().executeTask(eventTask);
}
复制代码

当post的时候,经过post传入的参数类型与第2步解析的获得的数据进行对比,回调的对应的方法,整个过程就结束了。

#####最后两个问题: 一、由于EventBus,在运行时大量存在了反射,势必会形成没必要要的性能问题,咱们是否可使用编译注解解决这个问题,相似于ARouter的方式? 二、EventBus并不支持跨进程通信,咱们是否能够对他进程拓展?那么这样会不会和第1的问题冲突呢?

从上面知道EventBus是不支持跨进程通信和大量反射有性能损耗,后期将尝试解决这些问题demo地址

相关文章
相关标签/搜索