Handler私房菜

中文 Android 人生DFS

字数统计: 4k阅读时长: 15 min

 2023/04/14 

首先，这篇文章会讲什么？

Android中的Handler机制，也被称为消息循环机制。它是干什么的，它由哪些东西组成，它是怎么运作的，以及面试会被怎么问。我尽力保证，通过这篇博客，配合给出的推荐文章，面试时handler相关问题就会是你的加分项。

我试着以最简单的语言去讲述我认为的最重要的东西，但这样难免出现不好理解的情况，这种时候就只能自己去搞明白了。

Let’s go then.

Handler是做什么的？

手机上一切你能看到的东西都是要系统去绘制的，如果多线程下，每个线程都可以绘制ui，会出现多个线程同时绘制同一个ui的不可控情况，这是不可接受的。

那我们为什么不加锁呢？

太慢。UI需要以最快的速度绘制出来。

Handler就是为了解决这个问题，它让UI统一在主线程，有序的一个个绘制。具体来说，子线程通过持有主线程Handler的引用，使用主线程Handler进行UI绘制任务，实现子线程向主线程通信进行UI绘制。

听不懂？没关系，先往下看。

Handler机制成员

在了解Handler的运作原理之前，先来看看是什么在支撑着整套系统。

作为一个共产主义者，我想要提醒您，就像接下来要讲的几个类支撑起了Handler机制一样，不要忘记是劳动人民支撑起了一切，

在这个部分，我会将整套消息循环机制比作一个流水线工厂，帮助尚未入门的我们更好理解各部分的作用。

现在想象一个工厂，有一个或多个窗口，将原材料放在一个盒子里从窗口送进去，这些盒子会被送到同一个传送带上，然后依次被同一个加工机器加工，最后被送回原窗口。

Handler。作为冠名整套机制的类，Handler就像这个工厂的窗口一样，往里面送入原材料，就会被加工好后送出来，再进行一系列的操作。
Message。流水线中的原材料不尽相同，但会被装在统一样式的盒子里。Message就是负责承载这些原材料的盒子。
MessageQueue。一开始说到这些装着原材料的盒子会被送到同一个传送带上，MessageQueue就是这样一个传送带，从它的名字上（消息队列）也能看出，这些Message会被送到这里来一个个被处理。
Looper。最后，传送带上的盒子（Message）会一个个被这台叫Looper的机器取走，加工，最后送回到它们被送进来的窗口。一条消息的循环就此完成。

文字难免抽象，看看图。

cooperationg

既然如此，我们只需要把主线程的窗口广而告之，所有子线程（再想象一下，这个流水线以外有许多工人，他们负责往窗口里送东西）就都可以通过向主线程的窗口里送消息了。也就是说，子线程可以向主线程通信，让主线程按照子线程的想法修改ui了。

Handler运行原理

到了问题大头了，有了Handler机制的概念，那么它到底是怎么运作的呢？

我想把重心放在Handler的原理上，但如果你连见都没见过这套机制在代码上要怎么使用的话，光听原理可能有点空中楼阁。所以我随便搜了一套代码，来展示Handler机制的使用。

（这套代码为了好看，我把它改的不太好运行，所以不要尝试跑它）

public class HandlerAddThreadActivity extends AppCompatActivity {
    private Button mButton;     //一个要改变UI的按钮
    private Handler mHandler; //主线程Handler

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler_add_thread);

        mButton = findViewById(xxxx);

        //实例化主Handler
        mHandler = new Handler(Looper.getMainLooper()) {
            @Override
            public void handleMessage(Message msg) {
                super.handleMessage(msg);
                //根据Message中的内容执行不同逻辑，比如改变mButton的文字
                if(msg.what==1) mButton.setText("文案1");
                else mButton.setText("文案2");
            }
        };

        //开启一个子线程
        CustomChildThread customThread = new CustomChildThread();
        customThread.start();

    //子线程，用于处理耗时工作
    public class CustomChildThread extends Thread {

        @Override
        public void run() {
            //通过让线程睡眠一秒，来模拟一个长耗时的任务
            Thread.sleep(1000);
            //现在长耗时任务完成了，我们想通知主线程要去修改UI了
            //在子线程中创建一个消息对象
            Message childThreadMessage = new Message();
            childThreadMessage.what = 1;
            //将该消息放入主线程的消息队列中
            mHandler.sendMessage(childThreadMessage);
            //最后主线程Handler会处理这个Message，发现Message.what==1，
            //于是把按钮的文字改为"文案1"
        }
    }
}

现在，让我们再来看看谷歌到底是怎么实现这一套充满美感的机制的。（当我们说完postDelayed()方法后，你一定会明白为什么我说它”充满美感”）

Message

