从开发的角度来说，Handler是Android 消息机制的上层接口，这使得在开发过程中只需要和Handler交互即可。Handler的使用过程很简单，通过它可以轻松的将一个任务切换到Handler所在的线程中去执行，本质上来说，Handler 并不是专门用于更新UI的，它只是常被开发者用来更新UI。
Android 的消息机制主要是指Handler的运行机制，Handler的运行需要底层MessageQueue和Looper的支撑，MessageQueue的中文翻译是消息队列，它的内部存储了一组消息，以队列的形式对外提供插入和删除的工作，虽然叫消息队列，但是它的内部存储结构并不是真正的队列，而是采用单链表的数据结构来存储消息列表。Looper翻译为循环，在这里可以理解为消息循环，由于MessageQueue只是一个消息的存储单元，它不能去处理消息，而Looper就填补了这个功能，Looper会以无限循环的形式去查找是否有新消息，如果有就处理消息，否则就一直等待着，Looper中还有一个特殊的概念就是ThreadLocal，ThreadLocal并不是线程，它的作业是可以在每个线程中存储数据，Handler创建的时候会采用当前线程的Looper来构造消息循环系统，那么Handler内部如何获取到当前线程的Looper呢，这就要使用ThreadLocal了，ThreadLocal可以在不同的线程中互不干扰的存储并提供数据，通过ThreadLocal可以轻松获取每个线程的Looper，需要注意的是，线程是默认没有Looper的，如果需要使用Handler就必须为线程创建Looper。我们常提到的主线程也叫UI线程，它就是ActivityThread ，ActivityThread被创建时就会初始化Looper，这也是在主线程中默认可以使用Handler的原因。
Android的消息机制概述
Android 的消息机制主要是指Handler的运行机制以及Handler 所附带的MessageQueue和Looper的工作机制，这三者实际上是一个整体，只不过我们在开发过程中比较多的接触到Handler。Handler 的主要功能是将一个任务切换到某个指定的线程中执行。那么Android为什么要提供这个功能呢，这是因为Android 规定访问UI只能在主线程中进行，如果在子线程中访问UI，那么程序就会抛出异常，ViewRootImpl对UI操作做了验证，这个验证工作是由ViewRootImpl的checkThread方法来完成的
针对checkThread方法中抛出的异常信息，很多人就遇到过，由于这一点的限制，导致必须在主线程中访问UI，但是Android又建议不要在主线程中进程耗时操作，否则会导致程序无法响应即ANR，系统之所以提供Handler，主要原因就是为了解决在子线程中无法访问UI的矛盾。
系统为什么不允许在子线程中访问UI呢，这是因为Android的UI控件不是线程安全的，如果在多线程中并发访问可能会导致UI控件处于不可预期的状态，那么为什么系统不对UI控件的访问加上锁机制呢？缺点：首先加上锁机制会让访问的逻辑变得很复杂，其次锁机制会降低UI的访问效率，因为锁机制会阻塞某些线程的执行，鉴于这些，最简单且高效的方法就是采用单线程模式来处理UI操作
Handler创建时会采用当前线程的Looper来构建内部的消息循环系统，如果当前线程没有Looper，那么就会报错
如何解决这个问题呢，只需要为当前线程创建Looper即可，或者在一个有Looper的线程中创建Handler即可。
Handler创建完毕后，这个时候其内部的Looper以及MessageQueue就可以和Handler一起协同工作了，然后通过Handler的post方法将一个Runnable投递到Handler内部的Looper中去处理，也可以通过Handler的send方法发送一个消息，这个消息同样会在Looper中去处理，其实post方法最终也是通过send方法来完成的，当Handler的send方法被调用时，它会调用MessageQueue的enqueueMessage方法将这个消息放入消息队列中，然后Looper发现有新消息到来时，就会处理这个消息，最终消息中的Runnable或者Handler的handMessage方法就会被调用，注意Looper是运行在创建Handler所在的线程中的，这样一来Handler中的业务逻辑就被切换到创建Handler 所在的线程中去执行了。
Android的消息机制分析
ThreadLocal的工作原理
ThreadLocal是一个线程内部的数据存储类，通过它可以在指定的线程中存储数据，数据存储以后，只有在指定线程中可以获取到存储的数据，对于其他线程来说则无法获取到数据，在日常开发组用到ThreadLocal的地方较少，但在某些特殊的场景下，通过ThreadLocal可以轻松的实现一些看起来很复杂的功能，这一点在Android 的源码中也有所体现，比如Looper，ActivityThread以及AMS中都用到了ThreadLocal，具体到ThreadLocal的使用场景，当某些数据是以线程为作用域并且不同线程具有不同的数据副本的时候，就可以考虑采用ThreadLocal，比如对于Handler来说，它需要获取当前线程的Looper，很显然Looper的作用域就是线程并且不同线程具有不同的Looper，这个时候通过ThreadLocal就可以轻松实现Looper在线程中的存取，如果不采用ThreadLocal，那么系统就必须提供一个全局的哈希表供Handler查找指定线程的Looper，这样一来就必须提高一个类似于LooperManager的类了。
ThreadLocal另一个使用场景是复杂逻辑下的对象传递，比如监听器的传递，有些时候一个线程中的任务过于复杂，这可能表现为函数调用粘比较深以及代码入口的多样性，在这种情况下，我们又需要监听器能够贯穿整个线程得执行过程，这个时候可以怎么做呢，其实这时就可以采用ThreadLocal，采用ThreadLocal可以让监听器作为线程内得全局对象而存在，在线程内部只要通过get方法就可以获取到监听器，如果不采用ThreadLocal，那么我们能想到得是如下两种方法：第一种方法是将监听器通过参数得形式在函数调用栈中进行传递，第二张方法是将监听器作为静态变量供线程访问。上述两种方法都是有局限性的，第一种方法的问题是当函数调用栈很深的时候，通过函数参数来传递监听器对象这几乎是不可能的，第二张方法是可以接受的，但是这种状态是不具有可扩充性的
实例：
分别在主线程，子线程1 和子线程2 设置和访问它的值
日志如下：
虽然在不同线程中访问的是同一个ThreadLocal对象，但是它们通过ThreadLocal获取到的值却是不一样的。是因为不同线程访问同一个ThreadLocal的get方法，ThreadLocal内部会从各自的线程中取出一个数组，然后再从数组中根据当前ThreadLocal的索引娶查找出对应的value值，不同线程中的数组是不同的
ThreadLocal内部实现：
ThreadLocal是一个泛型类，它的定义为public class ThreadLocal<T> 只要弄清楚ThreadLocal的get和set方法就可以明白它的工作原理：
首先会通过values方法来获取当前线程中的ThreadLocal数据，在Thread类的内部有一个成员专门用于存储线程的Th'readLocal的数据：ThreadLocal.values localValues,因此获取当前线程的ThreadLocal数据就很简单，如果LocalValue的值为null，那么就需要对其进行初始化，初始化后再将ThreadLocal的值进行存储，在localValues内部有一个数组：private Object[]table,ThreadLocal的值就存在这个table数组中