一切从android的handler说起(三)之UI线程为何不卡顿

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

 

 

和小张聊到兴起，我就问了android面试界一个众所周知的问题。

 

我：之前说到每个线程的looper都在不断的从message queue里取message来处理，那android系统是如何做到“不断”二字的？

 

小张快速回到答：这个我看过一些技术文章里剖析过源码，我记得是Looper是在loop()方法里通过for(;;)死循环里的Message msg = queue.next()这句话来不断获取message queue里的下一条message。

 

我继续问道：没错，看来你的确接触过这块儿的源码，而且记忆力还挺不错啊。

 

紧接着我又问道：我们都知道在UI线程里，系统预先为我们创建了一个looper，那么UI线程里的looper这个死循环岂不是占用了所有CPU资源，一打开app岂不是卡出翔？但是我们平时用app很流畅啊，这是怎么回事啊？

 

听到这个问题，看小张脸色犯难，感觉当时小张的心情是这样的：

                                

小张：哦，是这样的 ...

怕什么来什么，躲是躲不过去了，只好硬着头皮扛下去。

 

小张沉思片刻，说道：我记得这个循环比较特殊，并不是普通的死循环，queue.next()是一个可能阻塞线程的操作，也就是说可能会交出CPU执行时间片，而不至于导致卡顿或者ANR发生。

 

我听后，感觉有得聊，于是打算趁机打算再深入一步。

 

继续问道：queue.next()看起来像是去queue里获取下一条可以处理的message，你能否对这块儿的逻辑说得详细一些呢？

 

小张：嗯，可以。如果message queue检查到单链表里没有任何message存在，就会使得线程阻塞在此处，因为没有任何message可以返回使得loop()方法继续下面的处理逻辑，因此也没有可执行的代码片段，对于CPU来讲此线程将会进入休眠，就会把时间片分配给其他线程。

 

如果message queue检查到单链表队首有message可以立即返回[注1]，交给loop()执行接下来处理此message 的逻辑，处理完逻辑后。for(;;)又会紧接着循环到开头的queue.next()问其要下一条message，如此周而复始...

 

                                                               

听完小张的回答，我是比较满意的，毕竟到目前为止，我面的候选人里能回答到这一步的都比较少，心里对小张的印象分提高了不少。

 

为了考察小张对这个问题的理解到底有多深，我决定打破砂锅问到底。

 

我：嗯，很好很好。你的理解基本上是正确的，但这里面有个问题不知道你考虑过没有，就是当message queue在检查到没有message时进入了休眠。

 

那如果此时，用户此时来一个按钮点击事件，点击事件包装成的message被handler扔进来时，message queue又如何知道，从而立即做出反应？

 

毕竟UI线程是不能错失任何一个message的，否则对用户来说就是点击没有反应，对吧？

 

估计小张听完感觉内心快崩溃了...

                                            

小张：这个我只记得queue.next()的源码里有个nativePollOnce()进入了JNI C代码里，有立即执行的message就会立即返回，没有的话nativePollOnce()无法返回，线程就会进入休眠。如果此时有message来时，这里面的逻辑就会唤醒线程，重新进行获取message的逻辑...

 

我看小张的回答稍显模糊，估计是到了他理解的极限了，但毕竟离真相只差最后一步了，我怀着试一试的态度，打算做最后的试探。

 

于是问道：嗯嗯，能够理解到这个程度相当不错了。那能够最后说一下你刚才提到的”唤醒“这块具体是怎么实现的吗？

 

小张故作思考了一下道：这块儿...不是很了解...

 

                                                      

 

我试图引导道：看nativePollOnce()这个函数的名字，有没有感觉很像Linux的什么机制？

 

小张经过提示，貌似想起了什么，小声问道：你说的是Linux的epoll吗？

 

到了这一步，我直接摊牌：是的，正是大名鼎鼎的epoll，epoll机制提供了Linux平台上最高效的I/O复用机制，它能够在一个地方等待多个文件句柄的I/O事件。

 

简而言之，就是android使用pipe管道创建两个fd文件描述符，nativePollOnce方法中正是承载着这个管道的读操作，根据fd知道是管道读端有可读事件。

 

当有message来临时，比如触摸事件，即会调用message.enqueueMessage()，添加完message后，调用了native层的nativeWake方法，就会向管道写端写一个“W”字符[注2]，这样就能触发管道读端从epoll_wait函数返回，从而达到唤醒线程的目的，从nativePollOnce()处继续执行下去。

 

看小张似懂非懂的的表情，我知道这个可能一时半会儿解释不清楚了。

 

就微笑着说道：没事儿，你回答得已经挺好的了，关于pipe/epoll这块儿的知识点，你可以后面回去查资料了解一下。

 

小张点了点头，道：嗯，的确是，对于操作系统的底层知识，的确是我的薄弱点，我一定会加强。

 

[注1]：这里并非有message即返回，因为此message有可能是由postDelay发送的延时处理消息，不可立即执行，需要等到时间到时才执行。关于此种情况，请见下一篇。

[注2]：关于这里是如何触发的，请等后面的文章。

 

---

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

                                                   

                                                                                                                       欢迎转发，关注公众号