Handler机制实现原理（五）总结

时光飞逝，不知不觉写完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的正常工做。