码迷,mamicode.com
首页 > 其他好文 > 详细

Handler异步消息处理机制,从源代码看起

时间:2016-07-22 19:22:08      阅读:245      评论:0      收藏:0      [点我收藏+]

标签:

转载注明出处:http://blog.csdn.net/xiaohanluo/article/details/51994401
简书链接:http://www.jianshu.com/p/e72aba99012a

简介

在Android开发中经常会遇见异步消息处理的情况,特别是网络请求成功或者失败之后需要更新UI,但是更新UI只能在UI线程里面进行,否则就会报错,这个时候就需要通知UI线程去更新UI,于是Handler出现了。

Handler的使用

Handler的使用非常简单,直接看例子。

    private static final int KEY_REQUEST_SUCCESS = 0x01;

    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
              //这里是在UI线程了
            if(msg.what == KEY_REQUEST_SUCCESS) {
                //更改UI
            }
        }
    };

    ... ...//一些其他操作

    private void changeUI() {
        Message message = mHandler.obtainMessage();
        message.what = KEY_REQUEST_SUCCESS;

        mHandler.sendMessage(message);
    }

声明了一个Handler成员变量mHandler,并复写了其中的handleMessage(Message msg)方法,然后使用mHandler发送一条消息,最终会调用到handleMessage方法,然后进行UI更新操作。

看见这么好用的异步消息处理方法,肯定会去看看内部是怎么实现消息的调度的。

Handler内部信息调度

消息进入队列

所有的消息都是使用sendMessage方法发送出去(还有其他类似方法),就从sendMessage开始查看。

    public final boolean sendMessage(Message msg)
    {
        return sendMessageDelayed(msg, 0);
    }
    ...
    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) {
            //异常处理
        }
        return enqueueMessage(queue, msg, uptimeMillis);
    }
    ...
    private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
        msg.target = this;
        if (mAsynchronous) {
            msg.setAsynchronous(true);
        }
        return queue.enqueueMessage(msg, uptimeMillis);
    }

我们可以看到,Handler发送消息最终都会调用到sendMessageAtTime方法,在这个方法里面就做了一件事,将消息放入一个消息队列中。记住msg.target这个赋值操作,然后我们去看看在放入队列时候都做了些什么。

    boolean enqueueMessage(Message msg, long when) {
        //异常处理
        synchronized (this) {
            //异常处理

            msg.markInUse();
            msg.when = when;
            Message p = mMessages;
            boolean needWake;
            if (p == null || when == 0 || when < p.when) {
                // New head, wake up the event queue if blocked.
                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;
            }

            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }

从代码中很清晰的可以看见。

  • 如果新消息首次加入队列,或者新消息延迟时间要小于队列首个消息延迟时间,就将新消息放在队列首部。
  • 如果队列不为空,新消息延迟时间并不是最短,就将新消息插入到队列的某个位置。

总之,新消息插入队列后,消息队列是按延迟时间长短排序的一个有序队列,延迟时间越短,越靠近队列首部。这样,就可以猜测,系统一次拿去队列中的消息,然后进行分发处理。

消息调度分发

我们都知道了消息被加入了一个按延迟长短排序的有序队列,消息仅仅加入了队列还需要有地方处理才行,那我们就看看哪里处理了这个队列。
首先我们来查看一下Handler的成员变量中的MessageQueue是在哪里初始化或者赋值的,从源头开始查找,顺藤摸瓜。

    public Handler() {
        this(null, false);
    }
    ...
    public Handler(Callback callback, boolean async) {
        ...
        mLooper = Looper.myLooper();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can‘t create handler inside thread that has not called Looper.prepare()");
        }
        mQueue = mLooper.mQueue;
        mCallback = callback;
        mAsynchronous = async;
    }

原来是直接用Looper赋值的,那会不会对这个消息队列的处理就在Lopper当中呢?赶紧去看看。Looper的代码不多,很快就看到了loop()这个方法。

    public static void loop() {
        final Looper me = myLooper();

        //异常处理

        for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }

            // This must be in a local variable, in case a UI event sets the logger
            Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }

            msg.target.dispatchMessage(msg);

            if (logging != null) {
                logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
            }

            // Make sure that during the course of dispatching the
            // identity of the thread wasn‘t corrupted.
            final long newIdent = Binder.clearCallingIdentity();
            if (ident != newIdent) {
                Log.wtf(TAG, "Thread identity changed from 0x"
                        + Long.toHexString(ident) + " to 0x"
                        + Long.toHexString(newIdent) + " while dispatching to "
                        + msg.target.getClass().getName() + " "
                        + msg.callback + " what=" + msg.what);
            }

            msg.recycleUnchecked();
        }
    }

