详解Android Handler机制和Looper Handler Message关系
概述
我们就从以下六个问题来探讨handler 机制和looper、handler、message之前的关系?
1.一个线程有几个handler?
2.一个线程有几个looper?如何保证?
3.handler内存泄漏原因?为什么其他的内部类没有说过这个问题?
4.为何主线程可以new handler?如果在想要在子线程中new handler 要做些什么准备?
5.子线程中维护的looper,消息队列无消息的时候的处理方案是什么?有什么用?
6.looper死循环为什么不会导致应用卡死?
一、源码解析
1.looper
对于looper主要是prepare()和loop()两个方法
首先看prepare()方法
private static void prepare(boolean quitallowed) { if (sthreadlocal.get() != null) { throw new runtimeexception("only one looper may be created per thread"); } sthreadlocal.set(new looper(quitallowed)); }
可以看出sthreadlocal是一个threadlocal对象,threadlocal 并不是线程,而是一个线程内部的存储类,可以在线程内存储数据.在第5行可以看到,将一个looper实例放入了
threadlocal,并且在第2~4行判断了sthreadlocal是否为空,否则抛出异常.这也looper.prepare()方法不能被调用两次.这也对应了上面的第二个问题.
下面来看looper的构造方法:
private looper(boolean quitallowed) { mqueue = new messagequeue(quitallowed); mthread = thread.currentthread(); }
在looper的构造方法中创建了一个messagequeue(消息队列)
然后我们在看loop()方法:
public static void loop() { final looper me = mylooper(); if (me == null) { throw new runtimeexception("no looper; looper.prepare() wasn't called on this thread."); } final messagequeue queue = me.mqueue; // make sure the identity of this thread is that of the local process, // and keep track of what that identity token actually is. binder.clearcallingidentity(); final long ident = binder.clearcallingidentity(); // allow overriding a threshold with a system prop. e.g. // adb shell 'setprop log.looper.1000.main.slow 1 && stop && start' final int thresholdoverride = systemproperties.getint("log.looper." + process.myuid() + "." + thread.currentthread().getname() + ".slow", 0); boolean slowdeliverydetected = false; for (;;) { message msg = queue.next(); // might block if (msg == null) { // no message indicates that the message queue is quitting. return; } // this must be in a local variable, in case a ui event sets the logger final printer logging = me.mlogging; if (logging != null) { logging.println(">>>>> dispatching to " + msg.target + " " + msg.callback + ": " + msg.what); } final long tracetag = me.mtracetag; long slowdispatchthresholdms = me.mslowdispatchthresholdms; long slowdeliverythresholdms = me.mslowdeliverythresholdms; if (thresholdoverride > 0) { slowdispatchthresholdms = thresholdoverride; slowdeliverythresholdms = thresholdoverride; } final boolean logslowdelivery = (slowdeliverythresholdms > 0) && (msg.when > 0); final boolean logslowdispatch = (slowdispatchthresholdms > 0); final boolean needstarttime = logslowdelivery || logslowdispatch; final boolean needendtime = logslowdispatch; if (tracetag != 0 && trace.istagenabled(tracetag)) { trace.tracebegin(tracetag, msg.target.gettracename(msg)); } final long dispatchstart = needstarttime ? systemclock.uptimemillis() : 0; final long dispatchend; try { msg.target.dispatchmessage(msg); dispatchend = needendtime ? systemclock.uptimemillis() : 0; } finally { if (tracetag != 0) { trace.traceend(tracetag); } } if (logslowdelivery) { if (slowdeliverydetected) { if ((dispatchstart - msg.when) <= 10) { slog.w(tag, "drained"); slowdeliverydetected = false; } } else { if (showslowlog(slowdeliverythresholdms, msg.when, dispatchstart, "delivery", msg)) { // once we write a slow delivery log, suppress until the queue drains. slowdeliverydetected = true; } } } if (logslowdispatch) { showslowlog(slowdispatchthresholdms, dispatchstart, dispatchend, "dispatch", msg); } if (logging != null) { logging.println("<<<<< finished to " + msg.target + " " + msg.callback); } // make sure that during the course of dispatching the // identity of the thread wasn't corrupted. final long newident = binder.clearcallingidentity(); if (ident != newident) { log.wtf(tag, "thread identity changed from 0x" + long.tohexstring(ident) + " to 0x" + long.tohexstring(newident) + " while dispatching to " + msg.target.getclass().getname() + " " + msg.callback + " what=" + msg.what); } msg.recycleunchecked(); } }
第2行:final looper me = mylooper();
public static @nullable looper mylooper() { return sthreadlocal.get(); }
第6行:拿到改looper实例中的mqueue(消息队列)
第23~98行:进入了一个死循环,
第24行:message msg = queue.next(); next()方法里会一直去取消息,然后会加锁,就会一直堵塞进程,这也就是我们经常说的looper死循环为什么不会导致死机.在这next()源码就不粘贴了,后面会说这个为什么不会死机的问题.
第57行: 调用msg.target.dispatchmessage(msg); 把消息交给msg的target的dispatchmessage()方法去处理.msg的target是什么呢?其实就是handler对象,下面会分析.
第97行:释放消息占用的资源
looper的主要作用:
与当前线程绑定,保证一个线程只会有一个looper实例,同时一个looper实例也是只有一个messagequeue.
loop()方法,不断从messagequeue中去取消息,交给消息的target属性的dispatchmessage()去处理.
2.handler
使用handler之前,我们都是初始化一个实例,比如用于更新ui线程,我们会在声明的时候直接初始化,或者在oncreate中初始化handler实例.所以我们首先看handler的构造方法,
看其如何与messagequeue联系上的,它的子线程中发送的消息(一般发送的消息都是在非ui线程)怎么发送到messagequeue中的.
public handler(callback callback) { this(callback, false); } public handler(callback callback, boolean async) { 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 " + thread.currentthread() + " that has not called looper.prepare()"); } mqueue = mlooper.mqueue; mcallback = callback; masynchronous = async; }
第15行:通过looper.mylooper()获取了当前线程保存的looper实例,然后在19行又获取了这个looper实例中保存的messagequeue(消息队列)
这样就保证了handler的实例与我们looper实例中messagequeue关联上了,
然后我们再看最常用的sendmessage方法:
public final boolean sendmessage(message msg) { return sendmessagedelayed(msg, 0); }
public final boolean sendemptymessagedelayed(int what, long delaymillis) { message msg = message.obtain(); msg.what = what; return sendmessagedelayed(msg, delaymillis); }
public final boolean sendmessagedelayed(message msg, long delaymillis) { if (delaymillis < 0) { delaymillis = 0; } return sendmessageattime(msg, systemclock.uptimemillis() + delaymillis); }
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); }
看到最后我们发现最后调用了sendmessageattime,在此方法内部有直接获取messagequeue然后调用了enqueuemessage方法,我们再来看此方法:
private boolean enqueuemessage(messagequeue queue, message msg, long uptimemillis) { msg.target = this; if (masynchronous) { msg.setasynchronous(true); } return queue.enqueuemessage(msg, uptimemillis); }
enqueuemessage中首先为meg.target赋值为this, 在looper的loop()方法会取出每个msg然后交给msg,target.dispatchmessage(msg)去处理消息,也就是把当前的handler作为
msg的target属性,最终会调用queue的enqueuemessage的方法,也就是说handler发出饿消息,最终会保存到消息队列中去.
现在已经很清楚了:looper会调用prepare()和loop()方法,在当前执行的线程中保存一个looper实例,这个实例会保存一个messagequeue对象,然后在当前的线程进入一个
无限循环中去,不断地从messagequeue中读取handler发来的消息.然后在回调创建这个消息的handler的dispatchmessage()方法.下面看一下dispathmessage方法:
public void dispatchmessage(message msg) { if (msg.callback != null) { handlecallback(msg); } else { if (mcallback != null) { if (mcallback.handlemessage(msg)) { return; } } handlemessage(msg); } }
第10行: 调用了handlemessage()方法,下面我们看这个方法:
/** * subclasses must implement this to receive messages. */ public void handlemessage(message msg) { }
可以看到这个是一个空方法,为什么呢?因为消息的最终回调是由我们控制的,我们在创建handler的时候都是重写handlemessage方法,然后根据msg.what进行消息处理的
例如:
private handler mhandler = new handler() { public void handlemessage(android.os.message msg) { switch (msg.what) { case value: break; default: break; } }; };
整个流程已经说完了,总结一哈:
1.首先looper,prepare()方法在本线程中保存了一个looper实例,然后该实例中保存一个messagequeue对象;因为looper.prepare()在一个线程中只能调用一次,
所以messagequeue在一个线程中只会存在一个.
2.looper.loop()会让当前的线程进入一个无限循环,不断地从messagequeue的实例中读取消息,然后回调,msg.target.dispatchmessage(msg)方法.
3.handler的构造方法,会首先得到当前线程中保存的looper实例,进而与looper实例的messagequeue相关联.
4.handler的sendmessage()方法,会给msg的target赋值为handler自身,然后加入messagequeue中.
5.在构造handler实例时,我们会重写handlermessage方法.也就是msg.target,dispatchmessage(msg)最终调用的方法.
回过头来来看我们的之前的六个问题:
二、分析问题
1.一个线程有几个handler?
我相信大家应该都使用过handler,所以这个问题的答案:多个
这个问题没有什么好分析的,大家也亲身使用过!
2.一个线程有几个looper?如何保证?
一个线程能有多个handler,那么会产生多少个looper呢? 答案: 1个
为什么?如何保证呢?
在源码分析中,可以看到stheadlocal会实例一个looper,如果在同一个线程中再次调用looper.prepare方法,会抛出异常:only one looper may be created per thread
说明了同一个线程只能实例looper对象.
3.handler内存泄漏原因?
为什么其他的内部类没有说过这个问题?
handler内存泄漏原因? 答案: 内部类引用外部类方法
private handler mhandler =new handler(){ @override public void handlemessage(message msg) { super.handlemessage(msg); switch (msg.what){ case 0: setlog(); break; default: break; } } }; private void setlog() { log.d(tag,"this is log!"); } @override public void onclick(view v) { switch (v.getid()){ case r.id.create_xml: log.d(tag,"create_xml"); mhandler.sendmessagedelayed(0,1000*60); break; default: break; }
创建一个匿名内部类handler, 这时候我发延迟sendmessagedelayed()执行setlog()方法,但这个时候我如果强行关闭activity,这个时候activity会被销毁,但是这个handler得不到
释放,因为还要延迟一分钟才能执行setlog()方法,这个时候就会造成内存泄漏.
其他的内部类为什么不会?
很简单,比如listview的viewholder这个常用的匿名内部类,如果当主activity销毁,这个时候viewholder内部类,也是直接被销毁的!所以不会出现内存泄漏问题!
4.为何主线程可以new handler?
如果在想要在子线程中new handler 要做些什么准备?
由前面的讲解,可以看出new handler的条件是需要一个looper对象,而looper对象需要调用两个方法prepare()和loop()方法,大家可以看下面主线程的main方法
public static void main(string[] args) { trace.tracebegin(trace.trace_tag_activity_manager, "activitythreadmain"); // install selective syscall interception androidos.install(); // closeguard defaults to true and can be quite spammy. we // disable it here, but selectively enable it later (via // strictmode) on debug builds, but using dropbox, not logs. closeguard.setenabled(false); environment.initforcurrentuser(); // make sure trustedcertificatestore looks in the right place for ca certificates final file configdir = environment.getuserconfigdirectory(userhandle.myuserid()); trustedcertificatestore.setdefaultuserdirectory(configdir); process.setargv0("<pre-initialized>"); looper.preparemainlooper(); // find the value for {@link #proc_start_seq_ident} if provided on the command line. // it will be in the format "seq=114" long startseq = 0; if (args != null) { for (int i = args.length - 1; i >= 0; --i) { if (args[i] != null && args[i].startswith(proc_start_seq_ident)) { startseq = long.parselong( args[i].substring(proc_start_seq_ident.length())); } } } activitythread thread = new activitythread(); thread.attach(false, startseq); if (smainthreadhandler == null) { smainthreadhandler = thread.gethandler(); } if (false) { looper.mylooper().setmessagelogging(new logprinter(log.debug, "activitythread")); } // end of event activitythreadmain. trace.traceend(trace.trace_tag_activity_manager); looper.loop(); throw new runtimeexception("main thread loop unexpectedly exited"); }
这个main方法,是所有的程序启动之前,都要走的这个main方法
第20行:调用了一个looper.preparemainlooper();
第47行:调用了一个looper.loop();
而looper.preparemainlooper()源码:
public static void preparemainlooper() { prepare(false); synchronized (looper.class) { if (smainlooper != null) { throw new illegalstateexception("the main looper has already been prepared."); } smainlooper = mylooper(); } }
第2行:可以看到调用了looper里的prepare()方法;
所以说可以在一个主线程中直接new handler
那如果在一个子线程new handler的话,需要做什么准备?
当然是要需要:调用一个looper.prepar()和looper.loop()方法了。
5.子线程中维护的looper,消息队列无消息的时候的处理方案是什么?有什么用?
在子线程使用handler时,调用looper.loop()方法,在上面的源码中,可以看到【message msg = queue.next(); // might block】会一直卡死在这个地方?那我们怎么解决这个问题呢?
在looper方法中有个quitsafely()方法,这个方法会干掉messagequeue(消息队列)中的所有消息而释放内存和释放线程。
这个时候回到第四个问题,在子线程中创建handler,需要准备什么?
调用三个方法:
- looper.prepare()
- looper.loop()
- handler.getlooper().quit();
6.looper死循环为什么不会导致应用卡死?
了解这个问题,首先我们要了解,什么情况下才会导致应用卡死?
卡死也就会会出现应用无响应,也就是我们常说的anr,出现anr问题有两种:
- 在5秒内没有响应输入事件,如:按键按下,屏幕触摸
- broadcastreceiver在10秒内没有执行完毕
了解这个了我们就会发现,在导致looper死循环的问题是message msg = queue.next()这个方法,看了next()源码,简单的可以说这个程序是在睡眠,从而在next()方法中调用wake()方法可以唤醒程序,从而不会导致应用出现anr问题.
以上就是详解android handler机制和looper handler message关系的详细内容,更多关于android handler机制和looper handler message关系的资料请关注其它相关文章!
推荐阅读
-
Android消息处理机制Looper和Handler详解
-
Android Studio 之 Android消息机制 之简单Demo --- 使用Handler和Message类来完成消息传递
-
Android异步2:深入详解 Handler+Looper+MessageQueue
-
Android消息机制(3)- Handler和Looper
-
Android Handler 机制 - Looper,Message,MessageQueue
-
Android消息通信机制Handler详解,Handler,Looper,MessageQueue,源码解析,讲解这几个类怎么配合工作的
-
Android消息处理机制(Handler、Looper、MessageQueue与Message)
-
Android异步消息处理机制 深入理解Looper、Handler、Message的关系
-
简述android线程间消息处理机制(Looper、Handler和Message)
-
Android消息机制三剑客之Handler、Looper、Message源码分析(一)