Android中的消息系统————Handler,MessageQueue与Looper

我们都知道,Android系统强制要求我们将更新ui等操作放在主线程中进行,而网络请求,读取文件等耗时操作则通常会放到子线程中运行,因此,在Android开发中经常需要在不同的线程之间进行切换。而Android系统为我们提供了消息系统来进行异步消息的处理,因此我们有必要了解一下Android消息系统的工作原理。

Handler,MessageQueue与Looper之间的关系

我们先来看一下Handler,MessageQueue与Looper三者之间的关系。首先,Handler对象负责发出一个消息,这个消息最终会被提交到一个MessageQueue之中,这个MessageQueue则是一个专门用来存储Message的队列集合。而Looper对象内部有一个无限循环,它会不断的从这个MessageQueue中取出消息,并将其交给发出该消息的Handler进行处理。

需要注意的是,我们可以在一个线程中创建很多个Handler对象,但是每个线程只会对应一个Looper和MessageQueue对象。Handler对象在初始化的时候会和该线程所对应的Looper及MessageQueue对象进行绑定。因此,Handler在哪个线程中创建,它发出的消息最终就会在哪个线程中执行。接下来我们通过源码来详细的看一下它们的工作原理。

消息系统的创建

先从消息系统的创建说起。Android中主线程的消息系统会在主线程启动时默认被创建,而子线程的消息系统默认则不会被创建,我们需要在子线程中手动调用Looper.prepare()和Looper.loop()这两个静态方法才可以开启子线程的消息系统。接下来我们以主线程为例看一下消息系统的创建过程。

Android主线程的消息系统是在ActivityThread类的main方法中被创建的,我们看一下main方法的代码:

    public static void main(String[] args) {
        ...
        Looper.prepareMainLooper(); //先调用prepareMainLooper方法

        ActivityThread thread = new ActivityThread();
        thread.attach(false);

        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }

        if (false) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));
        }

        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        Looper.loop();  //然后调用loop方法

        throw new RuntimeException("Main thread loop unexpectedly exited");//因为Looper.loop()实际上是执行了一个无限循环,所以一般情况下不会走到这句,除非出现异常导致循环中断
    }

我们可以看到,与子线程不同的是,主线程的消息系统在启动时调用的是Looper.prepareMainLooper方法而非prepare方法。在调用完prepareMainLooper方法之后又调用了Looper.loop方法。我们看一下prepareMainLooper方法:

    public static void prepareMainLooper() {
        prepare(false);//调用prepare方法
        synchronized (Looper.class) {
            if (sMainLooper != null) {
                throw new IllegalStateException("The main Looper has already been prepared.");
            }
            sMainLooper = myLooper();//通过myLooper方法将创建好的looper对象赋值给sMainLooper全局对象
        }
    }

可以看到prepareMianLooper方法中其实也是调用的prepare方法,prepare方法的源码如下:

    private static void prepare(boolean quitAllowed) {
        if (sThreadLocal.get() != null) {
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        sThreadLocal.set(new Looper(quitAllowed));
    }

在prepare方法中,系统直接通过new关键字创建了一个Looper对象,并将这个Looper对象放在了一个名为sThreadLocal的全局对象中。

这个sThreadLocal对象是一个定义在Looper中的类型为ThreadLocal的全局对象,并且被static final所修饰。ThreadLocal是java所提供的一个类,我们可以通过ThreadLocal的set(T value)方法来给这个ThreadLocal对象设置一个变量,但值得注意的是,通过ThreadLocal来维护的变量是线程私有的,各个线程通过ThreadLocal.get()方法取得的对象都是独立的,他们之间的操作都互不影响的。主线程将一个Looper对象设置给了一个ThreadLocal,其他子线程是无法通过这个ThreadLocal对象来获取主线程的Looper对象的。因此,Android通过ThreadLocal来维护Looper对象,就做到了每个线程对应一个独立的Looper对象。

我们再来看一下Looper的构造方法:

    private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
    }

可见Looper对象在初始化时直接创建了一个MessageQueue集合,并赋值给成员变量mQueue。因此MessageQueue对象被Looper对象所持有。

