一文搞定面试 | Handler源码解析
代码里部分含有中文注释，也建议认真看一下。当然源码的英文注释也非常有帮助
本文适合对Handler的使用基本了解，想要深入探索其运行机制和源码原理的人群，初学者建议先阅读学习 Android中Handler的基本使用
鉴于内容较多，后续扩展较广，建议根据需要，分批分段阅读，或时常复读，常读常新。愿对加深你的理解有帮助
Handler
先看Handler主要的构造方法和成员变量：Looper、MessageQueue是比较关键的
这里得到对于一个Looper对象，可以实例化n个Handler与之绑定。刚开始这里可能还比较懵，先看后面，这里留个疑问吧：为什么Handler需要与Looper绑定
final Looper mLooper;
final MessageQueue mQueue;
final Callback mCallback;
// 这个还是比较眼熟的吧，就是实例化Handler通常会传入的，或者会直接重写自身的handleMessage方法
public interface Callback {
/**
* @param msg A {@link android.os.Message Message} object
* @return True if no further handling is desired
*/
boolean handleMessage(@NonNull Message msg);
}
// 这两个可以先不看，建议整体知识能够串联起来后再自主回顾一遍
final boolean mAsynchronous;
IMessenger mMessenger;
// 推荐的Handler的获取方式需要传入Looper对象，关于Looper的获取请看对应段落
public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
mLooper = looper;
// 其中MessageQueue来自于Looper
mQueue = looper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
Handler通常如何使用
通常使用handler，会实例化一个 Meaasge对象，然后通过 sendMessage 方法发射出去，在重写的 handleMessage 方法或传入的Callback接口实现中处理回调内容，关于回调如何使用，这里就不再阐述了。
// 当然对它自带的分发机制不满意的话，也可以override
public void dispatchMessage(@NonNull Message msg) {
// 这里发现Message也有callback，并且是个Runnable，是个互斥逻辑
// 这里的callback是调用Handler的post方法时，绑定在Message对象上的
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
// 包括这里，Callback的实现的返回值如果为true，有点onTouchEvent消费事件的意味，将会拦截重写的Handler的handleMessage方法
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
在时序图中可以看出大致的调用链，最终会调用 enqueueMessage
结合代码我们发现，不管是post、Delayed、AtTime等变体方法，最终实际是将时间计算为发生时间uptimeMillis，结合方法名应该是放入了MessageQueue的消息队列中。
Handler的自身先告一段落，后面跟着Looper和MessageQueue的解析再继续品吧
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
long uptimeMillis) {
// 这里非常关键！！！
// 这里对Message对象绑定了target，this也就是Handler自身，这也是为什么后面能收到回调的原因，相当于常用的观察者模式的接口持有
msg.target = this;
msg.workSourceUid = ThreadLocalWorkSource.getUid();
if (mAsynchronous) {
// 这里设置了是否为异步模式，这里需要结合同步屏障一起食用，可以先不看
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
MessageQueue
首先顾名思义，是个维护Message的队列，通过持有头节点掌握队列。内部通过next指针形成链，同时在新节点插入时，会遵循when的时间优先
Message mMessages;
public final class Message implements Parcelable {
// 通常用于区分消息，即类似于通信code
public int what;
// enqueueMessage的时候传入的uptimeMillis
public long when;
// 存储数据的地方
Bundle data;
// handler绑定持有
Handler target;
// handler.post会把执行的action存在这，最终在dispatch的时候调用
Runnable callback;
Message next;
}
MessageQueue的入队
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
// target为空，就会抛异常，所以前面Handler的enqueueMessage中绑定target非常重要
throw new IllegalArgumentException("Message must have a target.");
}
synchronized (this) {
if (msg.isInUse()) {
// 这里可以留个心眼，关注下Message的状态什么时候会变化
throw new IllegalStateException(msg + " This message is already in use.");
}
if (mQuitting) {
// 调用了quit方法后，mQuitting才为true
// Looper持有了MessageQueue，可以调用该方法，提供了安全和不安全两种方式
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的状态，其中的标志位是二进制位运算进行维护的
msg.markInUse();
// 之前计算出来的uptimeMillis被存在了Message对象的when属性中
msg.when = when;
// p就是一个header节点，Message内部通过next指针形成链表
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// 这里就对头节点重新赋值，如果为空或 比当前头节点执行要早
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
// 当MessageQueue为空且没有idleHandler要处理，mBlocked为true
needWake = mBlocked;
} else {
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
// 这段挺重要的，needWake为true需要满足以下几个条件
// 阻塞标志位mBlocked为true，后面会分析
// 头结点target为空,所以想要突破同步屏障，需要避免几个设置target的方法，或者手动置空
// mAsynchronous需要为true
// 暂时先了解这些
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
for (;;) {
// 循环遍历，prev会到适合插入的节点
prev = p;
p = p.next;
if (p == null || when < p.when) {
// 这里还有时间的比较，所以是时间优先队列
break;
}
if (needWake && p.isAsynchronous()) {
// needWake会在这里被消费掉，取决于p是否是异步消息
// 因为之前唤醒过了，就不需要再唤醒了
needWake = false;
}
}
// 最终插到队列尾部
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
// 然后有个唤醒操作，结合上面的逻辑整理如下
// 如果现在是同步屏障模式下，且插入的是异步消息，因为异步消息需要先执行，所以唤醒线程
nativeWake(mPtr);
}
}
return true;
}
MessageQueue取消息
这里还有个比较重要的方法 next() ，因为已知MessageQueue是一个维护Message的队列，那队列需要出队的地方，就在这里
Message next() {
// Return here if the message loop has already quit and been disposed.
// This can happen if the application tries to restart a looper after quit
// which is not supported.
final long ptr = mPtr;
if (ptr == 0) {
// 当队列遍历时发现mQuitting，即被调用了quit后，ptr即为0
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
// 一个死循环，意味着一定会返回一条消息，否则则会阻塞，直到新消息到来
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
// 进行阻塞休眠，与enqueueMessage中的nativeWake唤醒对应
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// 这里就描述了同步屏障，所以需要记住同步屏障的条件就是target为空
// 如果需要了同步屏障，就会遍历去找到下一个异步消息，因为同步的会被阻塞
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// 这里就是消息队列在消费时，发现还未到触发时机时，那就会阻塞消息队列
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
// 有消息获取，那就不阻塞
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
// 拿出来用的时候，需要变更状态
msg.markInUse();
return msg;
}
} else {
// No more messages.
// 如果队列为空，就一直阻塞着
nextPollTimeoutMillis = -1;
}
// 如果前面找到了合适的Message，就直接return了，这里就走不进来，所以现在的状态是IDLE的闲置挂起，或者进行了安全退出或退出时，后续没有消息了
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
// 这里就是提到过的中断机制
dispose();
return null;
}
// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// 有IdleHandler就执行，没有那就阻塞标志位mBlocked启用
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
// mPendingIdleHandlers初始化懒加载
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
// mIdleHandlers copy一份到mPendingIdleHandlers，因为mPendingIdleHandlers中取出即会置空
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// Run the idle handlers.
// We only ever reach this code block during the first iteration.
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
// 取出后，即释放了引用
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
// 调用IdleHandler接口的queueIdle，并根据其返回值决定是否remove掉
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
// mPendingIdleHandlers只是一个临时队列，而mIdleHandlers才用来长久维持，需要keep的则不会被remove，下次还会被copy过来
mIdleHandlers.remove(idler);
}
}
}
// Reset the idle handler count to 0 so we do not run them again.
pendingIdleHandlerCount = 0;
// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
}
}
Looper
Looper是如何来的？
Looper在构造中会绑定当前线程，并且会实例化一个MessageQueue 所以MessageQueue和Looper是1:1关系
final MessageQueue mQueue;
final Thread mThread;
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
构造是私有的，该如何调用呢？
只有 prepare 方法提供了构造的调用，也就是说想要获取Looper，先得调用Looper.prepare 实例化后存入ThreadLocal且不能多次调用，否则会抛异常
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));
}
public static void prepareMainLooper() {
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}
这里附了ThreadLocal的set方法，帮助大家理解。 ThreadLocal可以实例化多个，但最终都会归到 所属Thread的ThreadLocalMap对象，即每个线程都有的一个本地备份，且相互之间不干扰
所以得到，对应关系和层级持有关系如先后顺序所示
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
为什么Handler实例化的时候，不传Looper也可以？
虽然这个方法已经被弃用了，但还可以正常使用
发现代码段中有空判断和异常抛出，那为什么在主线程这么实例化Handler没有问题呢，来接着看看 myLooper 方法
public Handler(@Nullable Callback callback, boolean async) {
// ……省略一部分
mLooper = Looper.myLooper();
if (mLooper == null) {
// 如果Looper.myLooper()为空的话，那就会抛异常
throw new RuntimeException(
"Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
// 这边就都一样了
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
前面介绍过了ThreadLocal，既然主线程不会崩溃，也就意味着主线程有地方帮我们调用了prepare 方法进行了Looper的实例化
大家可以尝试new Thread.start后在里面通过上面的这种构造实例化一下Handler看看会不会崩，然后再尝试自己避免它的崩溃
public static @Nullable Looper myLooper() {
// 因为prepare()不允许多次调用，所以在实例化前可以通过该方法进行检查，为空才实例化
return sThreadLocal.get();
}
有心人应该发现了，前面的代码段中有一个方法 prepareMainLooper ，就是猜测和主线程有关，所以全局搜索一下，发现在 ActivityThread类中有调用
// 帮大家处理了一下，只留了需要重点关注的部分
// main方法是一个Activity应用运行的主入口
public static void main(String[] args) {
// ……省略一部分方法
// 1.实例化Looper，所以是源码中帮我们调用了，为什么呢，因为它需要用呀
Looper.prepareMainLooper();
// ……省略一部分方法
if (false) {
// 2.这里日志标签和 一种卡顿监控有关联，可以留个心眼
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
// 3.新方法loop!!!
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
loop()是干什么的？
主要就一个检查和一个死循环调用 loopOnce
// 又是一个静态方法呢
public static void loop() {
final Looper me = myLooper();
if (me == null) {
// 所以在调用loop()前，一定需要确保prepare过了
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
// ……省略一部分代码
for (;;) {
// 又是一个死循环，这里通常会引申一个问题，主线程死循环不会卡死吗
// ActivityThread.main最后就这一个入口了，如果这里结束了，应用也就结束了
// 关于休眠机制，后面再讲
if (!loopOnce(me, ident, thresholdOverride)) {
return;
}
}
}
loopOnce里主要就两步，取出消息并分发
到这，基本的handler内容就结束了
private static boolean loopOnce(final Looper me,
final long ident, final int thresholdOverride) {
// 1.取消息
Message msg = me.mQueue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return false;
}
// ……省略一部分代码
try {
// 2.分发消息，这里的target调用的分发，也就是之前最先enqueueMessage里绑定的handler
msg.target.dispatchMessage(msg);
if (observer != null) {
observer.messageDispatched(token, msg);
}
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
}
// ……省略一部分代码
// 3.recycleUnchecked将分发完的Message进行回收复用
// sPool的最大长度为50，空消息被释放后会被放在表头，obtain复用时会直接取用头节点
msg.recycleUnchecked();
return true;
}
进阶，看看以下问题
以下问题均来源于此博客，经一定的整理调整，大家也可以直接看这个博客。也有一部分问题认为您认真地看过了上面的内容，已经融汇贯通了，所以就没有写答案
1. 子线程访问UI的 崩溃原因 和 解决办法？为什么建议子线程不访问（更新）UI？
更准确地说，
“创建UI的线程才能更新UI”，ViewRootImpl的checkThread进行了线程检查，也就是常见的子线程访问UI引发的崩溃，当然也是有控件不在主线程创建的，感兴趣的话可以自行了解。既然知道了原因，那就可以根据场景去合理避免，比如通过handler的通信机制\协程等手段切换到主线程进行UI操作
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
Android中UI控件是线程不安全的，加锁会降低UI访问的效率，造成卡顿，同时也会使UI更新整体复杂化，所以综合考虑，有了
单线程模型机制
2. MessageQueue是干嘛呢？用的什么数据结构来存储数据？延迟消息是怎么实现的？MessageQueue的消息怎么被取出来的？MessageQueue没有消息时候会怎样？阻塞之后怎么唤醒呢？
不提供答案，enqueueMessage(同步消息、异步消息入队)时进行唤醒
nativeWake，当next()队列中没有消息或下一个消息还未到时间执行时休眠nativePollOnce
3. 说说pipe/epoll机制？
epoll机制是一种IO多路复用的机制，具体逻辑就是一个进程可以监视多个描述符，当某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作，这个读写操作是阻塞的。在Android中，会创建一个Linux管道（Pipe）来处理阻塞和唤醒。 浅谈Android之Linux pipe/epoll 虽然看完也还有点懵hhh，就先这样吧
4. 同步屏障和异步消息是怎么实现的？同步屏障和异步消息有具体的使用场景吗？
区别于异步消息的是同步消息，也就是普通消息，而异步消息通过Message对象调用setAsynchronous。如果handler设置为异步，所有消息都会设置setAsynchronous。正常情况下，异步消息和普通消息一样，会根据when时间戳排队按序分发。当遇到
同步屏障时，会唤醒线程，并且跨过期间的同步消息
同步屏障是一种机制，特点是target为空，可以通过MessageQueue的postSyncBarrier（需要反射才能调用）方法（成功会有一个返回值code，在remove时需要用到。同时它不会真正意义上入队不走enqueueMessage，而是被直接放在了队列的适当位置，所以它不会引发线程唤醒）发送。同步屏障不属于一种消息，属于一种阻塞机制，意味着要
优先处理异步消息
ViewRootImpl.scheduleTraversals方法中，利用同步屏障和异步消息的组合使用，用于垂直同步信号脉冲的监听，并且ASYNC信号到来之后，保证UI绘制优先执行（避免期间有太多消息，导致绘制延后而导致卡顿），再移除同步屏障
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
// 发送同步屏障
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
// 这里可以跟进去看一下，发送了一个异步消息
// 这里设置了一个callback：mTraversalRunnable
// 里面调用了doTraversal移除了同步屏障，并开始performTraversals
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
// postCallback -> postCallbackDelayed -> postCallbackDelayedInternal
private void postCallbackDelayedInternal(int callbackType, Object action, Object token, long delayMillis) {
// ……省略一部分代码，这个消息最终在Choreographer中处理
// FrameDisplayEventReceiver
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
msg.arg1 = callbackType;
// 设置异步消息
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);
}
当然有好处，也有代价。对于VSYNC信号的机制，同步消息最多可能被延迟一帧，同时会造成同步消息的堆积，集中处理时会有压力。所以同步消息的执行时间是不一定准确的！！！
那使用异步消息需要注意点什么呢：
1.轻量级操作，否则无论如何都会使得主线程压力变大
2.不需要和绘制顺序同步的，那就可以使用，否则还是使用同步handler
5. Message是怎么找到它所属的Handler然后进行分发的？Message消息被分发之后会怎么处理？消息怎么复用的？
不提供答案
6. Looper是干嘛呢？怎么获取当前线程的Looper？可以多次创建Looper吗？为什么主线程不需要单独创建Looper？（ActivityThread中做了哪些关于Handler的工作）
不提供答案
7. ThreadLocal运行机制？这种机制设计的好处？还有哪些地方运用到了ThreadLocal机制？为什么不直接用Map存储线程和对象呢？
一个Thread持有一个ThreadLocalMap，其中用Entry数组维护key（ThreadLocal对象）-value（存的泛型），类似于hashMap，会通过ThreadLocal.threadLocalHashCode和位运算得到index
static class ThreadLocalMap {
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
private Entry[] table;
}
这种机制保证了线程间的数据隔离，而用Map存储就会造成线程间共享变量的混乱污染。所以适用于线程间不共享变量的线程对象维护。需要使用时需要注意内存泄露，及时进行remove，因为key是弱引用
Choreographer中也使用了static ThreadLocal完成了主线程单例，因为key是以ThreadLocal对象的，所以static可以使得一个线程内所有操作共享
8. Looper中的quitAllowed字段是啥？有什么用？
顾名思义，是否允许退出的标记（Looper.prepare->构造中传入），主线程在创建时传入的是false(即不允许退出)，最终给到MessageQueue，会在调用其quit时起作用
// 这里还有个safe标记
void quit(boolean safe) {
if (!mQuitAllowed) {
throw new IllegalStateException("Main thread not allowed to quit.");
}
synchronized (this) {
if (mQuitting) {
return;
}
// 新的消息就不会再进来了
mQuitting = true;
if (safe) {
// 安全退出，now时钟之前的消息需要处理，但之后的消息都recycler回收了
// 这也是为什么在MessageQueue.next()中，对mQuitting放这么后面
removeAllFutureMessagesLocked();
} else {
// 不安全，则直接全部清空回收
removeAllMessagesLocked();
}
// We can assume mPtr != 0 because mQuitting was previously false.
nativeWake(mPtr);
}
}
那什么时候才会调用quit()?
APP需要退出，则主线程调用
子线程处理完毕，则调用释放资源
9. Looper.loop方法是死循环，为什么不会卡死（ANR）？
当没有消息的时候，会阻塞在loop的
queue.next()中的nativePollOnce()方法里，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生。所以死循环也不会特别消耗CPU资源。而且主线程就是需要一直执行，处理各种消息（各种Message，比如Activity的生命周期等）。而导致ANR的是消息的处理耗时
10. Handler 的 post(Runnable) 与 sendMessage 有什么区别？Handler.Callback.handleMessage 和 Handler.handleMessage 有什么不一样？为什么这么设计？
不提供答案
11. Handler、Looper、MessageQueue、线程是一一对应关系吗？
不提供答案
12. IdleHandler是啥？有什么使用场景？
回顾一下next中，当MessageQueue中没有消息，在阻塞之前，还会去处理IdleHandler和mBlocked阻塞标志位。可以通过MessageQueue的
addIdleHandler进行添加
Looper.myLooper()?.queue?.addIdleHandler {
// do something
// 返回true代表keep，false即处理完就remove
false
}
性质：在不影响其他任务，在MessageQueue空闲状态下执行
应用：Android Framework层的GC场景就使用了这个机制，只有当cpu空闲的时候才会去GC
final class GcIdler implements MessageQueue.IdleHandler {
@Override
public final boolean queueIdle() {
doGcIfNeeded();
purgePendingResources();
return false;
}
}
切记~！如像
View.onDraw中无限制调用invalidate，不断添加同步屏障，在等到异步消息之前会一直阻塞在next()中，而这里的下一个异步任务又是绘制相关的，执行onDraw而无限循环，从而无法执行IdleHandler
13. HandlerThread是啥？有什么使用场景？
HandlerThread就是为了便于在子线程中使用Handler而封装调用了Looper.parpare()&loop()的模板Thread，其中的notify\wait挺有趣的，可以看一下
@Override
public void run() {
mTid = Process.myTid();
Looper.prepare();
synchronized (this) {
// 与getLooper中的同步锁对应，进行唤醒
mLooper = Looper.myLooper();
notifyAll();
}
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
}
/**
* This method returns the Looper associated with this thread. If this thread not been started
* or for any reason isAlive() returns false, this method will return null. If this thread
* has been started, this method will block until the looper has been initialized.
* @return The looper.
*/
public Looper getLooper() {
if (!isAlive()) {
// 这时说明Thread还没start，当然也没创建Looper
return null;
}
// If the thread has been started, wait until the looper has been created.
synchronized (this) {
while (isAlive() && mLooper == null) {
try {
// 这里结合同步锁，等待Looper创建完毕
wait();
} catch (InterruptedException e) {
}
}
}
return mLooper;
}
14. IntentService是啥？有什么使用场景？
是一个内部维护了HandlerThread的Service，Service启动后，会发送Message回调
onHandleIntent()，执行完毕后通过stopSelf进行关闭Service，同时onDestory时也及时对Looper进行quit，进行了合理回收。建议结合16题的内存泄露来看，这是避免该问题的良好实践
public abstract class IntentService extends Service {
private final class ServiceHandler extends Handler {
public ServiceHandler(Looper looper) {
super(looper);
}
@Override
public void handleMessage(Message msg) {
onHandleIntent((Intent)msg.obj);
stopSelf(msg.arg1);
}
}
@Override
public void onCreate() {
super.onCreate();
HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
thread.start();
mServiceLooper = thread.getLooper();
mServiceHandler = new ServiceHandler(mServiceLooper);
}
@Override
public void onStart(@Nullable Intent intent, int startId) {
Message msg = mServiceHandler.obtainMessage();
msg.arg1 = startId;
msg.obj = intent;
mServiceHandler.sendMessage(msg);
}
public void onDestroy() {
mServiceLooper.quit();
}
15. BlockCanary使用过吗？说说原理
BlockCanary是一个用来检测应用卡顿耗时的三方库。其原理主要对Looper设置了MessageLogging，实现对主线程消息耗时的监听
public static void loop() {
for (;;) {
// This must be in a local variable, in case a UI event sets the logger
Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
msg.target.dispatchMessage(msg);
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
}
}
// 注入自己的Printer
Looper.getMainLooper().setMessageLogging(new Printer() {
private static final String START = ">>>>> Dispatching";
private static final String END = "<<<<< Finished";
@Override
public void println(String x) {
if (x.startsWith(START)) {
// 对指定格式消息进行监听，并且根据自己的卡顿检测需求dump堆栈
startMonitor();
}
if (x.startsWith(END)) {
removeMonitor();
}
}
});
16. 说说Hanlder内存泄露问题。
“内部类持有了外部类引用”，先梳理一下Handler的调用链，即ThreadLocal自身作为弱引用，将要释放时，其value：Looper间接持有Activity，因其可达而无法回收Activity，但key：ThreadLocal已经被回收了，后续value一直没有被主动回收，这本身也是ThreadLocal的内存泄露问题
Thread -> ThreadLocal -> Looper -> MessageQueue -> Message(target持有) -> Handler -> 持有或操作Activity
即当Activity退出时，Handler仍可达（比如在处理耗时操作，或MessageQueue还在排队中持有Handler）
那应该如何处理呢？两步走
1.Handler对外部类，如Activity进行弱引用 2.Activity.onDestory时，切断Message与Handler之间的联系，即强迫执行Message的
recycle()，target置为null
open class WeakReferenceHandler<T>(looper: Looper?, referencedObject: T) : Handler(looper!!) {
private val mReference: WeakReference<T> = WeakReference(referencedObject)
protected val referencedObject: T?
protected get() = mReference.get()
}
// Activity 销毁的时候，如果子线程任务尚未结束，及时中断 Thread：
override fun onDestroy() {
...
// 协程的话，会关联lifecycleScope进行生命周期监听并及时cancel
thread.interrupt()
}
// 如果子线程中创建了 Looper 并成为了 Looper 线程的话，须手动 quit。比如 HandlerThread：
override fun onDestroy() {
...
// 如果用协程进行线程切换的话，也不存在这个问题，因为直接被cancel掉了
handlerThread.quitSafely()
}
// 主线程的 Looper 无法手动 quit（因为设置了quitAllow=false），所以还需手动清空主线程中 Handler 未处理的 Message：
override fun onDestroy() {
...
mainHandler.removeCallbacksAndMessages(null)
}
※1：Message 在执行 `recycle()` 后会清除其与和 Main Handler 的引用关系
※2：Looper 子线程调用 quit 时会清空 Message，所以无需针对子线程的 Handler 再作 Message 的清空处理了
有任何 建议\指正 欢迎
下方评论或联系作者
转载自:https://juejin.cn/post/7220778786126577720