android handler机制源码解析
android handler、looper异步消息处理机制
可能萌新感觉异步消息处理这个东西很高端,其实我们平时一直在用,最常用的该是子线程通知ui线程刷新了吧。sendMessage、handleMessage是不是突然间感觉就来了。
异步消息处理当然离不开handler、looper、message以及messageQueue、threadLocal.....
那么先从handler开始
handler的主要作用其实就是sendMessage handleMessage。不过呢发送msg有好几个函数(androidStuido输入handler.send会弹出好几个方法),最后基本上都是走这个关键的函数
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
return enqueueMessage(queue, msg, uptimeMillis);
}
可以看到最后是要enqueueMessage(queue, msg, uptimeMillis);的,可以理解为把这次handler发送的msg发到对应的queue(messageQueue)里面,延迟时间为uptimeMillis。
说到messageQueue,要有这个意识(暂且记住,后面会详解)
handler必须持有一个looper,这个是在构造handler的时候就会拿到的
不管是否是ui线程的mainLooper,handler使用的时候一定要有looper,比如Toast在子线程使用时可以不使用ui线程的mainLooper,但是必须有一个looper,不然会抛出异常。looper和一个massageQueue对应,并且和一个线程对应(注意了啊和线程相关的来了),一个线程最多有一个looper
由上面三条我们暂且可以得到这个信息:在创建handler的线程会绑定一个looper,既然有looper肯定有一个专门的messageQueue.那么假如我在子线程Anew了一个handler(前提是该线程要prepare一个looper),那么这个子线程A就会有一个在该线程一直循环的looper来处理该线程messageQueue里面的msg。
然后如果我在另外一个线程B获取到了该handler的对象,然后发送一个msg,因为handler、looper、messageQueue是对应的,所以发送的msg最后是入队到了创建该handler线程A的messageQueue上。已经切到A线程就很简单了啊,queue里面的msg取出来处理就完了。
好,现在我们已经发送msg,并且送到对应的queue里面了。接下来,Looper会一直循环的询问它的messageQueue是否来消息了,一旦来了就会把msg取出来,然后让它对应的handler.dispatchMessage来分发这个消息。
直接上源码:
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
可以看到我们经常用的handleMessage(msg)是在最后,需要前面的都放弃,才会执行到它。那么前面的msg.callback以及mCallback是什么呢?
先说msg.callback
查看Message源码发现msg.callback实际上是一个Runnable;不知道大家除了handler.sendMessage 以及handleMessage之外 handler.post(Runnable)、view.post(Runnable)、runOnUiThread(Runnable)有没有使用过;这些都是可以实现在子线程通知ui线程进行更新UI操作。
这里面的Runnable参数就是msg.callback。其实上面3种方式到后面都调用了handler.post,那我们就看一下这个是干什么的
public final boolean post(Runnable r)
{
return sendMessageDelayed(getPostMessage(r), 0);
}
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
可以看到把runnable设置给msg后,到后面又是sendMessageAtTime(不记得的往上翻)。
所以啊,如果以上面三种方式,handler.handleMessage是不会触发的哦,因为根本就没走到那里,而是走了handleCallback(msg);`
private static void handleCallback(Message message) {
message.callback.run();
}
请牢记,通过handler把消息放到了对应的msgQueue里面的时候,因为msgQueue和Looper是绑定的,所以等到looper用对应的handler dispatch消息的时候,已经切到了创建looper的线程了。
再简单说一下mCallback
这其实是一个回调接口,创建handler的时候可以传几个参数:looper、mcallBack、flag。平时我们什么默认值,其中mcallBack=Null;当然也可以实现这个回调接口,重写回方法
像这样:
handler = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
Log.v("tag","uiThread 接口回调 :"+Thread.currentThread().getId());
return true;
}
}){
@Override
public void handleMessage(Message msg) {
// super.handleMessage(msg);
Log.v("tag","uiThread 重写handleMessage:"+Thread.currentTead().getId());
}
};
再看上面dispatchMessage方法回调方法返回false则会继续执行到handler.handlerMessage();返回true就直接return了。
现在我们对handler的发消息和处理消息应该有比较清晰的认识了。只是还需合Looper来看。提到一个looper对应一个线程那一定要看ThreadLocal。 这些下次再详细讲解。
上面提到的几种发送消息的方式基本上最后都是执nqueuessage(queue, msg, 0);是因为有一种方式是sendMessageAtFrontOfQueue(Message msg)它会直接到消息入队那里 enqueueMessage(queue, msg, 0);
题外话:源码什么的,不懂就反复看;能点进去就带着好奇心点进去看看,如果是红的,点不动到frameWork了,就暂时不要导入frameWork源码深入了,这个有点多。如果最后点进去是native方法,涉及到JNI了,也暂停。等后面熟悉了sdk的源码再接触frameWork和jni。
上一篇: Handler Looper源码解析(Android消息传递机制)
下一篇: 原生js实现拖拽