PS一句：不得不说CSDN同步做的很烂，还得我花了近1个小时恢复这篇博客。

引言

【转载请注明出处：http://blog.csdn.net/feiduclear_up CSDN 废墟的树】

作为Android开发者，相信很多人都使用过Android的Handler类来处理异步任务。那么Handler类是怎么构成一个异步任务处理机制的呢？这篇

博客带你从源码分析Android的消息循环处理机制，便于深入的理解。

这里不得不从“一个Bug引发的思考”开始研究Android的消息循环处理机制。说来话长，在某一次的项目中，原本打算开启一个工作线程

WorkThread去执行一个耗时任务，然后在工作线程WorkThread中new一个Handler对象来发送消息。代码简化成如下：

private class WorkThread extends Thread {        private Handler mHandler;        @Override        public void run() {            mHandler = new Handler() {                @Override                public void handleMessage(Message msg) {                    switch (msg.what) {                        case 0:                            Log.e(TAG, 任务执行完成);                            break;                    }                }            };            //模拟一个耗时任务            try {                sleep(9000);            } catch (InterruptedException e) {                e.printStackTrace();            }            //任务执行完成之后发送一个消息            int what = 0;            mHandler.sendEmptyMessage(what);        }    }

当以上代码执行之后，很不幸的出现了如下的一个Bug：

从Handler+Message+Looper源码带你分析Android系统的消息处理机制_第1张图片

Log打印日志提示：不能在线程中没有调用 Looper.prepare()方法之前就去创建handler对象，言外之意就是，在线程中还没调Looper.prepare()

方法之前，你是不能去创建Handler对象的，否则抛出错误异常。为什么会这样呢？带着疑问，我们跟踪代码进入到Handler源码中的构造方法：

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;    }

代码第5-8行：我们发现当成员变量mLooper为空值时，就会抛出上面的异常了，意思就是刚才在WorkThread中创建Handler的时候mLooper是

空的，难道不可以这样创建Handler消息处理机制？那为什么在UI线程中直接new一个Hanlder对象不会出错呢？带着这种好奇心，我们今天来分

析一下Android系统消息处理机制有关的 Handler，Message，Looper，Thread类之间的关联。

Handler：消息的执行者，也可以称之为异步任务的执行者
Message：消息的封装者，把异步任务，消息码Handler对象等封装成Message对象
MessageQueue：消息队列，用于保存当前线程的所有消息Message对象的一个列表
Looper：循环者，能让工作线程变成循环线程，然后从消息队列中循环读取消息
Thread：异步任务或者耗时任务执行场所，一般开启一个新的工作线程处理耗时任务

消息的执行者–Handler

在Android的消息处理机制中，Handler扮演者重要的角色。Handler负责如下几个工作：

消息的发送消息的入列消息的调度/消息的分发消息的处理

1-1消息的发送

对于消息的发送，相信很多人平时用的最多的是Handler.sendEmptyMessage()，那么利用Handler发送的消息最终会发送到哪里呢？骚年不用YY了，源码会告诉你答案，我们跟踪Handler类中的sendEmptyMessage方法：

/**     * Sends a Message containing only the what value.     *       * @return Returns true if the message was successfully placed in to the      *         message queue.  Returns false on failure, usually because the     *         looper processing the message queue is exiting.     */    public final boolean sendEmptyMessage(int what)    {        return sendEmptyMessageDelayed(what, 0);    }/**     * Sends a Message containing only the what value, to be delivered     * after the specified amount of time elapses.     * @see #sendMessageDelayed(android.os.Message, long)      *      * @return Returns true if the message was successfully placed in to the      *         message queue.  Returns false on failure, usually because the     *         looper processing the message queue is exiting.     */    public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {        Message msg = Message.obtain();        msg.what = what;        return sendMessageDelayed(msg, delayMillis);    }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);    }

有以上代码发现，Handler消息的发送最终都会调用sendMessageAtTime成员方法。该方法首先判断当前Handler的成员变量mQueue是否为空，如果为空，则打印一个警告，并且返回false，表

