欢迎大家来到IT世界,在知识的湖畔探索吧!
“ 阅读本文大概需要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的handler说起(一)之message
一切从android的handler说起(二)之threadLocal
一切从android的handler说起(三)之UI线程不卡顿
每天几分钟，掌握一个硬核面试知识点
欢迎转发，关注公众号 肖晖
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://itzsg.com/18589.html