现在Looper和MessageQueue对象已经创建完成了。我们再回到prepareMainLooper方法中。在通过prepare方法创建完Looper对象和MessageQueue对象后,系统又调用了Looper的myLooper方法,而myLooper方法返回的其实是刚才创建的该线程所独有的Looper对象,这里即是主线程所对应的Looper对象。系统将这个对象赋值给了一个全局变量sMainLooper,方便之后使用getMainLooper方法来直接拿取主线程的Looper对象。myLooper方法的代码如下:

    public static @Nullable Looper myLooper() {
        return sThreadLocal.get();
    }

至此准备工作都已经完成了,系统只需要再通过Looper.loop方法让消息系统运行起来即可,loop方法的源码如下:

    public static void loop() {
        final Looper me = myLooper();   //获取looper对象
        if (me == null) {
            throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
        }
        final MessageQueue queue = me.mQueue;  //获取MessageQueue对象
        ...
        for (;;) {
            Message msg = queue.next(); // 从MessageQueue对象中获取一个消息
            if (msg == null) {
                return;
            }
           ...
            try {
                msg.target.dispatchMessage(msg);//将这个消息分发给相应的Handler进行处理
                end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
            } finally {
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
                }
            }
            ...
            msg.recycleUnchecked();
        }
    }

loop方法的代码较多,为了便于理解,省去了部分代码。首先通过myLooper方法获取当前线程对应的Looper对象,然后又通过me.mQueue拿取了looper对象内部的MessageQueue。之后开启了一个无限循环,在循环中,首先通过queue.next()取出MessageQueue中存储的一个消息,如果这个消息不为null,则通过msg.target.dispatchMessage(msg)分发给相应的Handler进行处理。msg.target其实就是发出该消息的Handler对象。Handler在发出一个消息时会将自身存储在Message内部的target变量中,之后在分析Handler时会讲到。我们先来看一下dispatchMessage方法的源码:

    public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);    //通过handleCallback来执行Message对象内部的Runnable
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg); //将Message交给handleMessage方法进行处理
        }
    }

首先会检查msg的callback对象是否为null,这个callback是一个Runnable类型的对象,我们知道Handler可以发出两种类型的消息,一种是通过sendMessage等方法直接发送一个Message消息对象,另一种是通过则会通过post方法发送一个Runnable对象。如果发送的是一个Runnable对象,Handler在内部也会将这个Runnable对象封装成一个Message对象,并将原来的Runnable对象赋值给Message的callback变量。如果msg.callback不为null,说明该消息原本是通过Handler的post方法发出的一个Runnable,那么会通过handleCallback方法直接执行这个Runnable。如果msg.callback对象为null,那么就将这个msg交给Handler的handleMessage方法进行处理。我们在创建Handler对象时通常会重写handleMessage方法来实现我们想要的逻辑。

由于loop方法内部其实是一个无限循环,因此Looper对象会不断的从MessageQueue对象中拿取消息并分发给对应的Handler进行处理。需要注意的是,如果我们在子线程中调用了Looper.loop方法,那么Looper中的无限循环会导致子线程阻塞,因此当我们在子线程中使用了Looper后,应该在适当的时机调用looper对象的quit或quitSafely方法来退出这个Looper。

至此整个主线程的消息系统已经创建完成并且开始工作了,接下来我们看一下Handler是如何将一个消息提交给相应的MessageQueue的。

消息的发送过程

Handler对象负责消息的发送和处理。我们先来看一下Handler对象的构造方法:

    public Handler(Callback callback, boolean async) {
        ...
        mLooper = Looper.myLooper();//与Looper进行了绑定
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
        mQueue = mLooper.mQueue;//与MessageQueue绑定
        mCallback = callback;  
        mAsynchronous = async;
    }

Handler对象有许多重载的构造方法,但这些构造方法最终都是调用的Hanler(Callback callback, boolean async)这个构造方法。在这个构造方法中,首先通过Looper.myLooper获取到了一个Looper对象并赋值给了自己的一个成员变量,前面我们说过,myLooper对象返回的是当前线程所独有的Looper对象,这样一来Handler,Looper和线程之间就一一对应起来了。因此,无论handler在哪个线程发出消息,这个消息最终都会在handler初始化时所绑定的Looper所对应的线程中进行处理。

