详细分析android的MessageQueue.IdleHandler
我们知道android是基于looper消息循环的系统，我们通过handler向looper包含的messagequeue投递message, 不过我们常见的用法是这样吧？
一般我们比较少接触messagequeue, 其实它内部的idlehandler接口有很多有趣的用法，首先看看它的定义：
简而言之，就是在looper里面的message暂时处理完了，这个时候会回调这个接口，返回false，那么就会移除它，返回true就会在下次message处理完了的时候继续回调，让我们看看它有哪些有趣的用法吧~~
一、提供一个android没有的声明周期回调时机
如果有这种需求，想要在某个activity绘制完成去做一些事情，那这个时机是什么时候呢？有同学可能觉得onresume()是一个合适的机会，不是可是这个onresume() 真的是各种绘制都已经完成才回调的吗？no, too naive ~~
你看谷老师说了，onstart是用户可见，onresume是用户可交互，谷老师可没说onresume是绘制完成吧~那么android那些耗时的measure, layout, draw是在什么时候执行的呢？它们跟onresume()又有何关系呢？让我们先来看看源码吧~
1. activitythread.java
我们知道app的进程其实是activitythread, 那么activity的生命周期自然是它来执行了，
performresumeactivity就是回调onresume了， 我们继续看wm.addview方法， 这个viewmanager是一个接口，其实现者是windowmanagerimpl
2.windowmanagerimpl.java
这个mglobal是windowmanagerglobal对象，我们继续
3.windowmanagerglobal.java
这里我们new 出了viewrootimpl对象， 我们知道这个对象就是android view的根对象了，负责view绘制的measure, layout, draw的巨长的方法 performtraversals就是这个类的，我们继续看setview方法
4.viewrootimpl.java
这个函数调用了关键方法requestlayout(), 我们继续跟踪，顺便说下，后面一连串的badtokenexception就是我们常常遇到的dialog相关抛出的，也有些特殊场景也会出这个异常，可以到这里查看线索。
调用了scheduletraversals， 从名字就能看出来了吧：
它往choreographer里面post了一个runnable， 这个choreographer是android负责帧率刷新相关的东西，我们暂时可以不关注它，可以理解为往主线程post一个消息是一样的，顺便说下这个choreographer可以做帧率检测相关的东西，，可以用于卡顿检测什么的···
我们看这个runnable果然是去执行了那个巨长无比的函数performtraversals函数, 现在我们可以总结下流程了：
结论：所以如果我们想在界面绘制出来后做点什么，那么在onresume里面显然是不合适的，它先于measure等流程了， 有人可能会说在onresume里面post一个runnable可以吗？还是不行，因为那样就会变成这个样子
所以你的行为一样会在绘制之前执行，这个时候我们的主角idlehandler就发挥作用了，我们前面说了，它是在looper里面message暂时执行完毕了就会回调，顾名思义嘛，idle就是队列为空的意思，那么我们的onresume和measure, layout, draw都是一个个message的话，这个idlehandler就提供了一个它们都执行完毕的回调了，大概就是这样
说了这么多，那么现在获取到这个时机有什么用呢？ look！！
这个是我们地图的公交详情页面， 进入之后产品要求左边的页卡需要展示，可以看到左边的页卡是一个非常复杂的布局，那么进入之后的效果可以明显看到头部的展示信息是先显示空白再100毫秒左右之后才展示出来的，原因就是这个页卡的内容比较复杂，用数据向它填充的时候花了较长时间，代码如下：
可以看到这个detailview就是这个侧滑的页卡了，填充里面的数据花了90ms，如果这个时间是用在了界面view绘制之前的话，就会出现以上的效果了，view先是白的，再出现，这样就体验不好了，如果我们把它放到idlehandler里面呢？代码如下：
效果是这样的：
看出不同了吗？顶部的页卡先展示出来了，这样体验是不是会更好一些呢。虽然只有短短90ms，不过我们做app也应该关注这种细节优化的，是吧~ 这个做法也提供了一种思路，android本身提供的activity框架和fragment框架并没有提供绘制完成的回调，如果我们自己实现一个框架，就可以使用这个idlehandler来实现一个onrenderfinished这种回调了。
二、可以结合handlerthread, 用于单线程消息通知器
我们先思考一个问题，如果有一个model数据管理模块，怎么设计？比如地图的收藏模块的model部分。就是下面这个图的小星星：
它原来的model设计大概是这个样子的：
由于这个model是单例的，而且是多线程可以访问的，所以它的增删改查都加上了锁，而且由于外部访问需要遍历有哪些收藏点，所以外部遍历列表也需要加锁，大概是这样的：
因为是多线程可访问的，如果遍历不加锁的话，其他线程删除了一个收藏，就会crash的，原来的这样设计有几个不好的地方：
1. 外部使用者需要关系锁的使用，增加了负担，不用还不安全
2. 如果在主线程加锁的话，可能另一个线程执行操作会阻塞主线程造成anr
总之，多线程代码就是容易出错，而且真的出错的时候查起来太费劲了，目前收藏夹模块就有n多bug，所以我想用单线程来解决这个问题，由于model层的访问需要数据库和网络等，所以需要异步线程，那么单线程队列+异步线程，首先想到的就是handlerthread, 大概架构如下：
现在，我们把原来多线程的逻辑改到了单线程里面，各种收藏的model共用一个handlerthread，这样我们增删改查都不用加锁了，出错几率大大减小，而且这种model的设计有点类似插件的意思，可以很方便的增加其他收藏。
ok， 那么跟我们的主题idlehandler有什么关系呢？思考这样一个问题，地图上的小星星需要实时更新，也就是model的任何变化都需要显示到地图上，那么收藏的小星星就应该作为model的观察者，以前的做法是向收藏model注册监听，在每一个增删改查操作后都对观察者回调，大概是这样：
这样有一个小小的问题，就是如果有一个操作生成10个快速连续的增删改查操作，那么我们的ui就会收到10次回调，而这种场景下我们其实只需要最后一次回调就够了，中间操作其实不用刷新ui的。
那么现在改成单线程模型，我们又该如何处理这个问题呢？当然我们也能在每个post到异步线程的runnable里面去回调观察者，但这样未免不够优雅，所以这个时候idlehandler不就又可以发挥作用了吗？它是在消息暂时处理完的时候回调的呀，不是很符合我们的时机么，对吧？
就是这个样子了，这里为什么不用第一个场景下的looper.myqueue().addidlehandler()呢？注意这个地方looper.myqueue()如果在主线程调用就会使用主线程looper了，所以我选择反射这个handlerthread的looper来设置它，这个idlehandler我们返回了true, 表示我们要长期监听消息队列，因为返回false，下次就没有回调了哦。
好了，结论是这个地方idlehandler用作了一个消息的触发器，是不是挺有意思的呢？
三、 结语
如果你没有用过它，从今天开始试试吧，这篇文章只是我个人的一点小思路，说不定这个idlehandler有很多其他的用法呢~~
腾讯wetest提供上千台真实手机，随时随地进行测试，保障应用/手游品质。节省百万硬件费用，加速敏捷研发流程。
同时腾讯wetest兼容性测试团队积累了10年的手游测试经验，旨在通过制定针对性的测试方案，精准选取目标机型，执行专业、完整的测试用例，来提前发现游戏版本的兼容性问题，针对性地做出修正和优化，来保障手游产品的质量。目前该团队已经支持所有腾讯在研和运营的手游项目。