handler机制原理

一,什么是handler
handler是消息机制的一个上层接口更新UI的操作耗时完毕后发送消息给主线程更新UI
耗时操作只能在子线程中执行,Android是线程不安全的你不能在子线程中更新UI 所以Android引入了handler机制
handler通过发送和处理message和Runnable对象来关联相对应线程的MssagerQueue(消息队列)
1.可以让对应的message(message是放置信息，可以传递一些参数)和runnable(Runnable则是直接给出处理的方法)在未来的某个时间进行相应处理
2.让自己想要处理的耗时操作放在子线程,让更新UI操作放在主线程
3.队列就是依次执行，Handler会处理完一个消息或者执行完某个处理在进行下一步，这样不会出现多个线程同时要求进行UI处理而引发的混乱现象
二,handler的使用方法
1.post(runnable) Runnable则是直接给出处理的方法)在未来的某个时间进行相应处理源码底层还是调用了sendmassage(massage)方法
2.sendmassage(massage) 放置信息，可以传递一些参数 ,可以定时处理更新UI
三,handler机制的原理

首先我们先看图

looper
每一个线程所独有的,通过loop()方法读取MessageQueue当中的消息读到消息后,把消息发送给Handler来进行处理
messageQueue
消息队列(先进先出的方式来管理的message),在创建looper的时候就创建了MESSagerQueue,已经关联到了一起
mssage
消息对象

handler
作用1.可以发送消息
作用2.处理消息(处理looper发送过来的消息)

1.1获取looper (mLooper = Looper.myLooper()),通过looper 获取massageQueue( mQueue = mLooper.mQueue;)

  /*** Use the {@link Looper} for the current thread with the specified callback interface* and set whether the handler should be asynchronous.** Handlers are synchronous by default unless this constructor is used to make* one that is strictly asynchronous.** Asynchronous messages represent interrupts or events that do not require global ordering* with respect to synchronous messages.  Asynchronous messages are not subject to* the synchronization barriers introduced by {@link MessageQueue#enqueueSyncBarrier(long)}.** @param callback The callback interface in which to handle messages, or null.* @param async If true, the handler calls {@link Message#setAsynchronous(boolean)} for* each {@link Message} that is sent to it or {@link Runnable} that is posted to it.** @hide*/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 that has not called Looper.prepare()");}mQueue = mLooper.mQueue;mCallback = callback;mAsynchronous = async;}

1.2 looper是怎么获取的呢?

 // sThreadLocal.get() will return null unless you've called prepare().static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>(); /*** Return the Looper object associated with the current thread.  Returns* null if the calling thread is not associated with a Looper.*/public static @Nullable Looper myLooper() {return sThreadLocal.get();}

sThreadLocal.get()作用:通过不同的线程访问同一个ThreadLocal ,不管是get方法还是set方法对所做的读写操作仅限于各自线程内部,这就是为什么handler里边通过ThreadLocal 来保存looper 这样他就可以使每一个线程有单独唯一的looper

1.3 looper作用

 /*** Run the message queue in this thread. Be sure to call* {@link #quit()} to end the 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();for (;;) {Message msg = queue.next(); // might blockif (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 loggerfinal Printer logging = me.mLogging;if (logging != null) {logging.println(">>>>> Dispatching to " + msg.target + " " +msg.callback + ": " + msg.what);}final long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;final long traceTag = me.mTraceTag;if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {Trace.traceBegin(traceTag, msg.target.getTraceName(msg));}final long start = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();final long end;try {msg.target.dispatchMessage(msg);end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();} finally {if (traceTag != 0) {Trace.traceEnd(traceTag);}}if (slowDispatchThresholdMs > 0) {final long time = end - start;if (time > slowDispatchThresholdMs) {Slog.w(TAG, "Dispatch took " + time + "ms on "+ Thread.currentThread().getName() + ", h=" +msg.target + " cb=" + msg.callback + " msg=" + msg.what);}}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();}}

源码中loopr 就是创建了一个FOR的死循环,然后从消息队列中逐个的去获取消息,最后处理消息的过程
总结:looper 是通过prepare 来创建LOOPER 把他保存在ThreadLocal中然后通过lopper.loop()开启循环来进行消息的分发

   /** Initialize the current thread as a looper.* This gives you a chance to create handlers that then reference* this looper, before actually starting the loop. Be sure to call* {@link #loop()} after calling this method, and end it by calling* {@link #quit()}.*/public static void prepare() {prepare(true);}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));}

