关于Handler，你应该掌握的一切

最近面试比较多，Handler是Android面试最多最重要的知识点之一，这篇文章就来深入分析了解Handler的运行机制，实现Handler的最佳使用。

1.概述

定义：主要接受子线程发送的数据， 并用此数据配合主线程更新UI。

提到Handler，我们不得不了解几个关键的概念：

• Handler
• Looper
• MessageQueue
• Message

简单概括：Looper负责的就是创建一个MessageQueue，然后进入一个无限循环体不断从该MessageQueue中读取Message；Handler负责发送消息对象到消息队列，然后处理Looper读取出的消息对象。

2.Handler的常规使用

接下来，我们就从最基本的一个Handler的用法中去深入分析其原理。

public class HandlerTestActivity extends AppCompatActivity {

    private Handler mHandler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            switch (msg.what){
                case 1:
                    Toast.makeText(HandlerTestActivity.this,msg.obj.toString(),Toast.LENGTH_SHORT).show();
                break;
            }
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler_test);

        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(10000);       
                    mHandler.obtainMessage(1,"Hello")
                    .sendToTarget();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

上面代码很简单，但是完全可以展现Handler的使用方式，Handler在子线程中将消息发送到主线程中。

3.源码分析

我们都知道异步消息处理是通过Handler、Looper、MessageQueue、Message结合实现的，那么究竟是如何实现的，我们一步步通过源码来分析具体的原理。

首先明确几个概念：
1. 一个线程只允许有一个Looper对象；
2. MessageQueue是由Looper创建的；
3. Message是由Handler创建的。

以上几个问题，我们会在下面的分析中一一进行验证。
首先，我们都知道Android系统有一个主线程，几乎所有的UI操作都放在主线程中执行。在Android主线程中，系统维护了一个Looper对象，因此，我们几乎不用去关心Looper的初始化。那么这个主线程的Looper究竟是在哪里初始化的呢？

我们知道所有的Activity都是继承自Android系统的Activity基类，Activity中有一个ActivityThread实例，也就是我们常说的主线程。

在ActivityThread中，系统初始化了一个Looper对象。

 public static void main(String[] args) {

        ***

        Process.setArgV0("<pre-initialized>");

        Looper.prepareMainLooper();

        ActivityThread thread = new ActivityThread();
        thread.attach(false);

        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }

        if (false) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));
        }

        // End of event ActivityThreadMain.
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

第7行Looper.prepareMainLooper()创建了Looper对象
第23行Looper.loop()开始无限循环消息队列。

知道了主线程在何时创建的Looper后，我们来深入分析Looper里面究竟做了什么操作。

Looper源码

Looper里面关键的方法：
1. prepare()方法
2. loop()方法

我们在上面已经知道主线程中是通过Looper.prepareMainLooper()方法实例化的Looper对象。

public static void prepareMainLooper() {
        prepare(false);
        synchronized (Looper.class) {
            if (sMainLooper != null) {
                throw new IllegalStateException("The main Looper has already been prepared.");
            }
            sMainLooper = myLooper();
        }
    }

第二行可以看到上面提到的prepare()方法，

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));
    }

sThreadLocal是一个ThreadLocal对象，可以在一个线程中存储变量。可以看到，在第5行，将一个Looper的实例放入了ThreadLocal，并且2-4行判断了sThreadLocal是否为null，否则抛出异常。这也就说明了Looper.prepare()方法不能被调用两次，同时也保证了一个线程中只有一个Looper实例。
Only one Looper may be created per thread这个异常可能有些人遇到过。

ThreadLocal实例化了一个Looper，那么我们来看下Looper的构造方法：

private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
    }

构造方法中创建了一个MessageQueue对象，这也验证了我们上面总结的Looper中创建消息队列。

接下来我们看主线程中的Looper.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 block
            if (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 logger
            final Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }

            final long traceTag = me.mTraceTag;
            if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
                Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
            }
            try {
                msg.target.dispatchMessage(msg);
            } finally {
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
                }
            }

            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();
        }
    }

第2行拿到Looper对象
接着第6行拿到了MessageQueue对象，然后无限循环遍历消息队列，当遍历到消息对象的时候通过msg.target.dispatchMessage(msg)方法，将消息交给Message的target的dispatchMessage方法去处理。Msg的target其实就是handler对象，下面会进行分析。

Handler源码

接下来我们看Handler初始化的时候做了哪些操作：

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;
    }

