分析Android中Handle机制

上次浅分析了android中的绘画机制，今天我们来谈谈，android中的Handle机制。在一开始学习Android的时候，总会遇见一个问题，更新UI只能在主线程中进行，而有时候做耗时操作（耗时操作要在分线程中进行）后要去更新UI，就不可避免的用到了Handle。

例如：

class myThread extends  Thread{   @Override    public void run() {        Message msg = Message.obtain();        msg.obj = "请求后的数据";        msg.what = 1;//消息表示        handle.sendMessage(msg);    }}

通过handle发送消息，然后在handle中处理消息

 Handler handle = new Handler(){    @Override    public void handleMessage(Message msg) {        if(msg.what == 1){            text.setText((String)msg.obj);        }    }};

这样就可以解决在分线程中做耗时操作后要更新UI的问题，当然，在分线程中更新UI的方式有很多种，还可以用runOnUiThread()方法，还可以用rxjava等等。

当我第一次用handle之后，心中就一直有一个疑问：Handle到底经历了什么？我调用的sendMessage方法，但是在handle中处理消息却是在handleMessage方法中，这是为什么？

这个疑问一直在我心中不断积累，直到有一天我点击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) {       RuntimeException e = new RuntimeException(               this + " sendMessageAtTime() called with no mQueue");       Log.w("Looper", e.getMessage(), e);       return false;   }   return enqueueMessage(queue, msg, uptimeMillis);}

追踪到sendMessageAtTime方法，终于有一丝丝真想浮出水面了。获取到当前Handle的MessageQueue对象，然后调用enqueueMessage方法。

首先，我们得知道，MessageQueue是什么？MessageQueue是一个消息队列，在MessageQueue里面拥有Message对象，Message是不是很眼熟，就是我们在sendMessage的传入参数嘛！！！所以我们猜测Handle里的enqueueMessage就是往MessageQueue插入Meassage的方法！

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

上面的代码是Handle的enqueueMessage方法！这里又浮现出一些真相！msg.target指向了自身handle对象。请大家记住这一行代码！然后调用了MessageQueue 的enqueueMessage方法，那是真正插入消息真正实现！

这里先谈一谈MessageQueue这个类。我们一直在说MessageQueue是消息队列。但是它却可以做一件在生活中令人讨厌的事情，就是插队！

在学数据结构的时候大家都知道，队列的原则是先进先出，而它却可以插队！！！有时候在排队火车票，总有人插到最前面，说他很急，火车还有10分钟就开车了，能不能给他让一下，让他先拿票。这样的行为是不是不好的？这是一个让我思考了很久的问题，至今也没有答案，因为就算排在开头的人同意插在他的前面，但是同时也插了全部人的前面啊，不单单只插了他！

后来我也插了一次队，也是同样的情况——真的很急！，但是这样对还是不对，我也不知道，想不清。

好，从生活中回来，在数据结构中，既然定义了队列是先进先出，但是MessageQueue却违反了这个定义，它是个假队列。

好，来看看这个加队列的底层是如何实现的呢？

在学习数组和链表的时候，总会被问：数组和链表的各自优势是什么？
数组的优势是：存储时耗的内存小，随机访问性强。
链表的优势是：插入和删除数据消耗的内存比较小，灵活性强。

