解析Android消息处理机制
——Handler/Thread/Looper & MessageQueue
本文解析Android如何利用Handler/Thread/Looper以及MessageQueue来实现消息机制的内部实现。知道了它的内部实现机理之后，以后再遇到使用它们时候的任何问题就驾轻就熟、迎刃而解了。
Android利用执行在HandlerThread线程中的Looper的相应消息分发/处理，与其他线程中的消息发送结合，实现完整的消息处理机制。本文首先介绍这些消息处理过程中的参与者之间的关系，然后结合WifiService消息处理的实际实例，讲解消息处理的全过程，最后还从线程视图的角度，重新审视一下线程同步模型。
一、HandlerThread/Looper/MessageQueue的前世今生
下图是从Froyo从抽取出的HandlerThread、Looper和MessageQueue的关系图。他们被定义在package android.os。
图一：HandlerThread/Looper/MessageQueue实例关系
HandlerThread是一个Thread，继承自Thread。它保留着对Looper实例的引用，不过这里还看不到HandlerThread、Looper和MessageQueue如何实例化，这要到二、HandlerThread/Looper/MessageQueue实例化之后才能看清如何实现的。
一看便知，Looper的构造函数是私有的，外界无法直接实例化之；要实例化，只有通过Looper::prepare()。这样HandlerThread就与Looper建立了对应关系。对如何建立的是不是已经迫不及待了，那就接着看下一小节。
二、HandlerThread/Looper/MessageQueue实例化
上一节只是看了HandlerThread、Looper和MessageQueue之间的静态视图关系，他们具体如何实例化的，还要看动态的实例初始化过程。
图二：HandlerThread/Looper实例化
- HandlerThread是一个Thread，在它被实例化并执行start()[序列1&2]之后，它的run()方法会在它自己的线程空间执行[序列3]。
- 上节已经提到了Looper的实例化是通过Looper::prepare实现的，图中可以看到Looper::prepare()正是在HandlerThread::run()中被调用而实例化[序列4&5]的。
- 而MessageQueue是在Looper的私有构造函数Looper()中实例化的。
总结一下，HandlerThread是被显式地通过new创建的实例，而与它绑定在一起的Looper是在HandlerThread的执行过程中被实例化的，相应的MessageQueue也是在这个过程中实例化的。
三、Looper::loop分发处理消息
上节重点讲了HandlerThread/Looper的实例化过程，它发生在Thread::run()这也是线程运行的关键，从图二也看到了Looper::loop()这个消息处理的核心正是在这里执行的，下面就看看它到底做了什么。
图三：Looper::loop()处理
图中的所有序列是发生在一个无限循环体while (true) {} 中的。
- mQueue:MessageQueue是Looper保留的一份引用，通过它的next()[序列1]获取MessageQueue中的下一个要处理的消息，这个过程中如果没有相应的消息，执行它的线程会用this.wait()释放它所拥有的MessageQueue的对象锁而等待。
- 一旦有消息到来[序列2]，Looper会用获得的Message的Handler（msg.target）来分发处理消息[序列3&4]。消息处理完之后，还要回收[序列5]。
四、Handler实现具体消息处理
在Looper::loop()消息处理的顺序图里看到了Handler，这个消息分发处理的参与者。下面结合WifiHandler这个具体的Handler看它如何参与到消息的发送、分发和处理的。
4.1 Handler实例化
WifiService中定义了如下的WifiHandler。
图四、消息的发送、分发、处理者Handler
看Handler的构造函数是需要Looper的，从上面的分析知道，Looper是在HandlerThread执行中实例化的，Looper实例如何获得的呢？看图一&图二，知道HandlerThread保留着Looper的应用mLooper，并可通过getLooper()被外面获取。而Handler的mQueue: MessageQueue可以通过mLooper.mQueue获得。
所以，Wifi的HandlerThread，WifiHandler可以这样实例化：
- HandlerThread wifiThread = new HandlerThread("WifiService");
- wifiThread.start();
- mWifiHandler = new WifiHandler(wifiThread.getLooper());
4.2 消息发送
图五、消息发送
通过Message::obtain()可以建立起Message和Target/Handler，what之间的关系，并得到一个Message msg[序列1&2]；然后通过msg.sendToTarget()就可以用Handler来具体发送消息了[序列3&4]；通过一系列的调用，最后会通过MessageQueue::enqueueMessage()把消息放到mMessages上[序列7]，还会通过this.notify()通知正在等待新消息的线程，重新拥有MessageQueue的对象锁，而处理该消息。
图六、MessageQueue与Message的关系
至此，消息的发送，分发，处理基本上介绍完毕。
4.3 消息处理
而要具体处理消息，从图三的序列4就可知道，整个框架的最后消息的处理是通过Handler::handleMessager(msg: Message)来完成。所以如果有自己具体要处理的消息，只要override Handler的handleMessage(msg: Message)方法，并加入自己特定的对消息的处理即可。
要处理消息，就看看Message的属性里都有什么。
图七、Message属性
重点关注public属性what是区分具体什么消息；可以带参数arg1, arg2。
五、重新审视
5.1 应用指南
上面介绍了消息处理的全过程，这些对于只是用来发送和处理消息的应用者来说，可能有些繁杂，这里梳理一下从应用者角度看，怎么使用之。
其实四、Handler实现具体消息处理中的WifiService就是一个典型的应用场景。
实现一个Handler的子类，并Override handleMessage()方法，亦即，实现消息处理函数handleMessage()。然后分别创建HandlerThread和Hanlder继承类的实例。这样就可以如4.2里那样发消息了，而消息处理在handleMessage()中进行。
从应用者角度看，Looper和MessageQueue是消息处理的内部机制，可以不关注它的实现细节（唯一要知道的，Handler实例化的时候，需要通过HandlerThread获得Looper的实例，从而可以传递给Handler）。
5.2 线程角度
下面再从线程的角度看一下，消息处理过程中参与的线程，以及这些线程之间的同步。
显然的，这里有线程HandlerThread的参与，而且Looper::loop()就是执行在HandlerThread的run()方法里，也就是在HandlerThread里执行，这也就是说消息的分发处理和执行是在HandlerThread的线程上下文中。另外，还有至少一个线程存在，也就是创建了HandlerThread的线程B，以及执行消息发送的线程C，B和C有可能是同一线程。
消息的发送是在另外一个线程里，就是因为有了多个线程的存在，才有了线程的同步操作。可再次关注一下图三和图五中实现线程同步的Java原语wait()/notify()。
结束语
写本文的初衷并不是为了写它而写它，是在研究Android中的Wifi实现时，遇到了实现Wifi的各种具体操作都是通过消息来实现的，就想探讨一下ANDROID消息处理机制，这样就边看边用ROSE画了图，等到消息的发送/接收/处理的过程都看完了，再回头看一下整个UML图，这不就整个一完整的消息处理机制嘛！
工作这么多年过来了，回过头来看看，自己积累了什么呢，再看一下5、6年前鄙人的BLOG发现那时还是留下了些东西的，而且写本文时，重温Java的线程同步机制时，看到当时写的东西，发现如果是当时是自己理解的东西，并且用自己擅长的领域表达出来，自己回头再看时，一目了然，几个UML图就能解决问题了。
参考资料
Google Android source Froyo(2.2) git://android.git.kernel.org/platform/manifest.git
田海立 解析JVM线程同步机制 http://blog.csdn.net/thl789/article/details/566494
修正记录
2011/07/18 修改标题、摘要及关键词
消息发送分发处理的主要参与者是Looper, Handler，还有Thread的执行。很多应用场景有他们参与就可完成，HandlerThread倒是WifiService处理时消息处理的一个特例，所以，在这些关键点上去掉HandlerThread。
原文链接：http://blog.csdn.net/thl789/article/details/6601558