一、消息机制简述
消息机制是Android的核心，宏观来说它是一种顺序的、非阻塞的任务机制，APP的主线程就是以消息来驱动的。消息机制主要由Handler、Looper与MessageQueue实现，每个线程只有一个Looper和MessageQueue，因为Looper是ThreadLocal变量，而MessageQueue又是Looper的成员变量。
消息机制的流程概括起来很简单：用户通过Handler将消息添加到MessageQueue中，而Looper又会不断从MessageQueue中取出消息分发给对应的Handler。由于Handler是与线程绑定的，如果在子线程中，通过绑定了主线程的Handler发送消息，该消息最终会在主线程处理，这就实现了线程切换的功能。
下面从源码开始，剖析消息机制的运行，以及分析如何通过消息机制实现卡顿监控，最后讲怎么预防Handler带来的内存泄漏。
二、消息机制源码分析
2.1 Looper初始化
Looper负责遍历当前线程的MessageQueue并分发Message至对应的Handler，如果没有初始化Looper，Handler无法收到自己发出去的消息。因此在使用某个线程的Looper之前，需要先对其初始化。
主线程Looper的初始化工作是系统做的，在ActivityThread的main方法中，可以看到应用启动时对主线程的Looper进行了初始化。
public static void main(String[] args) {
......
Looper.prepareMainLooper();
......
Looper.loop();
}
关于Looper的调用就是这两个方法，其中Looper.prepareMainLooper()通过prepare(boolean quitAllowed)方法为当前线程设置一个Looper，随后将其赋值给sMainLooper。
public static void prepareMainLooper() {
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}
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));
}
Looper.loop()精简后的代码如下，它的主要功能就是开启一个死循环，不断通过queue.next()取出MessageQueue中的下一条Message，再通过msg.target.dispatchMessage(msg)让该Message对应的Handler去处理该消息。
值得注意的是，在msg.target.dispatchMessage(msg)的前后，logging都会打印日志，我们可以通过该特性来分析每个Message的处理耗时，从而达到卡顿监控的目的。关于卡顿监控这里先不展开，第四节会详细说明。
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;
for (;;) {
// 当消息队列中没有可以处理消息时，会阻塞在这里
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
try {
msg.target.dispatchMessage(msg);
......
} catch (Exception exception) {
......
}
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
msg.recycleUnchecked();
}
}
每个循环最后调用msg.recycleUnchecked()将Message对象添加到缓存池，这主要是为了避免频繁创建和销毁Message对象而带来内存抖动，开发时一般通过Message.obtain()来获取一个Message对象，该方法会先去缓存池中取，没有的话才会新建。
/**
* Return a new Message instance from the global pool. Allows us to
* avoid allocating new objects in many cases.
*/
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();
}
一般情况下我们只会在主线程中使用Looper，而主线程的Looper是系统初始化的，但如果我们需要在子线程中使用Looper该怎么做呢？
官方示例如下，只需要在该子线程中调用Looper.prepare()与Looper.loop()即可。而当该线程不再需要Looper时，需要手动调用Looper.quit()停止Looper.loop()的运行，不然该方法内部的死循环会一直运行，导致该线程一直存在于内存中。
class LooperThread extends Thread {
public Handler mHandler;
@override
public void run() {
Looper.prepare();
mHandler = new Handler() {
public void handleMessage(Message msg) {
// process incoming messages here
}
};
Looper.loop();
}
}
2.2 发送Message
消息的发送与获取都与MessageQueue相关，当通过Handler发送消息时，会根据Message的when属性(该属性代表Message应该在什么时候被执行)将其存储到MessageQueue的对应位置，Handler中发送消息相关的API如下所示，可以发现最终都会调用enqueueMessage(queue, msg, uptimeMillis)方法。
public final boolean sendEmptyMessage(int what) {
return sendEmptyMessageDelayed(what, 0);
}
public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
Message msg = Message.obtain();
msg.what = what;
return sendMessageDelayed(msg, delayMillis);
}
public final boolean sendEmptyMessageAtTime(int what, long uptimeMillis) {
Message msg = Message.obtain();
msg.what = what;
return sendMessageAtTime(msg, uptimeMillis);
}
public final boolean sendMessage(@NonNull Message msg) {
return sendMessageDelayed(msg, 0);
}
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");
return false;
}
return enqueueMessage(queue, msg, uptimeMillis);
}
Handler的enqueueMessage(...)最终调用的是MessageQueue的同名方法。可以将MessageQueue理解为一个阻塞队列，当队列中没有当前可以执行的消息时，从MessageQueue中取消息的线程会进入阻塞状态；当往队列中插入消息时，如果该消息可以执行，则唤醒被阻塞的线程。
enqueueMessage(...)的代码中还包含了对异步消息(Asynchronous)的判断，先解释一下异步消息的作用：
一般来说MessageQueue中的Message都是按照它的when属性顺序执行，但是有些Message的优先级更高(界面刷新)，为了保证流畅性，这些Message需要比其余Message先执行，此时可以通过Message.setAsynchronous()来将消息设置成异步消息。异步消息是与Barrier配合使用的，如果一个Message的target是null，那它就是一个Barrier，它之后的消息中只有异步消息会被执行，直到Barrier被移除。
不过关于异步消息的API是不对外开放的，只有系统代码可以调用。
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
// 消息队列不是线程安全的, 因此同步该代码块
synchronized (this) {
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;
}
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake; // 表示是否需要唤醒队列
if (p == null || when == 0 || when < p.when) {
// 消息插入到队头, 如果已经被阻塞了那么就唤醒
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// 将 Message插入到队列中间, 一般来说我们不用唤醒队列
// 除非队头有一个 barrier并且当前 Message是队列中最前面的异步消息
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
2.3 获取Message
Looper.loop()的死循环中，应用通过queue.next()不断从MessageQueue中取出Message并执行，queue.next()主要有以下2个功能：
按Message的when属性依次取出
每个Message通过when属性描述它该在哪个时刻被执行，当MessageQueue中没有Message或者尚未到队头Message的执行时间时，消息队列就会阻塞。直到插入新的Message或者已经到了队头Message的执行时间，消息队列才会被唤醒。在MessageQueue空闲时执行IdleHandler的代码
当MessageQueue空闲时，会自动执行用户提交的IdleHandler中的逻辑，这种"空闲时执行"的思想可以在一定程度上提升性能，我们可以通过以下方式添加IdleHandler，如果queueIdle()返回false，那么它只会被执行一次，如果返回true，那么每次MessageQueue空闲时都会执行。
Looper.myQueue().addIdleHandler(new IdleHandler() {
@Override
public boolean queueIdle() {
// 消息队列空闲时执行
return false;
}
});
下面来分析MessageQueue.next()的源码，看代码中的注释即可。
Message next() {
// 如果消息循环已经退出则在此处返回
// 可能发生在应用尝试在Looper退出后重启它, 但系统不支持该操作
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1;
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
// 阻塞消息队列nextPollTimeoutMillis毫秒
// 如果nextPollTimeoutMillis传-1则会一直阻塞下去, 直到被唤醒
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// 开始寻找下一条Message
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// 发现MessageQueue中有barrier, 开始寻找异步消息
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// 尚未到下一条 Message的执行时间, 设置 MessageQueue的阻塞时长
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// 找到一条 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 {
// MessageQueue中没有 Message
nextPollTimeoutMillis = -1;
}
// 如果外部调用了 quit()且队列中的所有消息都已处理完毕, 可以退出
if (mQuitting) {
dispose();
return null;
}
// 如果是第一次空闲, 获得需要执行的 mIdleHandlers数量
// IdleHandler只会在 MessageQueue为空或者尚未到队头 Message执行时间时运行
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// 只在第一次循环时会运行下方的代码块
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 {
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
// 将 pendingIdleHandlerCount设置为0, 这样第1次循环后就不会再运行 IdleHandler了
pendingIdleHandlerCount = 0;
// 运行 IdleHandler时 MessageQueue中可能被添加了消息
// 所以将 nextPollTimeoutMillis设置为 0
nextPollTimeoutMillis = 0;
}
}
三、HandlerThread
之前提到过，如果需要子线程像主线程一样支持消息机制，需要在子线程中初始化Looper，其实官方提供的HandlerThread就支持这个功能，使用示例如下。
HandlerThread handlerThread = new HandlerThread("test");
handlerThread.start();
Handler handler = new Handler(handlerThread.getLooper());
handler.post(new Runnable() {
@Override
public void run() {
......
}
});
HandlerThread本质上还是一个线程，精简后的代码如下，主要关注它的run()方法。run()方法首先通过Looper.prepare()为当前线程新建Looper；随后在同步代码块中为mLooper赋值，再通过notifyAll()唤醒那些调用getLooper()而阻塞的线程；最后再通过Looper.loop()开启循环。
开启任务循环后，我们可以通过handler.post(Runnable r)给该线程添加任务。
public class HandlerThread extends Thread {
Looper mLooper;
private @Nullable Handler mHandler;
public HandlerThread(String name) {
super(name);
mPriority = Process.THREAD_PRIORITY_DEFAULT;
}
protected void onLooperPrepared() {
// 可以重写这个方法加入自己的逻辑
}
@Override
public void run() {
mTid = Process.myTid();
Looper.prepare();
synchronized (this) {
mLooper = Looper.myLooper();
// 可能有线程在调用 getLooper()时被阻塞, 这里将它们唤醒
notifyAll();
}
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
}
// 该方法返回与当前线程关联的Looper, 如果 isAlive()为 false, 那么该方法返回null
// 有可能当前线程已经启动了, 但是 mLooper还没被赋值, 那么调用这个方法的线程会被阻塞
public Looper getLooper() {
if (!isAlive()) {
return null;
}
// If the thread has been started, wait until the looper has been created.
synchronized (this) {
while (isAlive() && mLooper == null) {
try {
wait();
} catch (InterruptedException e) {
}
}
}
return mLooper;
}
// quit()和 quitSafely()都是用于退出Looper事件循环的
// 调用这两个方法之后, Handler就无法向对应的 MessageQueue中发送 Message
// 它们的区别在于, quit()会直接退出, 而 quitSafely()会等待 MessageQueue的剩余 Message分发完毕
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;
}
}
四、通过消息机制监测卡顿
APP主线程实际运行的就是Looper.loop()，所有操作都以Message的形式传递到消息队列中，例如Activity的生命周期方法、屏幕的一次刷新甚至用户的一次触摸事件等等，可以理解为主线程是以消息驱动的。如果某个Message的执行时间过长，之后的Message(可能是屏幕刷新或触摸事件)没有及时得到处理就会出现卡顿，严重时会出现ANR，我们可以通过监测每一个Message的执行时长来监测卡顿。
还记得Looper.loop()中的logging吗？如果调用Looper.getMainLooper().setMessageLogging(logging)为Looper设置Printer，就可以通过Printer打印的Log来监听每个Message的处理时间了，BlockCanary(见参考2)就是通过这种方式进行卡顿监测的，下面来看一下它的实现原理。
由于每个Message的处理前后都会打印一条信息，因此Log是成对出现的。我们可以通过这个特性得到Message开始处理的时间startTime和结束处理的时间endTime，在Message被处理的期间通过子线程不断dump主线程的调用栈，当Message处理结束后判断处理耗时，如果超过卡顿阈值则输出调用栈用于分析。
public class LooperMonitor implements Printer {
private long mStartTimestamp = 0;
private long mStartThreadTimestamp = 0;
private BlockListener mBlockListener;
private boolean mPrintingStarted = false;
public interface BlockListener {
void onBlockEvent(long realStartTime, long realTimeEnd,
long threadTimeStart, long threadTimeEnd);
}
public LooperMonitor(BlockListener blockListener,
long blockThresholdMillis, boolean stopWhenDebugging) {
......
}
@Override
public void println(String x) {
if (!mPrintingStarted) {
// 开始处理Message
mStartTimestamp = System.currentTimeMillis();
mStartThreadTimestamp = SystemClock.currentThreadTimeMillis();
mPrintingStarted = true;
startDump(); // 让子线程dump主线程的调用栈
} else {
// Message处理完毕
final long endTime = System.currentTimeMillis();
mPrintingStarted = false;
if (isBlock(endTime)) {
// 发生卡顿, 记录过去一段时间的调用栈
notifyBlockEvent(endTime);
}
stopDump(); // 消息处理结束, 让子线程停止dump
}
}
private boolean isBlock(long endTime) {
return endTime - mStartTimestamp > mBlockThresholdMillis;
}
......
}
BlockCanary通过StackSampler实现dump主线程调用栈的功能，内部通过HandlerThread来实现定时dump的功能，代码中HandlerThreadFactory.getTimerThreadHandler()可以获取到该HandlerThread。
public class StackSampler {
private static final LinkedHashMap sStackMap = new LinkedHashMap<>();
private AtomicBoolean mShouldSample = new AtomicBoolean(false);
private Thread mCurrentThread;
private int mSampleIntervals;
public StackSampler(Thread thread, int sampleIntervals) {
mCurrentThread = thread;
mSampleIntervals = sampleIntervals;
}
private Runnable mRunnable = new Runnable() {
@Override
public void run() {
doSample();
if (mShouldSample.get()) {
// 每隔固定时间dump一次
HandlerThreadFactory.getTimerThreadHandler()
.postDelayed(mRunnable, mSampleIntervals);
}
}
};
public void start() {
if (mShouldSample.get()) {
return;
}
mShouldSample.set(true);
HandlerThreadFactory.getTimerThreadHandler().removeCallbacks(mRunnable);
HandlerThreadFactory.getTimerThreadHandler().postDelayed(mRunnable, 1000);
}
public void stop() {
if (!mShouldSample.get()) {
return;
}
mShouldSample.set(false);
HandlerThreadFactory.getTimerThreadHandler().removeCallbacks(mRunnable);
}
public ArrayList getThreadStackEntries(long startTime, long endTime) {
ArrayList result = new ArrayList<>();
synchronized (sStackMap) {
for (Long entryTime : sStackMap.keySet()) {
if (startTime < entryTime && entryTime < endTime) {
result.add(......); // 将调用栈信息添加到result中
}
}
}
return result;
}
private void doSample() {
StringBuilder stringBuilder = new StringBuilder();
for (StackTraceElement stackTraceElement : mCurrentThread.getStackTrace()) {
stringBuilder.append(stackTraceElement.toString()).append(BlockInfo.SEPARATOR);
}
synchronized (sStackMap) {
if (sStackMap.size() == DEFAULT_MAX_ENTRY_COUNT && DEFAULT_MAX_ENTRY_COUNT > 0) {
sStackMap.remove(sStackMap.keySet().iterator().next());
}
sStackMap.put(System.currentTimeMillis(), stringBuilder.toString());
}
}
}
以上就是BlockCanary的核心思路，它能获取到卡顿发生时的调用栈，但无法精确地知道每个方法的调用耗时，也无法知道卡顿时是CPU繁忙还是IO繁忙，因此没有能力做到精准定位。
五、预防内存泄露之WeakHandler
5.1 Handler与内存泄漏
原生Handler存在内存泄漏的风险，如果将Handler作为匿名内部类使用并post延时消息，在消息未处理完时关闭Activity，就会造成泄漏。这是因为Activity关闭时，MessageQueue中的Message尚未被处理，而Message又持有Handler的引用，Handler作为匿名内部类会隐式地持有外部类(也就是Activity)的引用，从而造成内存泄漏。
解决内存泄漏的关键就在于切断引用链，一种解决方式是在Activity销毁时将所有Handler发送的Message从MessageQueue中移除，在onDestroy()中调用handler.removeCallbacksAndMessages(null)即可；还有一种解决方式是将Handler声明为静态类，再持有Activity的弱引用，此时Handler也能调用Activity中的方法。
5.2 WeakHandler
除了上述两种方式，我们还可以使用WeakHandler直接代替原生Handler使用，使用示例如下。
WeakHandler weakHandler = new WeakHandler(new Handler.Callback() {
@Override
public boolean handleMessage(@NonNull Message msg) {
// ......
}
});
原生Handler发送的Message的生命周期与持有Handler的Activity是不一致的，Activity销毁后该Handler的Message有可能不会被回收。针对这个问题，WeakHandler通过弱引用对Handler和Runnable进行了一次封装，保证WeakHandler发送的Message和Runnable的生命周期与WeakHandler一致。先来看WeakHandler的变量声明。
public class WeakHandler {
private final Handler.Callback mCallback;
private final ExecHandler mExec;
private Lock mLock = new ReentrantLock();
@SuppressWarnings("ConstantConditions")
final ChainedRef mRunnables = new ChainedRef(mLock, null);
......
}
其中ExecHandler就是Handler的封装，用来完成消息的分发与处理工作，它持有mCallback的弱引用，并通过该mCallback来处理消息。
private static class ExecHandler extends Handler {
private final WeakReference mCallback;
// 省略构造方法
@Override
public void handleMessage(@NonNull Message msg) {
if (mCallback == null) {
return;
}
final Handler.Callback callback = mCallback.get();
if (callback == null) { // Already disposed
return;
}
callback.handleMessage(msg);
}
}
Runnable封装后为WeakRunnable，其内部通过一个弱引用指向真正的Runnable。
static class WeakRunnable implements Runnable {
private final WeakReference mDelegate;
private final WeakReference mReference;
WeakRunnable(WeakReference delegate, WeakReference reference) {
mDelegate = delegate;
mReference = reference;
}
@Override
public void run() {
final Runnable delegate = mDelegate.get();
final ChainedRef reference = mReference.get();
if (reference != null) {
reference.remove();
}
if (delegate != null) {
delegate.run();
}
}
}
当通过WeakHandler.post(Runnable r)添加一个任务时，WeakHandler会将其包装为WeakRunnable添加到MessageQueue中。
public final boolean post(@NonNull Runnable r) {
return mExec.post(wrapRunnable(r));
}
private WeakRunnable wrapRunnable(@NonNull Runnable r) {
//noinspection ConstantConditions
if (r == null) {
throw new NullPointerException("Runnable can't be null");
}
final ChainedRef hardRef = new ChainedRef(mLock, r);
mRunnables.insertAfter(hardRef);
return hardRef.wrapper;
}
你可能会奇怪wrapRunnable(Runnable r)中的ChainedRef是做什么的，为什么post(Runnable r)时还要将这个Runnable封装成ChainedRef添加到mRunnables这个单链表中？
其实mRunnables和mCallback这两个私有变量的作用都是一样的，都是为了维护对应变量的强引用。根据弱引用的定义，当一个对象只有弱引用指向它时，GC就会将其回收。为了避免ExecHandler中的mCallback和WeakRunnable中的Runnable对象过早被回收，WeakHandler通过私有变量mCallback和mRunnables保留它们的强引用，保证mCallback和Runnable在WeakHandler还被引用时不被回收。
参考
- Android消息机制1-Handler(Java层)
- BlockCanary — 轻松找出Android App界面卡顿元凶