这里把Message放到第一个讲，是因为Message当中所有的属性都不依赖于别的类。换句话说，它只负责承载信息，而不实现功能。 不论是Handler，MessageQueue，还是Looper，他们实现的很多功能都要靠Message内部的属性实现。这里列出一些Message的属性，并简单解释一下它们都是做什么的。

如果你在Android Developer的官网上查找Message，会发现官网上Message的属性比起下面列出来的少了一些。事实上，官网只提供了对开发者可见的字段，但既然我们需要理解原理，自然不能止于这些。如果你有足够的好奇心，为什么不试着翻翻源码呢？

// 用户自定义，主要用于辨别Message的类型
public int what;
// 用于自定义存储一些整型数据
public int arg1;
public int arg2;
// 可放入一个可序列化对象
public Object obj;
// Bundle数据
Bundle data;
// 以下对开发者不可见
// Message处理的时间。从系统开机开始算起
public long when;
// 记录这个Message是由哪个Handler发出的
Handler target;
// 当Message被处理后自定义的Runnable行为
Runnable callback;
// 指向MessageQueue中下一个Message
Message next;
......

这部分比较好理解，要注意的都写在上面了。了解Message的内部结构，对于后面部分的理解有很好的帮助，比如其中的when，target，next，都是后面某些问题的答案。

我们在开头提到，Handler机制又称消息循环机制。那么现在消息有了，循环在哪呢？所以官方建议使用Message.obtain()方法去获得一个Message，而不是直接new一个，使用完之后再调用recycle()方法回收Message。上面那段代码对于Message的获取其实是不恰当的。

MessageQueue

接着来看看将消息排成一列的流水线：MessageQueue，看看它有什么行为以及发挥怎样的作用。

MessageQueue的数据结构也不算复杂，甚至我们只需要讲一个属性，和两个方法。

一个属性：Message mMessages;

这个属性指向当前队头的第一个消息。所以，是的，MessageQueue其实并不是一个队列，它只维护第一个Message，后面的靠Message.next属性一个一个往后指。

什么情况，就看一个属性？是的，就看一个。其余属性基本都是负责某些功能的具体实现，主要是IdleHandler，Native阻塞机制，和同步屏障机制。这些在后面都会提及，吧。

两个方法：出队next()和入队enqueueMessage()

1
2
3

