时光飞逝，不知不觉写完Handler系列文章已经用时一个月了。作为我开始分析Android Framework源码的敲门砖还是遇到了很多挫折，尤其是分析MessageQueue源码时那种百思不得其解的疑惑困扰着我很长时间。不过当我想通了这其中的原理后那种酣畅淋漓的感觉也让我很有成就感。
Message缓存池
Android 的工程师们充分利用了Java的高级语言特性，即类中持有着一个类自身的属性作为经典数据结构中的链表next指针，以静态属性属于类本身的特性实现了链表的表头。这种模式给我了很大的启发，让我这种渣渣每逢想起都会惊讶“还有这种操作？”。
为什么要有缓存池
了解完Handler整体机制后我猜测，Message功能十分单一且状态很少，它只是一个具体发送消息的载体，但是使用数量十分庞大，回收用过的Message不仅可以有效的减少重复消耗系统资源且回收它的成本很低，所以何乐而不为呢？
谁负责回收Message
我们使用Message时候知道调用Message.obtain();方法可以从缓存池中取出一个Message，有存才能有取，我们什么时候回收它呢？从源码中发现，Looper在分发Message给宿主Handler之后，确定了Message已经完成了它的使命直接就会将它回收。所以我们完全不用担心这个，我们发送的每个消息最后都会被回收。
真正的阻塞发生在MessageQueue
MessageQueue维持的消息队列也是靠跟Message缓存池同样的原理生成的，每次消息出队时如果没有合适的待取出消息就会阻塞线程等待有合适的消息。
非常奇怪的是，MessageQueue线程的方式不是传统使用java实现的，而是通过JNI调用native层的C++代码实现的，C++代码中也实现了一套Looper+MessageQueue+Handler，阻塞线程的方式是调用Linux的监听文件描述符ePoll实现的。
我的猜测是因为Java代码需要经过JVM的帮助才能跟系统接触，这一过程会消耗性能，而C++代码则直接可以绕过这一个环节。所以，使用C++代码实现线程阻塞可能是性能上的需求。
为什么推荐使用Handler实现线程间通信
在没有真正了解Handler的时候以为Google的工程师们在Handler上使用了什么了不起的技术呢，所以才推荐开发者们使用Handler来实现线程间通信。
其实呢？Android是事件型驱动的系统，刚创建一个应用程序的主线程里就会被创建一个Looper来不断接受各种事件，所以说如果我们打开一个程序什么都不操作，这个程序就有可能是阻塞状态的，因为他没有任何事件需要去处理。反之，我们在自己的UI线程里执行一项耗时操作，主线程Looper一直在处理这个任务而无法分身处理其它的事件这时候就有可能ANR了。
所以，不是Handler的技术多牛逼，是主线程用了Handler来通信，你是用别的方法通信有可能会影响主线程Looper的正常工作。