前面我们说过,Handler可以发出两种类型的消息,一种是通过sendMessage方法发送一个Message对象,另一种是通过post方法发送一个Runnable。我们先来看一下sendMessage方法和post方法的源码:

    public final boolean post(Runnable r)
    {
       return  sendMessageDelayed(getPostMessage(r), 0);
    }

    public final boolean sendMessage(Message msg)
    {
        return sendMessageDelayed(msg, 0);
    }

可以看到无论是post方法还是sendMessage方法最终都是调用的sendMessageDelayed方法,不同的是在post方法中先调用了getPostMessage方法来对Runnable对象进行了一些处理,我们来看一下getPostMessage方法:

    private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }

正如我们前面所说的,Handler将通过post方法提交的Runnable封装在了一个Message对象内的callback变量里。接下来我们看一下sendMessageDelayed方法:

    public final boolean sendMessageDelayed(Message msg, long delayMillis){
        if (delayMillis < 0) {
            delayMillis = 0;
        }
        return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
    }

    public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
        MessageQueue queue = mQueue;
        if (queue == null) {
            RuntimeException e = new RuntimeException(
                    this + " sendMessageAtTime() called with no mQueue");
            Log.w("Looper", e.getMessage(), e);
            return false;
        }
        return enqueueMessage(queue, msg, uptimeMillis);
    }

可见在sendMessageDelayed方法中又调用了sendMessageAtTime方法。而在sendMessageAtTime方法中,先拿取了初始化时绑定的MessageQueue对象,然后将这个MessageQueue和Message对象一起传给了enqueueMessage方法:

    private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
        msg.target = this;
        if (mAsynchronous) {
            msg.setAsynchronous(true);
        }
        return queue.enqueueMessage(msg, uptimeMillis);
    }

在enqueueMessage方法中,Handler将自身赋值给了Message的target变量,前面在讲loop方法的时候也说过,Message最终会通过这个target变量来获取对应的Handler,因此,Message最终会被发出该消息的Handler所处理。之后又调用了MessageQueue的enqueueMessage方法,最终将这个Message提交给了对应的MessageQueue对象。MessageQueue实际上是一个单链表型的数据结构,链表中的前一个元素都会持有下一个元素的引用,而MessageQueue只需要持有第一个元素的引用即可。看一下MessageQueue的enqueueMessage方法:

    boolean enqueueMessage(Message msg, long when) {
            ...
            msg.when = when;
            Message p = mMessages;//当前链表中的首个元素
            boolean needWake;
            if (p == null || when == 0 || when < p.when) {//如果链表中没有元素或者要插入的message的执行时间早于队列中的首个元素
                msg.next = p;
                mMessages = msg;
                needWake = mBlocked;
            } else {
                needWake = mBlocked && p.target == null && msg.isAsynchronous();
                Message prev;
                for (;;) {
                    prev = p;
                    p = p.next;
                    if (p == null || when < p.when) {
                        break;
                    }
                    if (needWake && p.isAsynchronous()) {
                        needWake = false;
                    }
                }
                msg.next = p; //
                prev.next = msg;
            }
            ...
        }
        return true;
    }

当插入一个新的Message时,MessageQueue首先会判断当前链表中是否存在元素,如果集合中的首个元素为null,那么就说明这个集合现在也是空的。如果集合中不存在元素,或新插入的Message不需要延时执行,或者要插入的Message的执行时间要早于集合中的首个元素的话,那么直接将链表中的首个元素设置为新插入的Message的下个元素,并将新插入的元素设置为队列中的首个元素。如果不满足上述条件的话,那么会从头开始遍历集合,根据Message的执行时间来将Message插入到集合中的相应位置。可见MessageQueue虽然名字中带有Queue,但并不是一个标准的队列,因为队列只允许在表的后端插入元素。

至此,一个Message就成功被Handler提交到了Message中了。

由于Android系统的消息机制比较复杂,本人技术水平非常有限,本文中难免会出现错误或者表达不准确的地方,希望大家能够帮忙指出,谢谢!
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章