源码中调用 msg.target.dispatchMessage(msg); target就是一个handler 是中转器 (/*package*/ Handler target;)

handler总结: 通过handler将消息传递给了消息队列(massageQueue) 而消息队列又将消息分发给了handler 来处理,这就是handler的2个作用,一个是接收,发送消息,一个是处理消息

四,handler引起的内存泄露及解决办法

handler发送的消息在当前handler的消息队列中，如果此时activity finish掉了，那么消息队列的消息依旧会由handler进行处理，若此时handler声明为内部类（非静态内部类），我们知道内部类天然持有外部类的实例引用，这样在GC垃圾回收机制进行回收时发现这个Activity居然还有其他引用存在，因而就不会去回收这个Activity，进而导致activity泄露。

解决方案:

1.把handler设置成静态内部类,因为静态内部类不持有外部类的引用，所以使用静态的handler不会导致activity的泄露

2.onDestroy生命周期中调用 handler.removeCallbacks();,进行释放

3.handler内部类持有外部activity的弱引用

handler机制原理相关推荐

Handler机制原理解析（二）prepare，loop，post
Handler机制原理解析(二)prepare,loop,post 上一篇已经介绍了Handler机制的原理,如果不熟悉可以看Handler机制原理解析(一).这一篇,介绍下Handler周边的知识点 ...
Handler机制原理解析（一）
Handler机制原理解析(一) 我们都知道,在Android中,主线程也叫UI线程是负责界面更新的,子线程或者工作线程适合做网络请求,数据库等耗时操作.如果在主线程中执行耗时操作可能引发ANR异常. ...
android Handler机制原理解析（一篇就够，包你形象而深刻）
首先,我将Handler相关的原理机制形象的描述为以下情景: Handler:快递员(属于某个快递公司的职员) Message:包裹(可以放置很多东西的箱子) MessageQueue:快递分拣中心( ...
浅谈Android中的Handler机制
Handler是Android中提供的一种异步回调机制,也可以理解为线程间的消息机制.为了避免ANR,我们通常会把一些耗时操作(比如:网络请求.I/O操作.复杂计算等)放到子线程中去执行,而当子线程需 ...
AsyncTask机制原理解析
AsyncTask机制原理解析 Android为我们提供了2种方便的异步处理方案,Handler和AsyncTask,两种方式适合的场景网上一搜就知道了,但是为什么呢?这篇分析将为你揭晓答案.前面分析 ...
Android 为什么要有handler机制？handler机制的原理
为什么要有handler机制? 在Android的UI开发中,我们经常会使用Handler来控制主UI程序的界面变化.有关Handler的作用,我们总结为:与其他线程协同工作,接收其他线程的消息并通过 ...
Android Handler消息机制原理最全解读（持续补充中）
本文主要详细去解读Android开发中最常使用的Handler,以及使用过程中遇到的各种各样的疑问. Handler 在Android开发的过程中,我们常常会将耗时的一些操作放在子线程(work ...
android handler的机制和原理_第一百八十回：Android中的Handler机制九
各位看官们大家好,上一回中咱们说的是Android中Handler机制的例子,这一回咱们继续说该例子.闲话休提,言归正转.让我们一起Talk Android吧! 看官们,由于时间的原因我们在上一回中只 ...
android Handler机制之ThreadLocal详解
概述我们在谈Handler机制的时候,其实也就是谈Handler.Message.Looper.MessageQueue之间的关系,对于其工作原理我们不做详解(Handler机制详解). Messa ...
Android多线程：深入分析 Handler机制源码（二）
前言在Android开发的多线程应用场景中,Handler机制十分常用接下来,深入分析 Handler机制的源码,希望加深理解目录 1. Handler 机制简介定义一套 Android 消 ...

handler机制原理

handler机制原理相关推荐

最新文章

热门文章