Android—消息机制与WeakHandler源码分析

一、消息机制简述

消息机制是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个功能:

  1. 按Message的when属性依次取出
    每个Message通过when属性描述它该在哪个时刻被执行,当MessageQueue中没有Message或者尚未到队头Message的执行时间时,消息队列就会阻塞。直到插入新的Message或者已经到了队头Message的执行时间,消息队列才会被唤醒。

  2. 在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<Long, String> 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<String> getThreadStackEntries(long startTime, long endTime) {
        ArrayList<String> 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<Handler.Callback> 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<Runnable> mDelegate;
        private final WeakReference<ChainedRef> mReference;

        WeakRunnable(WeakReference<Runnable> delegate, WeakReference<ChainedRef> 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还被引用时不被回收。

参考

  1. Android消息机制1-Handler(Java层)
  2. BlockCanary — 轻松找出Android App界面卡顿元凶