11行通过Looper.myLooper()获取了当前线程保存的Looper实例；
16行又获取了这个Looper实例中保存的MessageQueue；
这样就保证了handler的实例与我们Looper实例中MessageQueue关联上了。

然后我们看Handler的sendMessage方法:

public final boolean sendMessage(Message msg)
    {
        return sendMessageDelayed(msg, 0);
    }

public final boolean sendMessageDelayed(Message msg, long delayMillis)
    {
        if (delayMillis < 0) {
            delayMillis = 0;
        }
        return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
    }

public boolean sendMessageAtTime(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);
    }

其实enqueueMessage方法才是我们关注的：

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
        msg.target = this;
        if (mAsynchronous) {
            msg.setAsynchronous(true);
        }
        return queue.enqueueMessage(msg, uptimeMillis);
    }

enqueueMessage中首先为meg.target赋值为this，查看Message的源码可以看到，其实这个target就是一个Handler对象，也就是把当前的handler作为msg的target属性。最终会调用queue的enqueueMessage的方法，也就是说handler发出的消息，最终会保存到消息队列中去。

现在已经清楚，线程中的Looper会调用prepare()和loop()方法，在当前线程中保存一个Looper实例，这个实例会保存一个MessageQueue消息队列，并且无限循环从消息队列中读取Handler发来的消息。然后通过Handler中的dispathMessage方法处理消息对象，接下来看看这个方法：

public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

这里handleMessage方法是我们在创建Handler时候实现的方法，系统的该方法是一个空方法，交给我们实现。

到此为止，Handler的分析也结束了。整体流程大概是：

1. 首先线程中保存一个Looper实例，Looper中保存一个消息队列；因为Looper.prepare()在一个线程中只调用一次，所以一个线程中只会有一个Looper；
2. Looper.loop()方法会让当前线程进入一个无限循环，不断从MessageQueue中读取消息对象，然后通过Message的target（是一个Handler）的dispatchMessage(msg)方法处理消息；
3. Handler的构造方法中会得到当前线程的Looper对线，根据Looper对象在得到MessageQueue消息队列；
4. Handler的sendMessage方法将该handler赋值给msg的target属性，然后加入消息队列；
5. 我们重写handleMessage方法，也就是msg.target.dispatchMessage(msg)最终调用的方法。

Handler的最佳实践

通常我们使用Handler的时候是这样的：

private Handler mHandler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    };

但是细心的你可能会发现，这样使用handler时，我们往往会得到如下警告：

 ⚠ In Android, Handler classes should be static or leaks might occur.

系统建议我们使用静态方式，否则它却会造成严重的内存泄漏问题。简单概括内存泄漏的根本原因：

只要有未处理的消息，那么消息会引用handler，非静态的handler又会引用外部类，即Activity，导致Activity无法被回收，造成泄漏；

为了解决遇到的问题，我们要明确一点：

静态内部类不会持有对外部类的引用。所以，我们可以把handler类放在单独的类文件中，或者使用静态内部类便可以避免泄漏。

另外，如果想要在handler内部去调用所在的外部类Activity，那么可以在handler内部使用弱引用的方式指向所在Activity，这样统一不会导致内存泄漏。

public class MyActivity extends Activity{

    private final MyHandler mHandler = new MyHandler(this);

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mHandler.postDelayed(sRunnable, 1000 * 60 * 10);
        finish();
    }

    /**
     * 静态类
     */
    private static final Runnable sRunnable = new Runnable() {

        @Override
        public void run() {
             TODO: 2017-09-28  
        }
    };

    /**
     * 静态内部类
     */
    private static class MyHandler extends Handler {

        private final WeakReference<MyActivity> mActivity;

        public MyHandler(MyActivity activity) {
            mActivity = new WeakReference<MyActivity>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            MyActivity activity = mActivity.get();
            if (activity != null) {
                // ...
            }
        }
    }
}

上面Handler的使用方式可以很好的避免内存泄漏的问题。对于匿名类Runnable，同样将其设置为静态类。因为静态的匿名类不会持有对外部类的引用。

虽然静态类与非静态类之间的区别并不大，但是对于Android开发者而言却是必须理解的。至少我们要清楚，如果一个内部类实例的生命周期比Activity更长，那么我们千万不要使用非静态的内部类。最好的做法是，使用静态内部类，然后在该类里使用弱引用来指向所在的Activity。

---

相信仔细看过后，我们会对Handler有一个深入的了解，对Android异步消息处理的机制有一个整体的认知。

如果对你有帮助，欢迎留言交流，关注点赞，谢谢！