我们知道，MessageQueue这个家伙是可以插队的，那么我们猜测，它的实现是用链表来实现的。

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) {          //下面这三行语句是插入队列的方法          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; // invariant: p == prev.next          prev.next = msg;      }      // We can assume mPtr != 0 because mQuitting is false.      if (needWake) {          nativeWake(mPtr);      }  }  return true;}

这里又出现了真相，平时我们在发送消息时，可以选择发送即时消息，也可以选择发送延期消息，延期消息需要带有一个时间。这里的代码就是在插入队列时关于延迟消息和即时消息的不同。

这里证明了我们的猜测，在插入即时消息和延迟消息的时候，是链表的插入操作。MessageQueue里面拥有Message对象，可以去看看Message对象，Message就是一个链表。

到这里总结一下，我们在自己的创建的handle中调用sendMessage方法，然后系统调用：

sendMessageAtTime ——> 获取当前的MessageQueue，并且调用Handle的enqueueMessage方法。

Handle的enqueueMessage ——>把当前Handle对象放入Message.target中，然后调用MessageQueue.enqueueMessage方法

MessageQueue的enqueueMessage ——> 根据不同的情况去做不同的插入消息操作。详细请看上面代码备注！

看到这里，还有两个疑问啊
疑问一：MessageQueue在哪里被创建？
疑问二：消息在哪里被拿出来处理？

请思考一个问题，我们在开发的时候，在分线程创建Handle会报错，在错误信息中，会提示要调用Looper.prepare()和Looper.loop()方法。

我们的第二个疑问，“消息在哪里被拿出来处理？”是啊，这里的错误就是在和开发者说：“消息没有地方可以处理！”

来，如果我们在分线程中创建Handle，那么分线程是没有消息处理的能力的（除非调用Looper.prepare()和Looper.loop()）。所以报错了。

那么，主线程中为什么就有消息的处理能力呢？

好，我们去看看主线程。在我们点击android的桌面图标后，系统底层会自动开辟一个进程，和一个线程，然后调用ActivityThread的main方法。（注意：ActivityThread并没有继承Thread）。

public static void main(String[] args) {    .....    //调用了prepare()    Looper.prepareMainLooper();    ActivityThread thread = new ActivityThread();    thread.attach(false);    if (sMainThreadHandler == null) {        sMainThreadHandler = thread.getHandler();    }    if (false) {        Looper.myLooper().setMessageLogging(new                LogPrinter(Log.DEBUG, "ActivityThread"));    }    // End of event ActivityThreadMain.    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);    //看这，看这    Looper.loop();    throw new RuntimeException("Main thread loop unexpectedly exited");}

看到了吧！！！系统在就帮我们调用了Looper.prepare()和Looper.loop()，所以我们才会用得那么的爽！

拥有好奇心的人一定要一步一步的往下问：那么为什么要调用Looper.prepare()和Looper.loop()才能当前线程才有处理消息的能力呢？

好，进去Looper.perpare()中看看！

private static void prepare(boolean quitAllowed) {    if (sThreadLocal.get() != null) {        throw new RuntimeException("Only one Looper may be created per thread");    }    //创建Looper对象，并且设置在当前线程里    sThreadLocal.set(new Looper(quitAllowed));}

prepare先判断当前线程有没有Looper对象，如果有，就报异常！所以，每一个线程都只能调用一次Looper.prepare方法！

然后创建Looper对象，并且设置在当前线程里，那就再看看Looper的构造方法。

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

构造方法做了两件事：
第一件事：创建了MessageQueue对象。
第二件事：把loop标识当前线程。（为了以后做线程操作的限制）

我们上面提出两个疑问：第一个疑问是Handle的MessageQueue对象哪里被创建了，就是在这里被创建了！！！而如何引用过去呢？去看看Handle的构造方法，就知道了，就不在做分析。

Looper.perpare()解决了第一个疑问，那么Looper.loop()就是解决了第二个疑问：消息在哪里被拿出来处理？

进去看看。

public static void loop() {    final Looper me = myLooper();    ...    final MessageQueue queue = me.mQueue;    ...    for (;;) {      Message msg = queue.next(); // might block       if (msg == null) {           //消息为null则退出           //如果是主线程，不可能MessageQueue.next不可能返回null           return;       }       ....//省略日志输出代码       //处理消息       msg.target.dispatchMessage(msg);       ....//省略日志输出代码       //回收消息，放入消息池中       msg.recycleUnchecked();   }}

ok，一切都明了！首先，有一个死循环来处理消息。先在消息队列中取出消息，然后处理消息，然后回收消息。

还记的在发送sendMessageAtTime中msg.target引用了我们把本身handle吗？所以msg.target.dispatchMessage(msg)相当于调用了本身handle的dispatchMessage(msg)方法！

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

如果有Callback就调用CallBack方法，如果没有就调用handlemessage方法。绕了一圈，终于给绕回来了。

我这么分析，是因为我们没有办法一开始就捉住源头。一开始呈现在我们眼前的只有冰山的一角，就只有sendMessage()，而同时，这样也容易记忆，也会有探寻的感觉！

总结一下

首先，在App运行之后，c++会帮我们调用ActivityThread的main方法。

1. Looper.prepareMainLooper(); ——> prepare(false);——>创建Looper对象，Looper构造方法创建MessageQueue，如果是主线程则设置队列为不可退出，Looper拿到MessageQueue的引用。然后在looper设置给当前线程变量。
   因为prepare()方法一个线程只能被调用一次，所以一个线程只能有一个Looper，所以也只能有一个MessageQueue。

2. Looper.loop();——>拿到当前线程的Looper，拿到Looper中的MessageQueue，然后往MessageQueue拿Message消息，然后调用Message.target.dispatchMessage处理消息。

3. 我们平时在使用Handle的时候，创建Handle 然后sendMessage的本质是在向当前线程MessageQueue插入消息

4. 所以， Handle机制就像是：求救！怎么说？我和我的好朋友，中间相隔一条河。我有一封情书（obj）要寄给我的女朋友，但是我没有寄信的能力，我好朋友有（Handle），我有我的好朋友地址（Handle引用），OK，我把我的信放到今天要去河对面的老王（MessageQueue），老王有很多人麻烦他带东西，所以规定要他捎带的东西一定有标识（what），把要带的东西和标识放在一起（Message），老王骑着它的老牛（looper）带给我的朋友，我的朋友帮我寄信（handleMessage），问题得以解决！

当然，上面的比喻并不完美，因为有时候并不是为了求救，而是为了解耦。

好，今天先分析到这里，最后插一句，MessageQueue涉及到很多native方法，现在目前的我还没有能力去分析，但我相信我以后我会慢慢有能力的！下一篇文章，分析Volley。下下个周日会准时写出来的。

最后，上面这些分析是我看牛人的文章后，自己看源码写出来的，当然其中有不足，也有错误，后面随着我发现出来我会更改的。

当然，你也可以指出这些错误或者补充这些不足，我会虚心的接受，改正。如果你有不懂的地方，可以留言，我看到会耐心解答