临时抱佛脚：IdleHandler 的原理分析和妙用 - 知乎
大致的流程是这样的：
- 如果本次循环拿到的 Message 为空，或者这个 Message 是一个延时的消息而且还没到指定的触发时间，那么，就认定当前的队列为空闲状态。
- 接着就会遍历 mPendingIdleHandlers 数组(这个数组里面的元素每次都会到 mIdleHandlers 中去拿)来调用每一个IdleHandler 实例的 queueIdle 方法。
- 如果这个方法返回false的话，那么这个实例就会从 mIdleHandlers 中移除，也就是当下次队列空闲的时候，不会继续回调它的 queueIdle 方法了。
处理完 IdleHandler 后会将 nextPollTimeoutMillis 设置为0，也就是不阻塞消息队列，当然要注意这里执行的代码同样不能太耗时，因为它是同步执行的，如果太耗时肯定会影响后面的 message 执行。
系统中的使用：
handleResumeActivity() 方法中末尾会执行 Looper.myQueue().addIdleHandler(new Idler())，也就是说在 onResume 等方法都执行完，界面已经显示出来了
可以看到在 queueIdle 方法中会进行回收等操作，下面会详细讲解，但这一些都是等 onResume 方法执行完，界面已经显示这些更重要的事情已经处理完了，空闲的时候开始处理这些事情。也就是说系统的设计逻辑是保障最重要的逻辑先执行完，再去处理其他次要的事情。
但是如果 MessageQueue 队列中一直有消息，那么 IdleHandler 就一直没有机会被执行，那么原本该销毁的界面的 onStop，onDestory 就得不到执行吗？不是这样的，在 resumeTopActivityInnerLocked() -> completeResumeLocked() -> scheduleIdleTimeoutLocked() 方法中会发送一个会发送一个延迟消息（10s），如果界面很久没有关闭(如果界面需要关闭)，那么 10s 后该消息被触发就会关闭界面，执行 onStop 等方法。
常见使用方式
- 在应用启动时我们可能希望把一些优先级没那么高的操作延迟一点处理，一般会使用 Handler.postDelayed(Runnable r, long delayMillis)来实现，但是又不知道该延迟多少时间比较合适，因为手机性能不同，有的性能较差可能需要延迟较多，有的性能较好可以允许较少的延迟时间。所以在做项目性能优化的时候可以使用 IdleHandler，它在主线程空闲时执行任务，而不影响其他任务的执行。
- 想要在一个 View 绘制完成之后添加其他依赖于这个 View 的 View，当然这个用View.post()也能实现，区别就是前者会在消息队列空闲时执行
- 发送一个返回 true 的 IdleHandler，在里面让某个 View 不停闪烁，这样当用户发呆时就可以诱导用户点击这个View，这也是种很酷的操作
“终于懂了”系列，Android启动优化~
)
)