Message next() {
    final long ptr = mPtr;
    .....

等等等等，别一言不合就上代码，让我先来试着简述一下。在队列里，next()方法会用一个死循环去调用队头的Message，如果这个Message的when属性，也就是这个Message应该被处理的时间，还没到的话，系统就会设置对应的堵塞时间去堵塞进程，最后进行一系列的处理（主要是和IdleHandler相关的）。

Message next() {
    ...
    // 阻塞时间
    int nextPollTimeoutMillis = 0;
    for (;;) {
        if (nextPollTimeoutMillis != 0) {
            Binder.flushPendingCommands();
        }
        // 阻塞对应时间，（-1代表永久堵塞）
        nativePollOnce(ptr, nextPollTimeoutMillis);
		// 对MessageQueue进行加锁，保证线程安全
        synchronized (this) {
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
            ...
            if (msg != null) {
                if (now < msg.when) {
                    // 下一个消息还没开始，记录需要堵塞的时间
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    // 获得消息且现在要执行，标记MessageQueue为非阻塞
                    //注意！！该mBlocked值为全局变量，在需要堵塞的场景下该值会被设为true（相关代码牵扯到IdleHandler的内容故省略）
                    mBlocked = false;
                    // 链表操作
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    msg.markInUse();
                    return msg;
                }
            } else {
                // 没有消息，进入阻塞状态
                nextPollTimeoutMillis = -1;
            }
           ...
    }
}

有一点长，但其实也好理解。从队列里拿出第一个Message，看现在到不到时间执行，到时间就返回这个Message，不到时间就堵塞等待。

注意到当堵塞时间为-1时，代表着永久堵塞。那么为什么怎么做呢？什么时候唤醒呢？接着看。

说完出队的方法，再来看入队的enqueueMessage()方法。入队方法有两个参数，实际的写法是：enqueueMessage(Message msg, long when)。从参数名上也很容易看出来一个是要入队的消息，一个是Message应该被处理的时间。前文的Handler使用方法demo中，Handler去发送消息的sendMessage()方法，最后实际上调用enqueueMessage()方法去入队消息。

还是先简述一下入队方法的逻辑。根据Message的处理时间，也就是when属性，去从头遍历消息队列，找到这个消息应该插入的位置插进去，确保整个消息队列中的消息是按处理时间排序的。再看线程是否阻塞，阻塞的话就唤醒线程。这就对应了前面说的无限阻塞的场景。

boolean enqueueMessage(Message msg, long when) {
    ...
    // 对MessageQueue进行加锁
    synchronized (this) {
        ...
        // 标记Message正在被执行，将消息需要被执行的时间赋给Message.when（在此之前该属性为空）
        msg.markInUse();
        msg.when = when;
        // 用p记录当前队列头
        Message p = mMessages;
        boolean needWake;
        // 判断是否需要唤醒MessageQueue
        // 如果有新的队头，同时MessageQueue处于阻塞状态则需要唤醒队列
        if (p == null || when == 0 || when < p.when) {
            msg.next = p;
            mMessages = msg;
            //正如前文所说，mBlocked是全局变量，出队方法会改变这个变量的值。true代表正在阻塞，则需要唤醒。
            needWake = mBlocked;
        } else {
            ...
            // 根据when找到插入的位置插入
            Message prev;
            for (;;) {
                prev = p;
                p = p.next;
                if (p == null || when < p.when) {
                    break;
                }
                ...
            }
            msg.next = p; 
            prev.next = msg;
        }
        // 如果需要则唤醒队列
        if (needWake) {
            nativeWake(mPtr);
        }
    }
    return true;
}

其实写到这里，我感觉有点背离初心。将四个组件分开来讲我认为是不好的，这样虽然更有条理也更容易消化，但我更想要做一个Handler机制的串讲。可能这一部分得到后面面试的部分才能实现了，如果各位看官也觉得有点不成体系的话，建议先跳过具体的代码部分，通过我的简述形成一个大致的了解，把细节问题留到最后回头看。

Looper

Looper的部分更好理解，关键方法也不多。正如前文所说，Looper负责不断从MessageQueue中不断取出Message，要注意的是每个线程有独立的Looper，主线程的Looper会自动准备好，而在子线程中要使用自己的Looper的话则需要调用Looper.prepare()方法初始化一个。

Looper.prepare()源码，简单看一下就行。

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

public static void prepare() {
    prepare(true);
}

// 最终调用到了这个方法
private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

顺便看一下Looper的构造方法。这个构造方法会同时new一个MessageQueue，并绑定当前线程。

private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread();
}

就像发动机需要点火来启动一样，一个Looper初始化完成后还需要调用Looper.loop()方法去启动这个Looper。

public static void loop() {
    // 获取当前线程的Looper与MessageQueue
    final Looper me = myLooper();
    final MessageQueue queue = me.mQueue;
    ...
    for (;;) {
        // 用一个死循环去不停获取消息队列中的消息
        Message msg = queue.next(); // 可能造成线程堵塞
        ...
        try {
            // 调用Message对应的Handler（target属性）处理消息
            msg.target.dispatchMessage(msg);
            ...
        }
        ...
    }
}

我把所有其余的代码都删了，只留下核心的方法，是不是难以相信的清爽？原来这么简单，就是在一个死循环里不停的获取Message，再分发到对应的Handler去处理。就是这么简单！

Handler

终~~~~~~~于，来到了最后的大哥，Handler。前文讲的三个组件主要是在后台默默无闻的工作着，与程序员打交道最多的还是Handler。我们用Handler去操作Message，来实现线程之间的跳跃与交流。

注意到创建Handler时必须显示指明对应的Looper，如：

1	Handler handler = new Handler(Looper.myLooper())

对于Handler的操作主要是发送消息和处理消息，我们先从发送消息讲起。

发送消息的部分我不打算放代码上来了，主要是调用链比较长，每个函数内容又不多，建议参考源码。

发送消息最常使用的方法为sendMessage(Message msg)与post(Runnable r)，一个是直接发送消息，一个是讲Runnable包装进Message后发送。实际上这两个函数都是调用sendMessageDelayed(Message msg, long delayMillis)。这个函数从名字上可以看出，是实现延迟发送的功能，希望消息在delayMillis的时间后被处理。而前面两个函数既然没有说希望延迟多久发送，自然将delayMillis设为0就行了。在此之后会调用sendMessageAtTime(Message msg, long uptimeMillis)函数，在此之前的delayMillis会被加上系统的开机时间，从“希望延迟的时间”转变成“会被处理的时间”后发送给MessageQueue，消息队列再调用前文说过的enqueueMessage(Message msg, long when)，消息最后被发送到消息队列里。

最后整理一下调用链：sendMessage(Message msg)/post(Runnable r)->sendMessageDelayed(Message msg, long delayMillis)->sendMessageAtTime(Message msg, long uptimeMillis)->enqueueMessage(Message msg, long when)

处理消息的部分显得不那么重要，主要解决的问题是由哪一层去处理消息队列下发回来的Message。一段源码，一张图可解。

public void dispatchMessage(@NonNull Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

private static void handleCallback(Message message) {
    message.callback.run();
}