Android的消息机制之Handler源码解析

最新推荐文章于 2023-02-13 15:40:22 发布

lishutong1006

最新推荐文章于 2023-02-13 15:40:22 发布

阅读量1.9w

点赞数 2

分类专栏： Android 的消息机制 Handler 源码解析文章标签： android

本文链接：https://blog.csdn.net/lixiong0713/article/details/107781413

版权

Android 的消息机制同时被 2 个专栏收录

1 篇文章 0 订阅

订阅专栏

Handler 源码解析

1 篇文章 0 订阅

订阅专栏

Android 的消息机制

消息机制在开发中我们会经常遇到，Handler的使用过程很简单，通过它可以轻松地将一个任务切换到Handler所在的线程中去执行。很多人认为Handler 的作用是更新UI，这的确没错，但是更新UI仅仅是Handler的一个特殊的使用场景。具体来说是这样的：有时候需要在子线程中进行耗时操作，当耗时操作完成以后可能需要在UI上做一些改变，由于Android开发规范的限制，我们并不能在子线程中访问UI控件，否则就会触发程序异常，这个时候通过Handler就可以将更新UI的操作切换到主线程中执行。因此，本质上来说，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。

本文主要基于Android 8.1.0 系统分析android的消息机制

1. Android 的消息机制概述

Android 的消息机制主要是指 Handler 的运行机制以及 Handler 所附带的 MessageQueue 和 Looper 的工作过程，这三者实际上是一个整体，只不过我们在开发过程中比较多地接触到 Handler 而已。Handler的主要作用是将一个任务切换到某个指定的线程中去执行，那么Android为什么要提供这个功能呢？这是因为Android规定访问UI只能在主线程中进行，如果在子线程中访问UI，那么程序就会抛出异常。ViewRootlmpI对UI操作做了验证，这个验证工作是由ViewRootlmpI的checkThread方法来完成的，代码如下所示：

frameworks/base/core/java/android/view/ViewRootImpl.java

    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的问题。

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

Handler 的使用方法这里就不做介绍了，有兴趣的同学可以通过“Handler消息机制 —— 基本使用及存在的性能问题”这篇文章去学习，这里描述一下 Handler 的工作原理。Handler 创建时会采用当前线程的 Looper 来构建内部的消息循环系统，如果当前线程没有Looper，那么就会报错，错误信息如下所示：

2020-08-04 14:06:42.050 12985-13017/com.lx.test E/AndroidRuntime: FATAL EXCEPTION: pool-1-thread-1
    Process: com.lx.test, PID: 12985
    java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
        at android.os.Handler.<init>(Handler.java:204)
        at android.os.Handler.<init>(Handler.java:118)
        at com.lx.test.MainActivity$1.run(MainActivity.java:31)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
        at java.lang.Thread.run(Thread.java:764)

如何解决上述问题呢？其实很简单，只需要为当前线程创建一个Looper即可。

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

2. Android 的消息机制分析

本节将对 Android 消息机制的实现原理做一个全面的分析，主要包括 Handler，MessageQueue 和 Looper。同时为了更好地理解 Looper 的工作原理，还会介绍 ThreadLocal的工作原理，通过本节的分析可以让读者对 Android 的消息机制有一个深入的理解。

2.1 ThreadLocal 的工作原理

ThreadLocal是线程本地变量的意思，主要用于多线程对同一个变量的读写操作，且相互之间又不会依赖于原始值的改变而影响线程的业务逻辑。主要表现为以下两个方面：

1：每一个线程对ThreadLocal变量都保存着一份副本，任何一个线程的操作只是对这个副本的操作，并不会对原始数据进行修改。

2：由于ThreadLocal变量是线程本地变量，因此其不适用于值的改变需要对多线程必须可见的场景。

下面通过一个例子来理解ThreadLocal的用法，代码如下所示：

public class MainActivity extends AppCompatActivity {
    private static final String TAG = MainActivity.class.getSimpleName();
    // 定义ThreadLocal对象
    private ThreadLocal<String> mNameThreadLocal = new ThreadLocal<>();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        // 主线程
        mNameThreadLocal.set("UI Thread");
        Log.d(TAG,"主线程中的值：" + mNameThreadLocal.get());

        // 线程1
        Executors.newCachedThreadPool().execute(new Runnable() {
            @Override
            public void run() {
                mNameThreadLocal.set("Thread-1");
                Log.d(TAG,"线程1中的值：" + mNameThreadLocal.get());
            }
        });

        // 线程2
        Executors.newCachedThreadPool().execute(new Runnable() {
            @Override
            public void run() {
                mNameThreadLocal.set("Thread-2");
                Log.d(TAG,"线程2中的值：" + mNameThreadLocal.get());
            }
        });
    }
}

在 MainActivity 中我们定义了一个 ThreadLocal 类型的变量 mNameThreadLocal变量，然后分别在主线程、线程1 和线程2 中设置和访问它的值。运行结果如下所示：

2020-08-04 14:39:03.412 13716-13716/com.lx.message.mechanism D/MainActivity: 主线程中的值：UI Thread
2020-08-04 14:39:03.413 13716-13758/com.lx.message.mechanism D/MainActivity: 线程2中的值：Thread-2
2020-08-04 14:39:03.416 13716-13757/com.lx.message.mechanism D/MainActivity: 线程1中的值：Thread-1

从上面日志可以看出，虽然在不同线程中访问的是同一个 ThreadLocal 对象，但是它们通过 ThreadLocal 获取到的值却是不一样的，这就是 ThreadLocal 的奇妙之处。

对 ThreadLocal 的使用方法和工作过程做了介绍后，下面分析 ThreadLocal 的内部实现, ThreadLocal 是一个泛型类，它的定义为 public class ThreadLocal<T>，只要弄清楚 ThreadLocal 的 get 和 set 方法就可以明白它的工作原理。

首先来分析 ThreadLocal 的 set 方法，代码如下所示：