临时抱佛脚:IdleHandler 的原理分析和妙用 - 知乎
大致的流程是这样的:
处理完 IdleHandler 后会将 nextPollTimeoutMillis 设置为0,也就是不阻塞消息队列,当然要注意这里执行的代码同样不能太耗时,因为它是同步执行的,如果太耗时肯定会影响后面的 message 执行。
系统中的使用:
handleResumeActivity() 方法中末尾会执行 Looper.myQueue().addIdleHandler(new Idler()),也就是说在 onResume 等方法都执行完,界面已经显示出来了
可以看到在 queueIdle 方法中会进行回收等操作,下面会详细讲解,但这一些都是等 onResume 方法执行完,界面已经显示这些更重要的事情已经处理完了,空闲的时候开始处理这些事情。也就是说系统的设计逻辑是保障最重要的逻辑先执行完,再去处理其他次要的事情。
但是如果 MessageQueue 队列中一直有消息,那么 IdleHandler 就一直没有机会被执行,那么原本该销毁的界面的 onStop,onDestory 就得不到执行吗?不是这样的,在 resumeTopActivityInnerLocked() -> completeResumeLocked() -> scheduleIdleTimeoutLocked() 方法中会发送一个会发送一个延迟消息(10s),如果界面很久没有关闭(如果界面需要关闭),那么 10s 后该消息被触发就会关闭界面,执行 onStop 等方法。