首先需要明白,handler发消息是为了做异步操作.异步大家都很清楚.一个比较常用的例子就是.一个辅助线程要更新UI线程的画面,直接用View操作是不行的.这就需要异步更新.给UI线程发消息,让他更新.
那Handler是如何做到异步发消息更新的呢?需要解决以下几个问题.
系统如何知道我这个handler是给哪个线程发消息.
系统是如何做到异步的呢?
看代码吧.在UI线程启动后,会
public static final void prepare() {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper());
}
这样就创建了个Looper, 并且在构造函数中创建消息队列,并且集注当前线程.
private Looper() {
mQueue = new MessageQueue(); //转载者补充:消息队列是由Looper创建的
mRun = true;
mThread = Thread.currentThread();
}
当我们在创建handler对象时候.以下代码位于Handler的构造函数中。
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
在我们handler里会有了这个looper引用。以及得到该looper的消息队列.
MessageQueue
消息队列MessageQueue是一个以执行时间为序的优先级队列:
o 普通消息的执行为当前时间,先发送的在前面,后发送在后面,这是典型的FIFO。
o 最高优先级的消息执行时间为0,所以直接插在队列的最前面,通常会立即执行。
o 而在将来执行的Message相当于timer,执行时间为当前时间+delay的时间。
MessageQueue的函数boolean enqueueMessage(Message msg, long when)用来向队列中插入消息。
那如何证明这句话呢?
看enqueueMessage的具体实现过程.
msg.when = when;
//Log.d("MessageQueue", "Enqueing: " + msg);
Message p = mMessages;
if (p == null || when == 0 || when < p.when) {
msg.next = p;
mMessages = msg;
this.notify();
} else {
Message prev = null;
while (p != null && p.when <= when) {
prev = p;
p = p.next;
}
msg.next = prev.next;
prev.next = msg;
this.notify();
这就看出来了,根据when把消息插到消息队列里,根据时间顺序,时间值小的放前面,大的放后面.排序了.
转载者补充:用链表实现了消息队列,如果当前消息的when为0或者小于消息队列第一个消息的when,那么就把该message作为链表(消息队列)的第一个元素,将mMessage指向它,即mMessage指向消息队列的第一个元素。否则,将遍历这个消息队列链表,直到找到比当前message的when大的消息,并在之前插入。
Handler
Handler 对消息队列的enqueueMessage做了包装,这其实并不重要,因为完全可以直接调用enqueueMessage来实现。重要的Handler在包装enqueueMessage的同时,把Message的target设成了自己,即为Message指定执行的行为:
public boolean sendMessageAtTime(Message msg, long uptimeMillis)
{
boolean sent = false;
MessageQueue queue = mQueue;
if (queue != null) {
msg.target = this;
sent = queue.enqueueMessage(msg, uptimeMillis);
}
这样一来,当前Message被处理的时候就会调用Handler的dispatchMessage,而这个函数就会调用你要实现的虚函数handleMessage了。经过消息队列代码转了一圈,还是调用了你自己的实现函数,但是同步操作变成了异步操作。
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
当我们send消息时候,过程就很明朗了.
所有的发送消息的动作代码都会跑这步.把消息按系统时间送到消息队列里.那发送进去了.什么时候取出来呢?
Message放在消息队列里了,谁来一个一个的取出来处理呢?这时轮到Looper上场了,它的函数loop会一直循环处理队列中的消息,直到遇上一个没有target的Message:
public static final void loop() {
Looper me = myLooper();
MessageQueue queue = me.mQueue;
while (true) {
Message msg = queue.next(); // might block
//if (!me.mRun) {
// break;
//}
if (msg != null) {
if (msg.target == null) {
// No target is a magic identifier for the quit message.
return;
}
if (me.mLogging!= null) me.mLogging.println(
">>>>> Dispatching to " + msg.target + " "
+ msg.callback + ": " + msg.what
);
msg.target.dispatchMessage(msg);
if (me.mLogging!= null) me.mLogging.println(
"<<<<< Finished to " + msg.target + " "
+ msg.callback);
msg.recycle();
}
}
}
由此可见:一个Looper总是和一个MessageQueue关联起来的。
Thread
loop只是一个函数,它也需要别人来执行它。由于它一执行就会阻塞在那里,所以一定需要一个线程来调用:
* class LooperThread extends Thread {
* public Handler mHandler;
*
* public void run() {
* Looper.prepare();
*
* mHandler = new Handler() {
* public void handleMessage(Message msg) {
* // process incoming messages here
* }
* };
*
* Looper.loop();
* }
* }
一个Looper也总是和一个Thread关联起来的,不过不一定要创建新线程,可以是主线程的。Handler和Thread不是一一对应的,理论上,在一个LooperThread中,可以有任何多个Handler,每个消息都可以指定不同的Handler,因为每个消息都可以有不同的行为。
在创建Handler时并不会创建Thread,它只是取当前线程的Looper的MessageQueue:
public Handler() {
if (FIND_POTENTIAL_LEAKS) {
final Class<? extends Handler> klass = getClass();
if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
(klass.getModifiers() & Modifier.STATIC) == 0) {
Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
klass.getCanonicalName());
}
}
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = null;
}
通过myLooper取出当前线程的Looper:
public static final Looper myLooper() {
return (Looper)sThreadLocal.get();
}
这个Looper是在Looper.prepare里创建的:
public static final void prepare() {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper());
}
这个过程就很清楚了,UI线程启动后,会不断的从消息队列取消息,当没有消息时候,会
while (true) {
Message msg = queue.next(); // might block
在这阻塞,直到有消息近来,然后通过 msg.target.dispatchMessage(msg);
来调用我们的handler注册的HandleMessage来处理消息.
转自:http://www.wscxy.com/nuaa/article.asp?id=116
分享到:
相关推荐
NULL 博文链接:https://dingran.iteye.com/blog/1930178
android handler 机制源码 (带部分汉语注释)
在上一篇文章《Android应用程序消息处理机制(Looper、Handler)分析》中,我们分析了Android应用程序的消息处理机制,本文将结合这种消息处理机制来详细分析Android应用程序是如何获得键盘按键消息的。
Android Handler 原理分析 Handler一个让无数android开发者头疼的东西,希望我今天这边文章能为您彻底根治这个问题 今天就为大家详细剖析下Handler的原理 Handler使用的原因 1.多线程更新Ui会导致UI界面错乱 2.如果...
Android应用程序消息处理机制(Looper、Handler)分析
其中sMainLooper是个全局静态Looper,目前android系统特指为UI主Main线程对应的消息,这么设定,应该是大部分的消息处理只需要放到主Mai
主要介绍了Android Handler leak分析及解决办法详解的相关资料,需要的朋友可以参考下
先上图,让大家好理解下handler机制:handler机制示例图上面一共出现了几种类,ActivityThread,Handler,MessageQueue,Looper,msg(Message),对这些类作简要介绍:ActivityThread:程序的启动入口,为什么要介绍...
主要介绍了Android定时器和Handler用法,实例分析了Android中的定时器与Handler相关使用技巧,非常具有实用价值,需要的朋友可以参考下
本文主要介绍 Android Handle机制实现的原理,这里整理了详细的关于Handler的资料以及工作流程和实际应用,有兴趣的小伙伴可以参考下
Demo-实例讲解线程池里面的UI如何刷新,处理两个开发者头疼的问题: 1. 数据经常需要读取更新,并且比较耗时,需要分步刷新UI. 2. UI界面切换后,如何停止掉子线程里面正在读取的数据而不会将旧数据刷新到新UI界面上...
内存泄露的危害就是会使虚拟机占用内存过高,导致OOM(内存溢出),程序出错。接下来通过本文给大家分享Android使用Handler造成内存泄露问题及解决方法,一起看看吧
Android Handler Message源码解析和手写实现
主要为大家详细分析了Android Handler消息派发机制源码,感兴趣的小伙伴们可以参考一下
当我们在处理下载或是其他需要长时间执行的任务时,如果直接把处理函数... 以下模拟一个简单的小球上下跳动的案例来分析Handler的工作模式。 详细博客链接:http://blog.csdn.net/a13429921973/article/details/9279941
Android应用程序消息处理机制(Looper、Handler)分析[收集].pdf
本篇文章小编为大家介绍,Android Handler主线程和一般线程通信的应用分析。需要的朋友参考下
最近总结了一下handler的使用,handler是Android中要的消息机制之一,在面试和实际开发中尤为重要,所以总结了一下,传到这里,和大家交流学习