EventBus HandlerPoster简单分析

本篇博文理论知识储备：
Otto源码解读
 EventBus源码解析开篇
 EventBus BackgroundPoster原理解析
在阅读本篇博文之前，请先阅读上面几篇博客，可以对EventBus的工作原理做一个系统的了解。
EventBus的在EventBus BackgroundPoster原理解析一文中详细的说明了ThreadModel.BACKGROUND 的工作原理、PendingPostQueue事件链表的构建以及PendingPost对象的复用技术。本篇博文继续分析EventBus的一些其他的知识点。

通过上面的几篇博文可以总结出EventBus的核心工作原理：其中PendingPostQueue是整个EventBus的核心，它构成了EventBus的事件链表结构，而从链表中获取事件对象PendingPost的不同方式，在EventBus中表现为不同的ThreadModel，比如而ThreadModel.BACKGROUND则是在非UI线程中操作PendingPostQueue链表，来操控事件从发布到执行都是在非UI线程中执行；HandlerPoster对应的就是ThreadModel.MAIN,表明是在UI线程中获取PendingPostQueue链表中的元素（PendingPost对象）进行处理。这从某种程度上来看，有点类似于策略模式。

在EventBus种Poster接口的不同实现，就是对应着不同的ThreadModel。本文就对另外一个Poster—-HandlerPoster做一个简单的分析。在android种一切于UI线程操作有关的东西都少不了Handler的影子（详见android消息处理机制原理解析),在EventBus中处理ThreadModel.MAIN的相关代码如下：

 case MAIN:
       if (isMainThread) {
            //1、如果已经处于UI线程，则直接调用
            invokeSubscriber(subscription, event);
        } else {
            //2、如果非UI线程，则调用mainThreadPoster处理
            mainThreadPoster.enqueue(subscription, event);
        }
        break;

在MAIN这个case分支中对于是否处于UI作了判断，如果事件的产生本身处于UI线程则直接调用invokeSubscriber让subscription这个对象处理事件（subscription类似于Otto的EventHandler对象），注意EventBus的invokeSubscriber方法就是最终消费事件的方法。当处于非UI线成的时候就调用mainThreadPoster.enqueue的来让事件的消费切换到UI线程中执行。

在这里mainThreadPoster如果客户端不做额外配置的话就是EventBus内置的HandlerPoster了：

//本身是一个Handler，也是一个Post接口的实现类
public class HandlerPoster extends Handler implements Poster {

    private final PendingPostQueue queue;
    private final int maxMillisInsideHandleMessage;
    private final EventBus eventBus;
    private boolean handlerActive;
}

进入Poster接口的enqueue方法来看看其具体的实现：

 public void enqueue(Subscription subscription, Object event) {
        //将subscription和event构建成一个PendingPost对象
        PendingPost pendingPost = PendingPost.obtainPendingPost(subscription, event);
        synchronized (this) {
            //将pendingPost插入到事件链表的尾部
            queue.enqueue(pendingPost);
            if (!handlerActive) {
                handlerActive = true;
                //发送消息，执行handleMessage
                if (!sendMessage(obtainMessage())) {
                    throw new EventBusException("Could not send handler message");
                }
            }
        }
    }

整体来说就是先讲事件处理对象subscription和事件event封装成一个PendingPost，继而将pendingPost对象插入的PendingPost链表中(详见EventBus BackgroundPoster原理解析)，然那调用sendMessage交给Handler的handleMessage方法处理。

  public void handleMessage(Message msg) {
        boolean rescheduled = false;
        try {
            //执行开始计时
            long started = SystemClock.uptimeMillis();
            while (true) {
                //从连表中获取一个PendingPost事件
                PendingPost pendingPost = queue.poll();
                if (pendingPost == null) {
                    synchronized (this) {
                        // Check again, this time in synchronized
                        pendingPost = queue.poll();
                        if (pendingPost == null) {
                            handlerActive = false;
                            return;
                        }
                    }
                }
                //进行事件处理
                eventBus.invokeSubscriber(pendingPost);
                //如果在规定的时间内还没有处理完毕，则继续回调handleMessage处理
                long timeInMethod = SystemClock.uptimeMillis() - started;

                if (timeInMethod >= maxMillisInsideHandleMessage) {
                    if (!sendMessage(obtainMessage())) {
                        throw new EventBusException("Could not send handler message");
                    }
                    rescheduled = true;
                    return;
                }
            }
        } finally {
            handlerActive = rescheduled;
        }
    }
}

可以看出handleMessage对事件链表的处理是不断循环获取链表中的PendingPost，当链表中的事件处理完毕后退出while循环。或者是在规定的时间内maxMillisInsideHandleMessage没有将事件处理完，则继续调用sendMessage。继而重新回调handleMessage方法，事件会继续执行。这是为了避免队列过长或者事件耗时较长时，while循环阻塞主线程造成卡顿。算是个小技巧。

到此为止HandlerPoster算是讲解完毕，作为一个公共库除了对内提供默认支持以外，对外提供良好的扩展性也是很有必要的，方便用户用自己的实现来替代库中的默认实现（构建者模式在此中情况下使用最合理）。

在EventBus 中除了用HandlerPoster默认实现将事件切换到主线程执行之外，EventBus还提供了MainThreadSupport这个接口：

public interface MainThreadSupport {

    boolean isMainThread();
    //返回客户端自定义的ThreadModel.MAIN处理方式
    Poster createPoster(EventBus eventBus);

 ｝
 //EventBus中的默认实现
 class AndroidHandlerMainThreadSupport implements MainThreadSupport {

        private final Looper looper;

        public AndroidHandlerMainThreadSupport(Looper looper) {
            this.looper = looper;
        }

        @Override
        public boolean isMainThread() {
            return looper == Looper.myLooper();
        }

        @Override
        public Poster createPoster(EventBus eventBus) {
            //默认使用HandlerPoster对象
            return new HandlerPoster(eventBus, looper, 10);
        }
    }

mainThreadPoster接口提供了一个createPoster方法，由客户端自己初始化ThreadModel.Main的处理方式，在EventBus类中初始化mainThreadPoster代码如下：

    private final MainThreadSupport mainThreadSupport;
    private final Poster mainThreadPoster;

    EventBus(EventBusBuilder builder) {

        mainThreadSupport = builder.getMainThreadSupport();
        //默认返回的就是HandlerPoster对象
        mainThreadPoster = mainThreadSupport != null ? mainThreadSupport.createPoster(this) : null;
    ｝

可以看出就是一个构建者模式的应用，如果客户端没有实现自己的MainThreadSupport接口则默认使用HandlerPoster.其实就一个构建者模式的使用；其实第三方库中构建者模式是常用的设计模式之一，此处可以再次体会到该模式的便利之处。

本篇博文到此结束，如有不当之处欢迎批评指正。

EventBus HandlerPoster简单分析

猜你喜欢