示该消息发送失败。那么成员变量mQueue是神马东西呢？mQueue是MessageQueue对象，而MessageQueue类是一个消息队列，被Looper

对象持有。关于MessageQueue消息队列相关内容后面会展开分析。继续分析代码，如果消息队列不为空，则会调用enqueueMessage方法，跟踪代码进入该方法：

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

首先，将当前类Handler对象赋值给消息Message类中的target成员变量。然后调用消息队列MessageQueue类中的enqueueMessage方法将

该消息msg插入到消息队列中。这个过程称之为消息入列的一个过程。

1-2消息的入列

有1-1节可知，消息的入列是调用MessageQueue消息队列类中的enqueueMessage成员方法实现的，跟踪代码看看消息入列的具体实现

 boolean enqueueMessage(Message msg, long when) {        //判断消息的目标对象是否为空        if (msg.target == null) {            throw new IllegalArgumentException(Message must have a target.);        }        //判断消息是否正在使用        if (msg.isInUse()) {            throw new IllegalStateException(msg +  This message is already in use.);        }        synchronized (this) {            //判断是否正在清除消息队列            if (mQuitting) {                IllegalStateException e = new IllegalStateException(                        msg.target +  sending message to a Handler on a dead thread);                Log.w(MessageQueue, e.getMessage(), e);                msg.recycle();                return false;            }            //标记消息正在使用            msg.markInUse();            //对消息的延时处理时间幅值            msg.when = when;            //保存消息队列中的延时时间最小的那个消息            Message p = mMessages;            boolean needWake;            //条件判断，消息入列，将延时时间最小的那个消息赋值给mEssages变量            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 {                // Inserted within the middle of the queue.  Usually we don't have to wake                // up the event queue unless there is a barrier at the head of the queue                // and the message is the earliest asynchronous message in the queue.                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; // invariant: p == prev.next                prev.next = msg;            }            // We can assume mPtr != 0 because mQuitting is false.            if (needWake) {                nativeWake(mPtr);            }        }        return true;    }

分析：
1.代码第3行：判断当前入列的消息的目标处理对象是否为空，有1-1节我们知道msg.target的值是一个Handler实例。换言之，如果消息的目标处

理对象Handler为null，那么该消息就没有Handler去处理它，因此此处抛出一个异常

2.代码第7行：判断当前Message是否正在使用？如果是则抛出异常。说明一个相同的消息不可能同时存在同一个MessageQueue消息队列中。

3.代码第13行：判断当前消息队列是否正在退出？如果正在退出，则抛出异常，说明当前Message消息无法入列，因为MessageQueue消息队列退出了。

4.代码第27-52行：Message消息按照延时时间大小插入当前MessageQueue消息队列中，最终延时时间最短的消息在队列的最前面。

总结：到此，我们知道Handler将消息发送到消息队列MessageQueue中去了。那么这个消息队列MessageQueue是从哪里来

的呢？它属于谁呢？这里直接给出答案，MessageQueue消息队列是在Looper类中创建，Looper循环则持有当前线程中的消息队列

MessageQueue。至于为什么是这样，后面给出详细解释。

1-3消息的调度/消息的分发

有1-2小节我们知道，消息的执行者Handler将消息Message发送到消息队列MessageQueue中，并且消息队列中的所有消息都是按照时间排列。

那么在消息队列MessageQueue中的消息又是怎么分发出去的，或者说消息队列中的消息是怎么被消费掉的？现在我们来解答1-2小节中的最后一个问题，消息队列MessageQueue从哪里来？属于谁？在文章的一开头，

我们有“一个Bug引发的思考”知道了在线程中创建Handler对象之前需要调用Looper.prepare()，否则会抛出异常。那么我们就来分析一下Looper这个类：

/**  * Class used to run a message loop for a thread.  Threads by default do  * not have a message loop associated with them; to create one, call  * {@link #prepare} in the thread that is to run the loop, and then  * {@link #loop} to have it process messages until the loop is stopped.  *   * Most interaction with a message loop is through the * {@link Handler} class. * *This is a typical example of the implementation of a Looper thread, * using the separation of {@link #prepare} and {@link #loop} to create an * initial Handler to communicate with the Looper. * *  *  class LooperThread extends Thread {  *      public Handler mHandler;  *  *      public void run() {  *          Looper.prepare();  *  *          mHandler = new Handler() {  *              public void handleMessage(Message msg) {  *                  // process incoming messages here  *              }  *          };  *  *          Looper.loop();  *      }  *  }*/

分析：源码开头给出了一个很长的说明，大意是：Looper类作用是为一个线程构造消息循环的，因为线程Thread默认是不带消息循环的。因此

你可以调用Looper类中的prepare方法去为构造一个带消息循环的线程，并且调用Looper.loop()方法启动循环去循环处理消息，直到loop循环结

束。并且Google官方还提供了一个标准的构造一个带消息循环的线程实例，代码如下：

class LooperThread extends Thread {       public Handler mHandler;      public void run() {         Looper.prepare();          mHandler = new Handler() {              public void handleMessage(Message msg) {                  // process incoming messages here              }         };          Looper.loop();      } }

以上代码就是创建带消息循环的线程标准写法。那么我们来看看Looper.prepare()方法做了什么：

public final class Looper {    private static final String TAG = Looper;    // sThreadLocal.get() will return null unless you've called prepare().    static final ThreadLocal sThreadLocal = new ThreadLocal();    private static Looper sMainLooper;  // guarded by Looper.class    final MessageQueue mQueue;    final Thread mThread;    private Printer mLogging;     /** Initialize the current thread as a looper.      * This gives you a chance to create handlers that then reference      * this looper, before actually starting the loop. Be sure to call      * {@link #loop()} after calling this method, and end it by calling      * {@link #quit()}.      */    public static void prepare() {        prepare(true);    }    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));    }}

分析：
1.代码第24行：调用sThreadLocal.get()获得存储在本地线程中的Looper值，如果本地线程ThreadLocal中有当前的Looper对象，者会抛出一个异

常：”Only one Looper may be created per thread”每一个线程只能有一个Looper对象。所以每一个线程只能拥有一个Looper对象，关于ThreadLocal类，这里不展开学习，主要作用是将Looper对象存储在本地线程ThreadLocal中。

2.代码第27行：将当前的Looper对象保存在本地线程对象ThreadLocal中。至此，Looper的准备工作就完成了。

Looper的准备工作完成之后，我们来看看Looper的启动方法Looper.loop(),进入loop()方法代码如下：

 /**     * Run the message queue in this thread. Be sure to call     * {@link #quit()} to end the loop.     */    public static void loop() {        final Looper me = myLooper();        if (me == null) {            throw new RuntimeException(No Looper; Looper.prepare() wasn't called on this thread.);        }        final MessageQueue queue = me.mQueue;        // Make sure the identity of this thread is that of the local process,        // and keep track of what that identity token actually is.        Binder.clearCallingIdentity();        final long ident = Binder.clearCallingIdentity();        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();        }    }

分析：注释开头就描述了，该方法的作用是为了在线程中构建一个消息循环机制，当然你可以调用Looper类中的quit()成员方法结束当前loop循环。

代码第10行：获得当前线程Thread的消息队列并且赋值给本地变量queue。

代码第17-49行：构建一个死循环来遍历当前Looper中的消息队列。

代码第18-22行：每次遍历都获取消息队列中最前端的消息，也就是延时时间最短的消息。当从消息队列中获取的消息为空，则说明该消息队列已经退出。

代码第31行：这一行是重点，此处调用了当前消息的目标对象去分发消息。有1-1小节的最后一段我们知道，消息队列的目标对象就是Handler对象，因此这里就是调用Handler去调度消息或者叫分发消息。有此处也看出来，Message消息是有哪个Handler发送的，就有哪个Handler去分发消息。

跟踪代码进入

msg.target.dispatchMessage(msg);

以上方法在Handler类中

 /**     * Handle system messages here.     */    public void dispatchMessage(Message msg) {        if (msg.callback != null) {            handleCallback(msg);        } else {            if (mCallback != null) {                if (mCallback.handleMessage(msg)) {                    return;                }            }            handleMessage(msg);        }    }

该方法就是处理系统消息的地方，以上代码有三个分支，我们先看最后一个分支，就是执行handleMessage(msg);方法，跟踪代码：

/**     * Subclasses must implement this to receive messages.     */    public void handleMessage(Message msg) {    }

我擦，这么简单，就一个空方法？那怎么处理消息呢？注释已经告诉我们了，Handler的子类必须重写该方法用来接收消息，也就是说最后的消息

处理逻辑是延伸给Handler类的之类了。相信读者对该方法应该不陌生吧，就是我们经常在实现Handler类中重写的那个方法，消息的处理就在这个方法里面实现了。

到此，消息的调用/消息的分发就结束了，最后通过一个空方法将消息的处理逻辑留给了Handler的之类。

1-4消息的处理

消息有以上三步操作，最后进入消息的处理阶段，这里就到了我们非常熟悉的地方了，消息的处理是留给我们Handler子类去实现的，也就是我们平时编写Handler消息那样：

public Handler mHandler;mHandler = new Handler() {         public void handleMessage(Message msg) {             // process incoming messages here        }};

Handler消息执行过程总结：

下面用一张图来描述消息的发送，消息的入列，消息的分发，消息的处理四个过程。

从Handler+Message+Looper源码带你分析Android系统的消息处理机制_第2张图片

有线程中的Handler把Message类封装的消息发送到当前线程的Looper对象中的消息队列MessageQueue中，然后Looper遍历循环消息队列MessageQueue，从消息队列中取出消息，通过target Handler将消息分发出去，最后当前线程中的Handler获取到该消息，并对消息进行处理。

Handler有关的构造方法

分析Handler类源码发现，Handller类有很多个构造方法。爱思考的你肯定会问，这些构造方法有什么不同呢？那么我们就从代码中来分析他们之间的不同吧：

2-1 不带参的构造方法

 private Handler mHandler = new Handler() {        @Override        public void handleMessage(Message msg) {            //接收消息之后，处理消息        }    };

我们一般在UI线程中这么来实例化一个Handler对象，然后通过重写Handler类中的handleMessage（Message msg）方法来处理消息。

2-2带一个参数Callback的构造方法

private Handler handler1 = new Handler(new Handler.Callback() {        @Override        public boolean handleMessage(Message msg) {            //接收消息之后，处理消息            return true;        }    });

此处的Callback参数是Handler类的内部回调接口，我们通过实现Callback接口中的handleMessage(Message msg)方法来处理消息。

2-3带两个参数的构造方法

 private Handler handler2 = new Handler(Looper.myLooper(), new Handler.Callback() {        @Override        public boolean handleMessage(Message msg) {            //TODO 接收消息之后，处理消息            return true;        }    });

第一个参数是当前线程的Looper对象，第二个参数是Callback接口，消息的处理和2-2小节一样，唯一不同的地方就是多了一个Looper参数。

总结

由1-3小节我们发现，Handler类中的dispatchMessage方法分发消息有几种情况：

 /**     * Handle system messages here.     */    public void dispatchMessage(Message msg) {        //第一种处理消息方式        if (msg.callback != null) {            handleCallback(msg);        } else {            if (mCallback != null) {                //第二种处理消息方式                if (mCallback.handleMessage(msg)) {                    return;                }            }            //第三种处理消息方式            handleMessage(msg);        }    }

1.而当你使用2-1小节的构造方法创建Handler对象时，就是采用上面代码中的第三种处理消息的方式了，即重写Handler类中的handleMessage(msg)方法。

2.当你使用2-2和2-3小节的构造方法创建Handler对象时，就采用上面代码中的第二中处理消息的方式，即实现Handler类中的Callback接口中的

handleMessage(msg)方法。值得注意的是，如果Callback接口回调处理消息返回值是false的话，此消息还会调用第三种处理消息方式，因此没有特殊需求，我们一般在实现Callback接口回调方法时都返回true。

3.那么上面代码第一种处理消息的方式handleCallback(msg)是什么时候触发的呢？上面代码加了一个if条件判断，只有当msg消息中的成员变量

callback不为空时才调用该方式处理消息。那什么时候callback不为空呢？带着这个问题继续分析Handler发送消息的方法。

Handler发送消息的方法

handler发送消息的方法有多达11种，一听吓一跳，这么多方法怎么区分？不用怕，我把这些方法分为如下两类。

send系列
post系列

3-1 send系列

 private Handler mHandler = new Handler() {            @Override            public void handleMessage(Message msg) {            //接收消息之后，处理消息            }        };        Message msg = mHandler.obtainMessage();        //发送一个消息码为0的空消息        mHandler.sendEmptyMessage(0);        //发送一个消息码为0，绝对时间点为1000ms的空消息，该时间应该大于等于当前时间，下同        mHandler.sendEmptyMessageAtTime(0, 1000);        //发送一个消息码为0，延时时间为1000ms的空消息        mHandler.sendEmptyMessageDelayed(0, 1000);        //发送一个没有延时的msg封装的消息        mHandler.sendMessage(msg);        //发送一个绝对时间点为1000ms的msg封装的消息        mHandler.sendMessageAtTime(msg, 1000);        //发送一个延时时间为1000ms的msg封装的消息        mHandler.sendMessageDelayed(msg, 1000);        //立即发送一个msg封装的消息到消息队列的最前端        mHandler.sendMessageAtFrontOfQueue(msg);

分析源码你会发现，除了最后一个方法，以上所有的方法最后都会调用如下方法：

/**     * Enqueue a message into the message queue after all pending messages     * before the absolute time (in milliseconds) uptimeMillis.     * The time-base is {@link android.os.SystemClock#uptimeMillis}.     * Time spent in deep sleep will add an additional delay to execution.     * You will receive it in {@link #handleMessage}, in the thread attached     * to this handler.     *      * @param uptimeMillis The absolute time at which the message should be     *         delivered, using the     *         {@link android.os.SystemClock#uptimeMillis} time-base.     *              * @return Returns true if the message was successfully placed in to the      *         message queue.  Returns false on failure, usually because the     *         looper processing the message queue is exiting.  Note that a     *         result of true does not mean the message will be processed -- if     *         the looper is quit before the delivery time of the message     *         occurs then the message will be dropped.     */    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);    }

分析：以上注释都解释的很清楚，第一个参数就是Message类封装的消息，第二个参数就是消息的更新时间，该时间是绝对时间。

3-2 post系列

  mHandler = new Handler();        mHandler.post(new Runnable() {            @Override            public void run() {                //TODO 接收消息之后，处理消息            }        });        mHandler.postAtTime(new Runnable() {            @Override            public void run() {                //TODO 接收消息之后，处理消息            }        }, new Object(), 1000);        mHandler.postDelayed(new Runnable() {            @Override            public void run() {                //TODO 接收消息之后，处理消息            }        }, 1000);        mHandler.postAtFrontOfQueue(new Runnable() {            @Override            public void run() {                //TODO 接收消息之后，处理消息            }        });

分析：和send系列大有不同，此处我们的Handler无需在去重写handlerMessage方法来处理消息了，此处将接口类Runnable作为消息发送，然后实现Runnable接口类中的run方法来处理消息。对于这一点我相信很多初学者会有疑问，这里又没有Message封装消息，怎么将Runnable接口类当作消息发送呢？一句话，还是跟踪源码看看：

  /**     * Causes the Runnable r to be added to the message queue, to be run     * at a specific time given by uptimeMillis.     * The time-base is {@link android.os.SystemClock#uptimeMillis}.     * Time spent in deep sleep will add an additional delay to execution.     * The runnable will be run on the thread to which this handler is attached.     *     * @param r The Runnable that will be executed.     * @param uptimeMillis The absolute time at which the callback should run,     *         using the {@link android.os.SystemClock#uptimeMillis} time-base.     *      * @return Returns true if the Runnable was successfully placed in to the      *         message queue.  Returns false on failure, usually because the     *         looper processing the message queue is exiting.  Note that a     *         result of true does not mean the Runnable will be processed -- if     *         the looper is quit before the delivery time of the message     *         occurs then the message will be dropped.     *              * @see android.os.SystemClock#uptimeMillis     */    public final boolean postAtTime(Runnable r, Object token, long uptimeMillis)    {        return sendMessageAtTime(getPostMessage(r, token), uptimeMillis);    }

分析：不管post系列调用哪个方法，最终都会调用上面这个方法来发送消息，你会惊奇的发现，原来post系列也是调用send系列的方法发送方法的。只不过此处调用了getPostMessage方法将Runnable对象转换成Message对象而已。跟踪代码进入getPostMessage方法：

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

看到没？调用此方法，将Runnable对象r赋值给了Message类中的clalback成员变量。现在我们回顾一下2-3小节Handler类中的

dispatchMessage方法处理消息的三种方式，此处将Runnable接口对象赋值之后Message类中的msg.callback就不会为空，因此调用第一种处理消息的方式。

第3节总结：

不管3-1或者3-2小节调用那种方式发送消息，最终都会调用Handler类中的enqueueMessage成员方法，将消息按照消息更新时间顺序插入到消息队列中，这个过程的分析可以参考1-1小节最后一段内容。

在Message消息封装者类中有这么一段注释：

 /*While the constructor of Message is public, the best way to get * one of these is to call {@link #obtain Message.obtain()} or one of the * {@link Handler#obtainMessage Handler.obtainMessage()} methods, which will pull * them from a pool of recycled objects*/

这段话告诉我们，当你需要构造一个Message消息对象的时候，最好的方法是调用Message.obtain()或者Handler.obtainMessage()方法来获得，而不是这样获得：

Message msg1 = new Message();

为什么这样获得Message对象不好？我们跟踪源码瞧瞧不就知道了。

/**     * Return a new Message instance from the global pool. Allows us to     * avoid allocating new objects in many cases.     */    public static Message obtain() {        synchronized (sPoolSync) {            if (sPool != null) {                Message m = sPool;                sPool = m.next;                m.next = null;                m.flags = 0; // clear in-use flag                sPoolSize--;                return m;            }        }        return new Message();    }

这是一个Message类中的静态方法，方法开头解释的很清楚：从全局的消息池中获得一个新的消息示例，避免用户多次创建Message消息实例浪费

内存。只有当全局的消息池中没有可用的消息实例，才去调用new 一个新的Message消息实例。总之，归纳成一句话，调用Message.obtain()或

者Handler.obtainMessage()方法避免多次创建Message实例，这样性能更加优化。

Handler移除消息的方法以及Handler内存泄漏问题

方法包括如下：

//从消息队列中移出post系列方法中Runnable对象的消息 mHandler.removeCallbacks(Runnable r); //从消息队列中移除消息码为“what”的消息 mHandler.removeMessages(int what); //从消息队列中移除所有post系列方法和send系列方法发送的消息 mHandler.removeCallbacksAndMessages(Object token);

可能很初学者会有疑问，开发中很少用到以上这些方法。那如果你很少使用以上方法，说明你还是一个Android小白。如果不调用以上相应的方法

去移除消息，就会存在Handler对象内存泄漏的隐患。此话怎讲？我在一次项目开发中遇到这样的问题：

我开启一个新的工作线程WorkThread去执行一段耗时网络请求，当请求结束之后我调用UI线程中的Handler发送一个Message消息给UI线程，但

是此时，我早已经退出当前持有Handler对象的Activity，这会持有Handler的Activity是接收不到WorkThread发送过来的消息的，因为

Activity已经退出，因此会出现一个bug：Handler对象内存泄露。那怎么解决这个Handler内存泄露隐患呢？

4-1

很简单，在持有Handler对象的Activity的onDestory方法调用如下代码去移除消息队列中的所有消息

mHandler.removeCallbacksAndMessages(null);

此方法只要传递一个null空参数就表示移出当前线程中消息队列中所有的消息。有些人可能会说，我并不想清除消息队列，可能还有其他Activity等待接收消息，好办。你可以调用如下相应的方法移除消息队列中相应的消息：

//从消息队列中移出post系列方法中Runnable对象的消息 mHandler.removeCallbacks(Runnable r); //从消息队列中移除消息码为“what”的消息 mHandler.removeMessages(int what);

4-2

那么我们是否还有其他办法解决Handler内存泄漏问题呢？答案是肯定的：将Handler申明为静态的，因为静态类不持有外部类的引用。

public class SubActivity extends Activity {  static class StaticHandler extends Handler {        WeakReference mActivityReference;        StaticHandler(Activity activity) {            mActivityReference= new WeakReference(activity);        }        @Override        public void handleMessage(Message msg) {            final SubActivity activity = (SubActivity) mActivityReference.get();            if (activity != null) {                activity.textView.setText(测试静态Handler解决内存泄漏问题);            }        }    }}

UI线程在使用Handler之前不需要Looper.prepare的原因

文章一开头由“一个Bug引发的思考”我们知道，在线程中使用Handler之前需要调用Looper.prepare方法。爱思考的你会很纳闷，那为什么我

们的UI线程在创建Handler对象的时候没有调用Looper.prepare方法呢？此时我们不得不从UI线程是怎么来的说起了。不过这里不展开讨论，直接给出答案，我们创建一个Application的时候，都是由系统的一个ActivityThread类来启动的。跟踪代码进入ActivityThread类：

public final class ActivityThread {...................    public static void main(String[] args) {            ..............            Looper.prepareMainLooper();            ..............    }}

该类中有一个main方法，是不是感觉很熟悉啊？对了，这里就是我们整个Application应用的入口了。在main方法中调用了Looper.prepareMainLooper()，猜测该方法里面就调用了Looper.prepare方法来为线程循环loop准备。跟踪源码：

public static void prepareMainLooper() {        prepare(false);        synchronized (Looper.class) {            if (sMainLooper != null) {                throw new IllegalStateException(The main Looper has already been prepared.);            }            sMainLooper = myLooper();        }    }

果然，里面调用了prepare方法。到此，我们就知道其实在UI线程中系统在ActivityThread类中就帮我们调用了Looper.prepare方法为UI线程loop循环做准备。

HandlerThread帮你创建循环消息处理机制

你可能会遇到这样一种情况，在UI线程中创建一个工作线程WorkThread执行耗时任务。在正常情况下，这个WorkThread执行完任务之后就销毁

了。但是你过了一段时间又有一个耗时任务需要执行，这会你会怎么办？你只能重新去创建一个WorkThread执行耗时任务。但是线程Thread的每

次创建和销毁都是很耗系统资源的，因此在这种情况下，我们的HandlerThread就此诞生了。HandelrThread是继承自Thread实现了，

也就是说HandlerThread是一个线程。只是该线程里面帮你实现了Looper循环机制，从而使得该线程变成带有循环机制的线程。言外之

意：当该线程执行完一个耗时任务之后不会马上被销毁，除了用户主动调用HandlerThread类中的quit成员方法来退出当前loop循环。关于

HandlerTread是怎么使用的？可以参考我的另一篇博客：
http://blog.csdn.net/feiduclear_up/article/details/46840523

总结：

通过以上文章分析，基本了解了Android系统的消息处理机制是怎么一回事，也知道了怎么使用Handler，以及Handler使用的一些陷阱等。来总结一下 Handler，Message，Looper，MessageQueue，Thread之间的关联吧。

如果一个线程Thread想要使用Handler类来发送消息，就必须先调用Looper类中的prepare成员方法来做一些准备工作，然后调用Looper类

中的loop方法启动该线程的循环机制。Handler类把封装成Message类的消息发送到Looper类中的消息队列中，然后Looper类中的loop循环方法

中分发消息，最后将相应的消息对象分发到相应的target handler类中去处理消息。

由此我们知道：一个线程Thread中只能拥有一个Looper对象，且一个Looper对象中只能拥有一个MessageQueue消息队列，但是一个Thread

线程中可以有多个Handler对象，而多个Handler对象共享同一个MessageQueue消息队列。最后提供一个Handler消息处理机制的流程图

从Handler+Message+Looper源码带你分析Android系统的消息处理机制_第3张图片