一切从android的handler说起(四)之postDelay原理

“ 阅读本文大概需要4分钟。”

 

 

和小张聊完了handler底层原理后，我跟小张说：你现在知道Android的UI线程是通过事件来驱动的了吧，有消息来才干活，不然就睡大觉。

小张点了点头，道：通过刚才的了解，我对事件驱动模型的概念理解更为深刻了。

 

我接着说：恩，其实目前大部分的UI编程都是基于事件驱动模型实现的。

 

对刚才的话题做了总结后，我又转换了话题问小张：你平时使用handler发送message都有哪些方法啊？

小张答道：一般用sendMessage(msg)，如果希望延时执行的话，就用postDelay(runnable, delayMillis)。

 

我接着又问：那你有没有想过postDelay是如何实现的？

小张不假思索地回答道：这个应该就是设置一个定时器就可以实现了。

 

我：你了解过这块儿的源码吗？

小张：那倒没有，觉得这块儿没有啥好了解的啊，很符合使用直觉啊。

 

作为一名优秀的面试官，我打算开始把此题变为系统设计题。

 

于是便问道：如果你是这个方法的实现者，你有2个选择：

一种是为此设置一个定时器，等时间到了，然后再发送包装此runnable的message到message queue里去。

 

另一种是把延迟执行的时间设置到message.when属性里，不用等，然后直接交给message queue来处理，你选择哪种实现呢？

 

小张听后，由于以前从未思考过这个看似很不起眼的方法，一时之间难以抉择，于是便索性蒙了一个：我选择第二种实现方式。

 

我紧接着就问道：为什么不选择第一种呢，按理来说，第一种也可以啊？

小张不知哪里来的灵感，说道：如果选择第一种的话，如果发送N个延时消息就要设置N个定时器，对于系统消耗比较大，而第二种不需要，并且还很轻量级。

                                                             

我：嗯，很有道理哈，那你能否结合我们刚刚聊到的消息唤醒机制，按照第二种思路设计一下具体的实现呢？

为了不给小张压力，就说道：不用急，你先慢慢思考就好。

 

过了好一会儿，小张终于开口了：哦，我大概知道了！

 

之前说过android的消息机制是靠enqueueMessage(msg)先使message入链表，然后通过向管道写入"W"来唤醒线程获取此message进行处理的。

 

那么我们可以这样，在把message插进链表时，保证链表中的message按时间排序，头部的时间最小，链表尾的时间最大，当唤醒之后，只拿表头的message，然后比较一下其message.when是否到了该执行的时间，如果还未到，说明整个链表的message都有延迟，于是就继续阻塞，同时设置表头message待执行的定时器，到时候自我唤醒，那么唤醒之后必然可以立即返回此message给looper处理。

 

我听后很高兴，说明小张对于之前的消息机制基本理解了，而且系统设计能力也不错。但是作为一个完整的系统，还没结束，还要考虑到全面的场景。

 

于是鼓励地说道：嗯，非常不错，源码里的确有nativePollOnce(ptr, nextPollTimeoutMillis)这样的阻塞和延时唤醒机制。那如果在延时唤醒的过程中，又来了一个立即执行的message又该如何呢？

 

小张这次稍加思考，便回答道：还是可以按照消息机制原理刚才的设计思路，立即执行的消息同样也会先入链表，然后唤醒线程获取表头message，看是否到了执行时间。由于立即执行的消息其实是一个延时为0的message，在一个延迟的链表中，必然会放入表头，而且是无延迟的，所以会立即取出返回给loop去执行了，loop处理完消息，继续来拿表头的message，如此这样下去...

 

我笑着说道：嗯，没错，你这个设计很接近android的源码实现了。但是这里面你觉得有没有可以优化的点呢？比如是否需要每次enqueueMessage都需要唤醒线程呢？

小张这次陷入了沉思...

 

我便提示道：当整个链表都是延迟执行的message时，如果此时插入的message也是延时执行的，是否一定要唤醒呢？

小张恍然大悟：哦...！如果插入的message并非插入表头，说明拿的下一个message也不是自己，完全可以让线程继续休眠，没有必要唤醒，因为此时的定时器到期唤醒后拿到的正是待返回和执行的表头message。

 

我点了点头表示肯定，说道：是的，源码实现的设计正是如此！来，我们最后总结一下整个消息机制的基本原理：

 

1). 消息是通过enqueueMessage(msg)方法插入消息链表中的，并且按照message.when排序，链表头的延迟时间小，尾部延迟时间最大

 

2). Looper.loop()通过MessageQueue中的next()去取消息

 

3). next()中如果当前链表头部的message是延迟消息，则根据延迟时间进行消息队列会阻塞，不返回给Looper message，并设置定时唤醒，唤醒后，返回message给looper处理

 

4). 如果在looper处于休眠中(要么链表为空，要么整个链表均为延时message)，此时若有新的消息插入到链表头部则直接唤醒线程，looper继续判断步骤3)

 

5). 最终Looper将表头message交给handler中的handleMessage处理，然后继续调用MessageQueue的next()方法，如果刚刚的延迟消息还是时间未到，则计算时间继续阻塞

 

小张啧啧道：没想到一个毫不起眼的postDelay()方法背后蕴含着如此精美的设计，佩服佩服啊。

 

我又说道：虽然弄清楚了，但是总结起来的东西越多说明越没有抓住核心，能否用简短的一句话概括呢？

 

小张仔细想了想说：纵观5条，其实最核心的就是一句话：只有当表头来了新消息，才会唤醒loop来获取，message要么立即执行，要么loop刷新自我唤醒的定时器继续睡眠。

 

我说道：嗯，对的，你抓住了问题的本质和关键，这样以后回想这句话来，就能迅速把握住知识点。

 

---

 

有热爱Android技术的同学，欢迎加 QQ群 726464410，或者扫描QQ群二维码 和 微信公众号二维码。用诙谐的方式学习Android硬核知识点。

                                                                                              欢迎转发，关注公众号 肖晖