就是在这里!!在loop()方法中有一个循环一直在取出消息队列中的消息然后进行分发工作。我们注意这一行代码msg.target.dispatchMessage(msg),调用了msg.tartget中的一个分发消息的方法,还记得在上面消息进入消息队列时候,注意的msg.target的赋值操作吗?msg.target其实就是我们发送消息的Handler!!!赶紧去查看一下消息分发和处理过程吧。

消息处理

直接去查看Handler中的dispatchMessage(msg)方法,发现这个方法比较简单。

    public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

很容易理解如果Message和Handler的CallBack成员变量都为空的话,直接调用Handler本身的handlerMessage(Message msg)方法,这个方法就是我们在实例化Handler时候复写的一个方法,最终消息的具体处理过程就回到了我们手中。

调度图

技术分享
Handler发送Message消息,消息进入消息队列,Looper不断的从消息队列中取出Message,然后交给Handler处理,处理的代码交给用户处理。这样我们就可以在非UI线程中发送Message消息,但是最终的处理回到了UI线程,进行一些UI操作。

其他用法

虽然Handler是用于处理异步消息的,但是由于它本身有一个延迟的功能,所以Handler也可以做一个定时任务处理器,类似广告结束倒计时等等都可以用到Handler。

Tips

Handler虽然看起来使用简单,但是如果仔细的话,会发现,这一套机制对Message的管理是非常严格的。将消息从消息队列中删除或者消息处理完毕之后,并不是直接将Message舍弃,而是调用了Message本身的recycleUnchecked()方法。

    void recycleUnchecked() {
        // Mark the message as in use while it remains in the recycled object pool.
        // Clear out all other details.
        flags = FLAG_IN_USE;
        what = 0;
        arg1 = 0;
        arg2 = 0;
        obj = null;
        replyTo = null;
        sendingUid = -1;
        when = 0;
        target = null;
        callback = null;
        data = null;

        synchronized (sPoolSync) {
            if (sPoolSize < MAX_POOL_SIZE) {
                next = sPool;
                sPool = this;
                sPoolSize++;
            }
        }
    }

首先将Message里面一些成员变量进行了重置操作,在最后面我们发现了MAX_POOL_SIZE这个属性!!这说明在这一套机制中,Message数量是有上限的。心细的人就会发现,如果每次使用Message时候都使用new实例化一个的话,总会有一个时间点,Message数量会超出最大限制数。
所以我们在获取Message的时候,一定要使用Handler.obtainMessage()方法或者Message.obtain(Handler h)方法。

如果使用new去实例化Message的话,这里面有坑,慎重。

Q&A

Looper类的loop()方法处理完队列之后就会停止循环,如果有新的消息加入,系统是怎么调用到Looper的loop()的呢?

在将信息加入到消息队列后,会运行nativeWake(mPtr)这一行代码,nativeWake()是一个本地的方法,是通过这个方法在系统的底层去调用Looper.loop()方法。

由Handler发送出一个延迟任务消息,这个消息还未被处理,怎么撤回?

Handler撤回消息有五种方法。

  • removeCallbacks(Runnable r)
  • removeCallbacks(Runnable r, Object object)
  • removeMessages(int what)
  • removeMessages(int what, Object object)
  • removeCallbacksAndMessages(Object object)

但是实际上是在MessageQueue队列中删除了消息,MessageQueue提供了三种删除消息方法

  • removeMessages(Handler h, int what, Object object)
  • removeMessages(Handler h, Runnable r, Object object)
  • removeCallBackAndMessage(Handle h, Runnable r, Object object)

参数都是Message中的成员变量(Handler参数会在Handler调用MessageQueue删除消息方法传入,也就是Handler本身),当传入参数与Message中属性相等时候会将消息从消息队列中删除。参数object是补充条件,object传入null,则前面条件满足即可;object不为空,所有条件都需要满足。

    void removeCallbacksAndMessages(Handler h, Object object) {
        if (h == null) {
            return;
        }

        synchronized (this) {
            Message p = mMessages;

            // Remove all messages at front.
            while (p != null && p.target == h
                    && (object == null || p.obj == object)) {
                Message n = p.next;
                mMessages = n;
                p.recycleUnchecked();
                p = n;
            }

            // Remove all messages after front.
            while (p != null) {
                Message n = p.next;
                if (n != null) {
                    if (n.target == h && (object == null || n.obj == object)) {
                        Message nn = n.next;
                        n.recycleUnchecked();
                        p.next = nn;
                        continue;
                    }
                }
                p = n;
            }
        }
    }

从代码中很容易看出来,如果调用MessageQueue的removeCallbacksAndMessage方法时候,object传入是null,会将消息队列中所有消息都给清空。所以这样调用mHandler.removeCallbacksAndMessage(null)时候,会清空消息队列中所有信息。

待完善…

Handler异步消息处理机制,从源代码看起

标签:

原文地址:http://blog.csdn.net/xiaohanluo/article/details/51994401

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!