Handler消息机制关键类详解
Posted 小陈乱敲代码
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Handler消息机制关键类详解相关的知识,希望对你有一定的参考价值。
Handler机制关键类
一、ThreadLocal
概述
ThreadLocal是Java中一个用于线程内部存储数据的工具类。
ThreadLocal是用来存储数据的,但是每个线程只能访问到各自线程的数据。我们一般的用法是:
ThreadLocal<String> stringLocal = new ThreadLocal<>();
stringLocal.set("java");
String s = stringLocal.get();
不同的线程之间访问到的数据是不一样的:
public static void main(String[] args)
ThreadLocal<String> stringLocal = new ThreadLocal<>();
stringLocal.set("java");
System.out.println(stringLocal.get());
new Thread()
System.out.println(stringLocal.get());
结果:
java
null
线程只能访问到自己线程存储的数据。
ThreadLocal的作用
ThreadLocal的特性适用于同样的数据类型,不同的线程有不同的备份情况,如我们这篇文章一直在讲的Looper。每个线程都有一个对象,但是不同线程的Looper是不一样的,这个时候就特别适合使用ThreadLocal来存储数据,这也是为什么这里要讲ThreadLocal的原因
ThreadLocal内部结构
ThreadLocal的内部机制结构如下:
每个Thread,也就是每个线程内部维护有一个ThreadLocalMap,ThreadLocalMap内部存储多个Entry。Entry可以理解为键值对,他的本质是一个弱引用,内部有一个object类型的内部变量。
Entry是ThreadLocalMap的一个静态内部类,这样每个Entry里面就维护了一个ThreadLocal和ThreadLocal泛型对象。每个线程的内部维护有一个Entry数组,并通过hash算法使得读取数据的速度达到O(1)。由于不同的线程对应的Thread对象不同,所以对应的ThreadLocalMap肯定也不同,这样只有获取到Thread对象才能获取到其内部的数据,数据就被隔离在不同的线程内部了。
ThreadLocal工作流程
那ThreadLocal是怎么实现把数据存储在不同线程中的?先从他的set方法入手:
TheadLocal.class
public void set(T value)
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
逻辑不是很复杂,首先获取当前线程的Thread对象,然后再获取Thread的ThreadLocalMap对象,如果该map对象不存在则创建一个并调用他的set方法把数据存储起来。我们继续看ThreadLocalMap的set方法:
ThreadLocalMap.class
private void set(ThreadLocal<?> key, Object value)
// 每个ThreadLocalMap内部都有一个Entry数组
Entry[] tab = table;
int len = tab.length;
// 获取新的ThreadLocal在Entry数组中的下标
int i = key.threadLocalHashCode & (len-1);
// 判断当前位置是否发生了Hash冲突
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)])
ThreadLocal<?> k = e.get();
// 如果数据存在且相同则直接返回
if (k == key)
e.value = value;
return;
if (k == null)
replaceStaleEntry(key, value, i);
return;
// 若当前位置没有其他元素则直接把新的Entry对象放入
tab[i] = new Entry(key, value);
int sz = ++size;
// 判断是否需要对数组进行扩容
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
这里的逻辑和HashMap是很像的,我们可以直接使用HashMap的思维来理解ThreadLocalMap:ThreadLocalMap的key是ThreadLocal,value是ThreadLocal对应的泛型。他的存储步骤如下:
根据自身的threadLocalHashCode与数组的长度进行相与得到下标
如果此下标为空,则直接插入
如果此下标已经有元素,则判断两者的ThreadLocal是否相同,相同则更新value后返回,否则找下一个下标
直到找到合适的位置把entry对象插入
最后判断是否需要对entry数组进行扩容
是不是和HashMap非常像?和HashMap的不同是:hash算法不一样,以及这里使用的是开发地址法,而HashMap使用的是链表法。ThreadLocalMap牺牲一定的空间来换取更快的速度。具体的Hash算法这里就不再深入了,有兴趣的读者可以阅读这篇文章ThreadLocal传送门
然后继续看ThreadLocal的get方法:
ThreadLocal.class
public T get()
// 获取当前线程的ThreadLocalMap
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
// 根据ThreadLocal获取Entry对象
ThreadLocalMap.Entry e = map.getEntry(this);
// 如果没找到也会执行初始化工作
if (e != null)
@SuppressWarnings("unchecked")
// 把获取到的对象进行返回
T result = (T)e.value;
return result;
return setInitialValue();
前面讲到ThreadLocalMap其实非常像一个HashMap,他的get方法也是一样的。使用ThreadLocal作为key获取到对应的Entry,再把value返回即可。如果map尚未初始化则会执行初始化操作。下面继续看下ThreadLocalMap的get方法:
ThreadLocalMap.class
private Entry getEntry(ThreadLocal<?> key)
// 根据hash算法找到下标
int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
// 找到数据则返回,否则通过开发地址法寻找下一个下标
if (e != null && e.get() == key)
return e;
else
return getEntryAfterMiss(key, i, e);
利用ThreadLocal的threadLocalHashCode得到下标,然后根据下标找到数据。没找到则根据算法寻找下个下标。
内存泄露问题
我们会发现Entry中,ThreadLocal是一个弱引用,而value则是强引用。如果外部没有对ThreadLocal的任何引用,那么ThreadLocal就会被回收,此时其对应的value也就变得没有意义了,但是却无法被回收,这就造成了内存泄露。怎么解决?在ThreadLocal回收的时候记得调用其remove方法把entry移除,防止内存泄露。
ThreadLocal总结
ThreadLocal适合用于在不同线程作用域的数据备份
ThreadLocal机制通过在每个线程维护一个ThreadLocalMap,其key为ThreadLocal,value为ThreadLocal对应的泛型对象,这样每个ThreadLocal就可以作为key将不同的value存储在不同Thread的Map中,当获取数据的时候,同个ThreadLocal就可以在不同线程的Map中得到不同的数据。
ThreadLocalMap类似于一个改版的HashMap,内部也是使用数组和Hash算法来存储数据,使得存储和读取的速度非常快。
同时使用ThreadLocal需要注意内存泄露问题,当ThreadLocal不再使用的时候,需要通过remove方法把value移除。
二、Message
概述
Message是负责承载消息的类,主要是关注他的内部属性:
// 用户自定义,主要用于辨别Message的类型
public int what;
// 用于存储一些整型数据
public int arg1;
public int arg2;
// 可放入一个可序列化对象
public Object obj;
// Bundle数据
Bundle data;
// Message处理的时间。相对于1970.1.1而言的时间
// 对用户不可见
public long when;
// 处理这个Message的Handler
// 对用户不可见
Handler target;
// 当我们使用Handler的post方法时候就是把runnable对象封装成Message
// 对用户不可见
Runnable callback;
// MessageQueue是一个链表,next表示下一个
// 对用户不可见
Message next;
循环利用Message
当我们获取Message的时候,官方建议是通过Message.obtain()方法来获取,当使用完之后使用recycle()方法来回收循环利用。而不是直接new一个新的对象:
public static Message obtain()
synchronized (sPoolSync)
if (sPool != null)
Message m = sPool;
sPool = m.next;
m.next = null;
m.flags = 0; // clear in-use flag
sPoolSize--;
return m;
return new Message();
Message维护了一个静态链表,链表头是sPool,Message有一个next属性,Message本身就是链表结构。sPoolSync是一个object对象,仅作为解决并发访问安全设计。当我们调用obtain来获取一个新的Message的时候,首先会检查链表中是否有空闲的Message,如果没有则新建一个返回。
当我们使用完成之后,可以调用Message的recycle方法进行回收:
public void recycle()
if (isInUse())
if (gCheckRecycle)
throw new IllegalStateException("This message cannot be recycled because it "
+ "is still in use.");
return;
recycleUnchecked();
如果这个Message正在使用则会抛出异常,否则则调用recycleUnchecked进行回收:
void recycleUnchecked()
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = UID_NONE;
workSourceUid = UID_NONE;
when = 0;
target = null;
callback = null;
data = null;
synchronized (sPoolSync)
if (sPoolSize < MAX_POOL_SIZE)
next = sPool;
sPool = this;
sPoolSize++;
这个方法的逻辑也非常简单,把Message中的内容清空,然后判断链表是否达到最大值(50),然后插入链表中。
Message总结
Message的作用就是承载消息,他的内部有很多的属性用于给用户赋值。同时Message本身也是一个链表结构,无论是在MessageQueue还是在Message内部的回收机制,都是使用这个结构来形成链表。同时官方建议不要直接初始化Message,而是通过Message.obtain()方法来获取一个Message循环利用。一般来说我们不需要去调用recycle进行回收,在Looper中会自动把Message进行回收,后面会讲到。
三、MessageQueue
概述
每个线程都有且只有一个MessageQueue,他是一个用于承载消息的队列,内部使用链表作为数据结构,所以待处理的消息都会在这里排队。前面讲到ThreadLocalMap是一个“修改版的HashMap”,而MessageQueue就是一个“修改版的LinkQueue”。他也有两个关键的方法:入队(enqueueMessage)和出队(next)。这也是MessageQueue的重点所在。
Message还涉及到一个关键概念:线程休眠。当MessageQueue中没有消息或者都在等待中,则会将线程休眠,让出cpu资源,提高cpu的利用效率。进入休眠后,如果需要继续执行代码则需要将线程唤醒。当方法暂时无法直接返回需要等待的时候,则可以将线程阻塞,即休眠,等待被唤醒继续执行逻辑。这部分内容也会在后面详细讲。
关键方法
出队 – next()
next方法主要是做消息出队工作。
Message next()
// 如果looper已经退出了,这里就返回null
final long ptr = mPtr;
if (ptr == 0)
return null;
...
// 阻塞时间
int nextPollTimeoutMillis = 0;
for (;;)
if (nextPollTimeoutMillis != 0)
Binder.flushPendingCommands();
// 阻塞对应时间
nativePollOnce(ptr, nextPollTimeoutMillis);
// 对MessageQueue进行加锁,保证线程安全
synchronized (this)
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
...
if (msg != null)
if (now < msg.when)
// 下一个消息还没开始,等待两者的时间差
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
else
// 获得消息且现在要执行,标记MessageQueue为非阻塞
mBlocked = false;
// 链表操作
if (prevMsg != null)
prevMsg.next = msg.next;
else
mMessages = msg.next;
msg.next = null;
msg.markInUse();
return msg;
else
// 没有消息,进入阻塞状态
nextPollTimeoutMillis = -1;
...
代码很长,其中还涉及了同步屏障和IdleHandler,这两部分内容我放在后面讲,这里先讲主要的出队逻辑。代码中我都加了注释,这里还是再讲一下。next方法目的是获取MessageQueue中的一个Message,如果队列中没有消息的话,就会把方法阻塞住,等待新的消息来唤醒。主要步骤如下:
如果Looper已经退出了,直接返回null
进入死循环,直到获取到Message或者退出
循环中先判断是否需要进行阻塞,阻塞结束后,对MessageQueue进行加锁,获取Message
如果MessageQueue中没有消息,则直接把线程无限阻塞等待唤醒;
如果MessageQueue中有消息,则判断是否需要等待,否则则直接返回对应的message。
可以看到逻辑就是判断当前时间Message中是否需要等待。其中nextPollTimeoutMillis表示阻塞的时间,-1表示无限时间,只有通过唤醒才能打破阻塞。
入队 -- enqueueMessage()
MessageQueue.class
boolean enqueueMessage(Message msg, long when)
// Hanlder不允许为空
if (msg.target == null)
throw new IllegalArgumentException("Message must have a target.");
if (msg.isInUse())
throw new IllegalStateException(msg + " This message is already in use.");
// 对MessageQueue进行加锁
synchronized (this)
// 判断目标thread是否已经死亡
if (mQuitting)
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w(TAG, e.getMessage(), e);
msg.recycle();
return false;
// 标记Message正在被执行,以及需要被执行的时间,这里的when是距离1970.1.1的时间
msg.markInUse();
msg.when = when;
// p是MessageQueue的链表头
Message p = mMessages;
boolean needWake;
// 判断是否需要唤醒MessageQueue
// 如果有新的队头,同时MessageQueue处于阻塞状态则需要唤醒队列
if (p == null || when == 0 || when < p.when)
msg.next = p;
mMessages = msg;
needWake = mBlocked;
else
...
// 根据时间找到插入的位置
Message prev;
for (;;)
prev = p;
p = p.next;
if (p == null || when < p.when)
break;
...
msg.next = p;
prev.next = msg;
// 如果需要则唤醒队列
if (needWake)
nativeWake(mPtr);
return true;
这部分的代码好像也很多,但是逻辑也是不复杂,主要就是链表操作以及判断是否需要唤醒MessageQueue,代码中我加了一些注释,下面再总结一下:
首先判断message的目标handler不能为空且不能正在使用中
对MessageQueue进行加锁
判断目标线程是否已经死亡,死亡则直接返回false
初始化Message的执行时间以及标记正在执行中
然后根据Message的执行时间,找到在链表中的插入位置进行插入
同时判断是否需要唤醒MessageQueue。有两种情况需要唤醒:当新插入的Message在链表头时,如果messageQueue是空的或者正在等待下个任务的延迟时间执行,这个时候就需要唤醒MessageQueue。
MessageQueue总结
Message两大重点:阻塞休眠和队列操作。基本都是围绕着两点来展开。而源码中还涉及到了同步屏障以及IdleHandler,这两部分内容我分开到了最后一部分的相关问题中讲。平时用的比较少,但也是比较重要的内容。
四、Looper
概述
Looper可以说是Handler机制中的一个非常重要的核心。Looper相当于线程消息机制的引擎,驱动整个消息机制运行。Looper负责从队列中取出消息,然后交给对应的Handler去处理。如果队列中没有消息,则MessageQueue的next方法会阻塞线程,等待新的消息的到来。每个线程有且只能有一个“引擎”,也就是Looper,如果没有Looper,那么消息机制就运行不起来,而如果有多个Looper,则会违背单线操作的概念,造成并发操作。
每个线程仅有一个Looper,由不同Looper分发的Message运行在不同的线程中。Looper的内部维护一个MessageQueue,当初始化Looper的时候会顺带初始化MessageQueue。
Looper使用ThreadLocal来保证每个线程都有且只有一个相同的副本。
关键方法
prepare : 初始化Looper
Looper.class
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
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));
每个线程使用Handler之前,都必须调用Looper.prepare()方法来初始化当前线程的Looper。参数quitAllowed表示该Looper是否可以退出。主线程的Looper是不能退出的,不然程序就直接终止了。我们在主线程使用Handler的时候是不用初始化Looper的,为什么?因为Activiy在启动的时候就已经帮我们初始化主线程Looper了,这点在后面再详细展开。所以在主线程我们可以直接调用Looper.myLooper()获取当前线程的Looper。
prepare方法重点在sThreadLocal.set(new Looper(quitAllowed));,可以看出来这里使用了ThreadLocal来创建当前线程的Looper对象副本。如果当前线程已经有Looper了,则会抛出异常。sThreadLocal是Looper类的静态变量,前面我们介绍过了ThreadLocal了,这里每个线程调用一次prepare方法就可以初始化当前线程的Looper了。
接下来再看到Looper的构造方法:
private Looper(boolean quitAllowed)
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
逻辑很简单,初始化了一个MessageQueue,再把当前的线程的Thread对象赋值给mThread。
myLooper() : 获取当前线程的Looper对象
获取当前线程的Looper对象。这个方法就是直接调用ThreadLocal的get方法:
public static @Nullable Looper myLooper()
return sThreadLocal.get();
loop() : 循环获取消息
当Looper初始化完成之后,他是不会自己启动的,需要我们自己去启动Looper,调用Looper的loop()方法即可:
public static void loop()
// 获取当前线程的Looper
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;
...
for (;;)
// 获取消息队列中的消息
Message msg = queue.next(); // might block
if (msg == null)
// 返回null说明MessageQueue退出了
return;
...
try
// 调用Message对应的Handler处理消息
msg.target.dispatchMessage(msg);
if (observer != null)
observer.messageDispatched(token, msg);
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
...
// 回收Message
msg.recycleUnchecked();
loop()方法就是Looper这个“引擎”的核心所在。首先获取当前线程的Looper对象,没有则抛出异常。然后进入一个死循环:不断调用MessageQueue的next方法来获取消息,然后调用message的目标handler的dispatchMessage方法来处理Message。
前面我们了解过了MessageQueue,next方法是可能会进行阻塞的:当MessageQueue为空或者目前没有任何消息需要处理。所以Looper就会一直等待,阻塞在里,线程也就不会结束。当我们退出Looper的时候,next方法会返回null,那么Looper也就会跟着结束了。
同时,因为Looper是运行在不同线程的逻辑,其调用的dispatchMessage方法也是运行在不同的线程,这就达到了切换线程的目的。
quit/quitSafely : 退出Looper
quit是直接将Looper退出,quitSafely是将MessageQueue中的不需要等待的消息处理完成之后再退出,看一下代码:
public void quit()
mQueue.quit(false);
// 最终都是调用到了这个方法
void quit(boolean safe)
// 如果不能退出则抛出异常。这个值在初始化Looper的时候被赋值
if (!mQuitAllowed)
throw new IllegalStateException("Main thread not allowed to quit.");
synchronized (this)
// 退出一次之后就无法再次运行了
if (mQuitting)
return;
mQuitting = true;
// 执行不同的方法
if (safe)
removeAllFutureMessagesLocked();
else
removeAllMessagesLocked();
// 唤醒MessageQueue
nativeWake(mPtr);
我们可以发现最后都调用了quitSafely方法。这个方法先判断是否能退出,然后再执行退出逻辑。如果mQuitting==true,那么这里会直接方法,我们会发现mQuitting这个变量只有在这里被执行了赋值,所以一旦looper退出,则无法再次运行了。之后执行不同的退出逻辑,我们分别看一下:
private void removeAllMessagesLocked()
Message p = mMessages;
while (p != null)
Message n = p.next;
p.recycleUnchecked();
p = n;
mMessages = null;
这个方法很简单,直接把当前所有的Message全部移除。再看一下另一个方法:
private void removeAllFutureMessagesLocked()
final long now = SystemClock.uptimeMillis();
Message p = mMessages;
if (p != null)
// 如果都在等待,则全部移除,直接退出
if (p.when > now)
removeAllMessagesLocked();
else
Message n;
// 把需要等待的Message全部移除
for (;;)
n = p.next;
if (n == null)
return;
if (n.when > now)
break;
p = n;
p.next = null;
do
p = n;
n = p.next;
p.recycleUnchecked();
while (n != null);
这个方法逻辑也不复杂,就是把需要等待的Message全部移除,当前需要执行的Message则保留。最终在MessageQueue的next方法中,会进行判断后返回null,表示退出,Looper收到这个返回值之后也跟着退出了。
Looper总结
Looper作为Handler消息机制的“动力引擎”,不断从MessageQueue中获取消息,然后交给Handler去处理。Looper的使用前需要先初始化当前线程的Looper对象,再调用loop方法来启动它。
同时Handler也是实现切换的核心,因为不同的Looper运行在不同的线程,他所调用的dispatchMessage方法则运行在不同的线程,所以Message的处理就被切换到Looper所在的线程了。当looper不再使用时,可调用不同的退出方法来退出他,注意Looper一旦退出,线程则会直接结束。
五、Handler
概述
我们整个消息机制称为Handler机制就可以知道Handler我们的使用频率之高,一般情况下我们的使用也是围绕着Handler来展开。Handler是作为整个消息机制的消息发起者与处理者,消息在不同的线程通过Handler发送到目标线程的MessageQueue中,然后目标线程的Looper再调用Handler的dispatchMessage方法来处理消息。
创建Handler
一般情况下我们使用Handler有两种方式: 继承Handler并重写handleMessage方法,直接创建Handler对象并传入callBack,这在前面使用Handler部分讲过就不再赘述。
需要注意的一点是:创建Handler必须显示指明Looper参数,而不能直接使用无参构造函数,如:
Handler handler = new Handler(); //1
Handler handler = new Handler(Looper.myLooper())//2
1是错的,2是对的。避免在Handler创建过程中Looper已经退出的情况。
发送消息
Handler发送消息有两种系列方法 : postxx 和 sendxx。如下:
public final boolean post(@NonNull Runnable r);
public final boolean postDelayed(@NonNull Runnable r, long delayMillis);
public final boolean postAtTime(@NonNull Runnable r, long uptimeMillis);
public final boolean postAtFrontOfQueue(@NonNull Runnable r);
public final boolean sendMessage(@NonNull Message msg);
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis);
public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis);
public final boolean sendMessageAtFrontOfQueue(@NonNull Message msg)
这里我只列出了比较常用的两类方法。除了插在队列头的两个方法,其他方法最终都调用到了sendMessageAtTime。我们从post方法跟源码分析一下:
public final boolean post(@NonNull Runnable r)
return sendMessageDelayed(getPostMessage(r), 0);
post方法把runnable对象封装成一个Message,再调用sendMessageDelayed方法,我们看看他是如何封装的:
private static Message getPostMessage(Runnable r)
Message m = Message.obtain();
m.callback = r;
return m;
可以看到逻辑很简单,把runnable对象直接赋值给callBack属性。接下来回去继续看
sendMessageDelayed:
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis)
if (delayMillis < 0)
delayMillis = 0;
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
public boolean sendMessageAtTime(@NonNull 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);
sendMessageDelayed把小于0的延迟时间改成0,然后调用sendMessageAtTime。这个方法主要是判断MessageQueue是否已经初始化了,然后再调用enqueueMessage方法进行入队操作:
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
long uptimeMillis)
// 这里把target设置成自己
msg.target = this;
msg.workSourceUid = ThreadLocalWorkSource.getUid();
// 异步handler设置标志位true,后面会讲到同步屏障
if (mAsynchronous)
msg.setAsynchronous(true);
// 最后调用MessageQueue的方法入队
return queue.enqueueMessage(msg, uptimeMillis);
可以看到Handler的入队操作也是很简单,把Message的target设置成本身,这样这个Message最后就是由自己来处理。最后调用MessageQueue的入队方法来入队,这在前面讲过就不再赘述。
其他的发送消息方法都是大同小异,读者感兴趣可以自己去跟踪一下源码。
处理消息
上面讲Looper处理消息的时候,最后就是调用handler的dispatchMessage方法来处理。我们来看一下这个方法:
public void dispatchMessage(@NonNull Message msg)
if (msg.callback != null)
handleCallback(msg);
else
if (mCallback != null)
if (mCallback.handleMessage(msg))
return;
handleMessage(msg);
private static void handleCallback(Message message)
message.callback.run();
他的逻辑也不复杂。首先判断Message是否有callBack,有的话就直接执行callBack的逻辑,这个callBack就是我们调用handler的post系列方法传进去的Runnable对象。否则判断Handler是否有callBack,有的话执行他的方法,如果返回true则结束,如果返回false则直接Handler本身的handleMessage方法。这个过程可以用下面的图表示一下:
dispatchMessage逻辑
内存泄露问题
当我们使用继承Handler方法来使用Handler的时候,要注意使用静态内部类,而不要用非静态内部类。因为非静态内部类会持有外部类的引用,而从上面的分析我们知道Message在被入队之后他的target属性是指向了Handler,如果这个Message是一个延迟的消息,那么这一条引用链的对象就迟迟无法被释放,造成内存泄露。
一般这种泄露现象在于:我们在Activity中发送了一个延迟消息,然后退出了activity,但是由于无法释放,这样activity就无法被回收,造成内存泄露。
Handler总结
Handler作为消息的处理和发送者,是整个消息机制的起点和终点,也是我们接触最多的一个类,因为我们称此消息机制为Handler机制。Handler最重要的就是发送和处理消息,只要熟练掌握这两方面的内容就可以了。同时注意内存泄露问题,不要使用非静态内部类去继承Handler。
六、HandlerThread
概述
有时候我们需要开辟一个线程来执行一些耗时的任务。一般情况下可以通过新建一个Thread,然后再在他的run方法里初始化该线程的Looper,这样就可以用他的Looper来切线程处理消息了。如下(这里是kotlin代码,和java差不多相信可以看得懂的):
val thread = object : Thread()
lateinit var mHandler: Handler
override fun run()
super.run()
Looper.prepare()
mHandler = Handler(Looper.myLooper()!!)
Looper.loop()
thread.start()
Thread()
Thread.sleep(10000)
thread.mHandler.sendMessage(Message.obtain())
.start()
执行一下,诶,没有报错了果然可以。但是!!! ,这样的代码显得特别的难堪和臃肿,还要再开启一个线程来延迟处理。那有没有更好的解决方案?有,HandlerThread。
HandlerThread本身是一个Thread,他继承自Thread,他的代码并不复杂,看一下(代码还是有点多,可以选择看或者不看,我下面会讲重点方法):
public class HandlerThread extends Thread
// 依次是:线程优先级、线程id、线程looper、以及内部handler
int mPriority;
int mTid = -1;
Looper mLooper;
private @Nullable Handler mHandler;
// 两个构造器。name是线程名字,priority是线程优先级
public HandlerThread(String name)
super(name);
mPriority = Process.THREAD_PRIORITY_DEFAULT;
public HandlerThread(String name, int priority)
super(name);
mPriority = priority;
// 在Looper开始运行前的方法
protected void onLooperPrepared()
// 初始化Looper
@Override
public void run()
mTid = Process.myTid();
Looper.prepare();
synchronized (this)
mLooper = Looper.myLooper();
// 通知初始化完成
notifyAll();
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
// 获取当前线程的Looper
public Looper getLooper()
if (!isAlive())
return null;
// 如果尚未初始化则会一直阻塞知道初始化完成
synchronized (this)
while (isAlive() && mLooper == null)
try
// 利用Object对象的wait方法
wait();
catch (InterruptedException e)
return mLooper;
// 获取handler,该方法被标记为hide,用户无法获取
@NonNull
public Handler getThreadHandler()
if (mHandler == null)
mHandler = new Handler(getLooper());
return mHandler;
// 两种不同类型的退出,前面讲过不再赘述
public boolean quit()
Looper looper = getLooper();
if (looper != null)
looper.quit();
return true;
return false;
public boolean quitSafely()
Looper looper = getLooper();
if (looper != null)
looper.quitSafely();
return true;
return false;
// 获取线程id
public int getThreadId()
return mTid;
整个类的代码不是很多,重点在run()和getLooper()方法。首先看到getLooper方法:
public Looper getLooper()
if (!isAlive())
return null;
// 如果尚未初始化则会一直阻塞知道初始化完成
synchronized (this)
while (isAlive() && mLooper == null)
try
// 利用Object对象的wait方法
wait();
catch (InterruptedException e)
return mLooper;
和我们前面自己写的不同,他有一个wait(),这个是Java中Object类提供的一个方法,类似于我们前面讲的MessageQueue阻塞。等到Looper初始化完成之后就会唤醒他,就可以顺利返回了,不会造成Looper尚未初始化完成的情况。然后再看到run方法:
// 初始化Looper
@Override
public void run()
mTid = Process.myTid();
Looper.prepare();
synchronized (this)
mLooper = Looper.myLooper();
// 通知初始化完成
notifyAll();
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
常规的Looper初始化,完成之后调用了notifyAll()方法进行唤醒,对应了上面的getLooper方法。
HandlerThread的使用
HandlerThread的使用范围很有限,开个子线程不断接受消息处理耗时任务。所以他的使用方法也是比较固定:
HandlerThread ht = new HandlerThread("handler");
Handler handler = new Hander(ht.getLooper());
handler.sendMessage(msg);
获取到他的Looper,外部自定义Handler来使用即可。
七、总结
Handler,MessageQueue,Looper三者共同构成了android消息机制,各司其职。其中Handler主要负责发送和处理消息,MessageQueue主要负责消息的排序以及在没有需要处理的消息的时候阻塞代码,Looper负责从MessageQueue中取出消息给Handler处理,同时达到切换线程的目的。
以上是关于Handler消息机制关键类详解的主要内容,如果未能解决你的问题,请参考以下文章
深入源码分析Handler 消息机制 LooperMessageQueue 消息同步屏障IdleHandlerMessage 复用