10分钟掌握Android消息机制(一)机制分析

本文为个人学习笔记分享，没有任何商业化行为，对其他文章的引用都会标记。如有侵权行为，请及时提醒更正！如需转载请表明出处
本文主要来源是 任玉刚大神的《Android开发艺术探索》

提到消息机制大家应该都不陌生，从开发的角度来说，Handler是Android消息机制的上层接口，这使得再开发过程中只需要我们和Handler打交道就可以了。Handler的使用过程很简单，通过它可以轻松的将一个任务切换到handler所在的线程中去执行。很多人认为Handler的作用就是更新UI，这的确没错，但是更新UI仅仅是Handler的一个特殊的使用场景。具体来说是这样的：有时候需要在子线程中进行耗时的操作，可能是读取文件或者访问网络等，当耗时操作完成以后可能需要在UI上做一些改变，由于Android开发规范的限制，一般情况我们并不能在子线程中访问UI控件，否则就会触发程序异常，这个时候通过Handler就可以将更新UI的操作切换到主线程中执行。因此，本质上来说，Handler并不是专门用于更新UI的，他只说常被开发者用来更新UI。

---

Android 的消息机制主要是指Handler的运行机制，Handler的运行需要底层的Looper和MessageQueue的支持。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开发规范的限制，一般情况我们并不能在子线程中访问UI控件，否则就会触发程序异常，可以通过Handler就可以将更新UI的操作切换到主线程中执行
• Android 的消息机制主要是指Handler的运行机制，Handler的运行需要底层的Looper和MessageQueue的支持。
• MessageQueue 消息队列，顾名思义它的内部存储一组消息，以队列的形式对外提供插入和删除的工作。采用单链表的数据结构存储消息列表。
• Looper 消息循环，Looper会以无线循环的形式去查找是否有新消息，如果有的话就处理，否则就一直等待着。
• ThreadLocal，ThreadLocal并不是线程，它的作用就是在每个线程中存储数据。
• 我们经常提到的主线程，也叫UI线程，它就是ActivityThread，ActivityThread被创建时就会初始化Looper，这也是在主线程中默认可以使用Handler的原因。

拓展

Android是如何验证线程访问UI的问题呢？
Android规定访问UI只能在主线程进行，如果子线程访问UI，那么程序就会抛出异常。ViewRootImpl对UI操作做了验证，这个验证工作是由ViewRootImpl的checkThread方法来完成的，如下所示。

  void checkThread(){
    if(mThread !=Thread.currentThread()){
            throw new CalledFromWrongThreadException("Only the original thread
                     that created a view hierarchy can touch its views.");
    }
  }

针对checkThread方法中抛出的异常信息，相信读者在开发中都曾遇到过。由于这一点的限制，导致必须在主线程中访问UI，但是Android有建议不要在主线程进行耗时操作，否则会导致程序无法响应即ANR。考虑一种情况，假如我们需要从服务端拉取一些信息将其展示在UI上，这时候必须在子线程中进行拉取工作，拉取完毕后又不能在子线程中直接访问UI，如果没有Handler，那么我们的确没有办法将访问UI的工作切换到主线程中去执行。因此，系统之所以提供Handler，主要原因就是为了解决在子线程中无法访问UI的矛盾。

Android系统为什么不允许在子线程中访问UI?
Android 的UI控件不是线程安全的，如果在多线程并发访问可能会导致UI控件处于不可预期的状态，那么为什么系统不对UI控件的访问加上锁机制呢？缺点有两个：首先加上锁机制会让UI访问的逻辑变得复杂；其次锁机制会降低UI的访问效率，因为锁机制会阻塞某些线程的执行。鉴于这两点，最简单且高效的方法就是采用单线程模型来处理UI操作，对于开发者来说也不是很麻烦，只是需要通过Handler切换一下UI访问的执行线程即可。