关于空闲任务IdleHandler的那些事
??Android的消息机制Handler已经是老生常谈了,包括Android Framework层的应用启动过程都涉及消息机制,肥柴在“一切从Android的Handler讲起”专栏中已经讲了很多。
??对于Android中的消息处理机制来说,MessageQueue和Looper、Message是非常重要的对象,而IdleHandler是MessageQueue的静态内部接口。那什么是IdleHandler呢?
一、IdleHandler
??IdleHandler是一种在只有当消息队列没有消息或者是队列中的消息还没到执行时间时,才会执行的任务,其存放在MessageQueue的mIdleHandlers队列中。
public static interface IdleHandler {
boolean queueIdle();
}
public void addIdleHandler(@NonNull IdleHandler handler) {
if (handler == null) {
throw new NullPointerException("Can't add a null IdleHandler");
}
synchronized (this) {
mIdleHandlers.add(handler);
}
}
??使用方式是实现IdleHandler接口,在queueIdle实现MessageQueue空闲时需要处理的逻辑,并通过addIdleHandler()方法添加到mIdleHandlers队列中。
MessageQueue.IdleHandler idleHandler = new MessageQueue.IdleHandler() {
@Override
public boolean queueIdle() {
return false;
}
};
Looper.getMainLooper().getQueue().addIdleHandler(idleHandler);
二、IdleHandler实现基本原理
??知道了IdleHandler的定义和使用,那么Handler消息机制是如何实现MessageQueue空闲的时候调用IdleHandler进行任务处理的呢?这就需要我们从MessageQueue的next方法入手了,至于Looper消息的获取可以见肥柴之前的:一切从Android的Handler讲起(四):Looper消息获取一文。
@UnsupportedAppUsage
Message next() {
int pendingIdleHandlerCount = -1;
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
nextPollTimeoutMillis = -1;
}
if (mQuitting) {
dispose();
return null;
}
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null;
boolean keep = false;
try {
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
pendingIdleHandlerCount = 0;
nextPollTimeoutMillis = 0;
}
}
??这里肥柴把源码里涉及到IdleHandler处理的进行了注释,重点看注释的地方即可,从而我们可以总结IdleHandler实现的基本原理流程:
??1、如果本次循环拿到的Message为空,或者这个Message是一个延时的消息而且还没到指定的触发时间,那么,就认定当前的队列为空闲状态。
??2、遍历mPendingIdleHandlers数组(这个数组里面的元素每次都会到mIdleHandlers中去拿)来调用每一个IdleHandler实例的queueIdle方法。
??3、如果这个方法返回false的话,那么这个实例就会从 mIdleHandlers 中移除,也就是当下次队列空闲的时候,不会继续回调它的 queueIdle 方法了。
??4、处理完 IdleHandler 后会将 nextPollTimeoutMillis 设置为0,也就是不阻塞消息队列,当然要注意这里执行的代码同样不能太耗时,因为它是同步执行的,如果太耗时肯定会影响后面的 message 执行。
三、使用场景
??根据IdleHandler的特性,其使用场景遵循一个基本原则:在不影响其他任务,在消息队列空闲状态下执行。
??Android Framework层的GC场景就使用了这个机制,只有当cpu空闲的时候才会去GC。
void scheduleGcIdler() {
if (!mGcIdlerScheduled) {
mGcIdlerScheduled = true;
Looper.myQueue().addIdleHandler(mGcIdler);
}
mH.removeMessages(H.GC_WHEN_IDLE);
}
final class GcIdler implements MessageQueue.IdleHandler {
@Override
public final boolean queueIdle() {
doGcIfNeeded();
return false;
}
}
??而我们熟知的内存泄漏检测库LeakCanary,其进行内存泄漏检测并不是 onDestry 方法执行完成后就进行垃圾回收和一些分析的,而是利用 IdleHandler 在空闲的时候进行这些操作的,尽量不去影响主线程的操作。
|