分析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方法。绕了一圈，终于给绕回来了。

那么，当MessageQueue中没有数据时，会发生什么事情呢？
我们继续看到MessageQueue.next()方法。

Message next() {

        int pendingIdleHandlerCount = -1; // -1 only during first iteration
        int nextPollTimeoutMillis = 0;
        for (;;) {
            if (nextPollTimeoutMillis != 0) {
                Binder.flushPendingCommands();
            }

            nativePollOnce(ptr, nextPollTimeoutMillis);

            synchronized (this) {
                if (msg != null) {
                    if (now < msg.when) {
                        // Next message is not ready.  Set a timeout to wake up when it is ready.
                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                    } else {
                        // Got a message.
                        mBlocked = false;
                        if (prevMsg != null) {
                            prevMsg.next = msg.next;
                        } else {
                            mMessages = msg.next;
                        }
                        msg.next = null;
                        if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                        msg.markInUse();
                        return msg;
                    }
                } else {
                    // No more messages.
                    nextPollTimeoutMillis = -1;
                }

                // If first time idle, then get the number of idlers to run.
                // Idle handles only run if the queue is empty or if the first message
                // in the queue (possibly a barrier) is due to be handled in the future.
                if (pendingIdleHandlerCount < 0
                        && (mMessages == null || now < mMessages.when)) {
                    pendingIdleHandlerCount = mIdleHandlers.size();
                }
                if (pendingIdleHandlerCount <= 0) {
                    // No idle handlers to run.  Loop and wait some more.
                    mBlocked = true;
                    continue;
                }

                if (mPendingIdleHandlers == null) {
                    mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
                }
                mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
            }
            // Reset the idle handler count to 0 so we do not run them again.
            pendingIdleHandlerCount = 0;

            // While calling an idle handler, a new message could have been delivered
            // so go back and look again for a pending message without waiting.
            nextPollTimeoutMillis = 0;
        }
    }

上面代码进行了阉割。我们重点看 nativePollOnce(ptr,nextPollTimeoutMillis);
这个方法的意思是阻塞当前线程nextPollTimeoutMillis毫秒。而nextPollTimeoutMillis是当消息队列里没有消息或者消息还不需要执行时（延迟消息），会不为0。当nextPollTimeoutMillis不为0时，当前线程阻塞。
那么，当前线程在什么时候被唤醒呢？

按照正常思维，是在往队列加数据的时候。我们看一下MessageQueue。enqueueMessage方法。

boolean enqueueMessage(Message msg, long when) {
        省略.....
     if (needWake) {
         nativeWake(mPtr);
     }
     return true;
}

可以很清楚的看到，调用了nativeWake(mPtr)方法。
所以Handle机制的阻塞唤醒机制，就是这样发生的。

我这么分析，是因为我们没有办法一开始就捉住源头。一开始呈现在我们眼前的只有冰山的一角，就只有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。下下个周日会准时写出来的。

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

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

-------------------- 2019年-08月-20日 ------------------------
在Handle 机制中 MessageQueue 中有一个next方法，这个方法中，有一个变量叫做mBlocked，标识着是否要阻塞当前的next方法。
next方法是一个无限for旋转，当mBlocked 为 true 时，会一直continue。

-------------------- 2020年-10月09日 ---------------------------
Handle如何处理在添加队列时的多线程的问题？
采用 synchronized(this)，this是当前队列的引用。