Android的消息机制（一）——概述

从Android的开发角度来说，Handler是Android消息机制的上层接口，这使得开发过程中只需要和Handler交互即可。 Handler的使用过程比较简单，通过Handler可以轻松地将一个任务切换到Handler所在的线程中去执行。 同时，纠正一个大家的误解，很多人认为Handler的作用就是更新UI，这的确没错，但是更新UI仅仅是Handler的一个特殊的使用场景。具体为： 有时候需要在子线程中进行一些耗时的I/O操作，可能是读取文件或者是访问网络等。当耗时操作完成以后，需要在UI上做一些改变，由于Android开发规范的限制，我们并不能在子线程中访问UI控件，否则会触发异常，这个时候通过Handler就可以更新UI的操作切换到主线程中执行，因此，我们得出结论：

Handler并不是专门用于更新UI的，它只是经常被开发者用来更新UI。

Android的消息机制，主要是指Handler的运行机制，Handler的运行需要底层的MessageQueue和Looper的支撑 MessageQueue的中文翻译是消息队列，它的内部存储了一组消息，以队列的形式提供插入和删除的工作，虽然叫消息队列，但是它的内部存储结构并不是真正的队列，而是采用单链表的数据结构来存储消息列表。 Looper在这里理解为消息消息循环，由于MessageQueue只是一个消息的存储单元，它能去处理消息，而Looper就填补了这个功能，Looper会以无限循环的形式去查找是否有新消息，如果有的话就处理消息，否则就会一直等待着。Looper中还有一个特殊的概念，那就是ThreadLocal，ThreadLocal并不是线程，它的作用是可以在每个线程中存储数据。ThreadLocal的作用就是在Handler内部获取到当前线程的Looper，ThreadLocal可以在不同的线程中互不干扰存储，并提供数据，通过ThreadLocal就可以轻松地获取每个线程的Looper，其中线程是默认没有Looper的，如果需要使用Handler，就必须为线程创建Looper。 主线程，也就是UI线程，它就是ActivityThread，ActivityThread被创建时就会初始化，Looper这也是在主线程中默认可以使用Handler原因。 Android规定访问UI只能在主线程中进行，如果在子线程中访问UI，那么就会抛出异常，同时，Android又建议不要在主线程中进行耗时操作，否则会导致程序无法响应，即ANR，因此提供Handler，主要原因就是为了解决在子线程中无法访问UI的矛盾。 系统之所以不允许在子线程中访问UI，这是因为Android的UI控件不是先从安全的，如果在多线程中并发访问可能会导致UI控件处于不可预期的状态，最简单且高效的方法就是采用单线程模型来处理UI操作。

Handler的工作原理

Handler创建时会采用当前线程的Looper来构建内部的消息循环系统，当Handler创建完毕之后，这个时候器内部的Looper以及MessageQueue就可以和Handler一起协同工作了，然后通过Handler的post方法将一个Runnable投递到Handler内部的Looper中去处理，也可以通过Handler的send方法发送一个消息，这个消息同样会在Looper中去处理，其实post方法最终也是通过send方法来完成的，接下来看一下send方法的工作过程，当Handler的send方法被调用时，它会调用MessageQueue的enqueueMessage方法将这个消息放入消息队列中，然后Looper发现有Handler所在消息队列来时，就会处理Handler中的消息，最终消息中的Runnnable或者Handler的handlerMessage方法就会被调用。Looper就是运行在创建的线程中，这样一来业务逻辑就会被切换到创建Handler所在的线程中执行了。