Android之Handler消息处理机制

Handler的作用

      Handler消息机制在Android中的应用非常广泛，很多组件的底层实现都是靠Handler来完成的，所以掌握Handler消息机制的原理还是非常重要的。Handler的主要功能有两点：

      1.它可以在不同的线程之间传递消息  

      我们都知道Andorid中规定只有主线程里可以进行UI操作，在其他线程中绝不可以进行与UI相关的操作，否则会报错。还有就是在主线程中也不可以进行耗时操作，否则会阻塞主线程，报ANR。基于以上这两点，我们就可以使用Handler在子线程中处理耗时操作，然后把返回的结果传给主线程，再进行UI方面的更新处理等。

      2.它可以延时传递消息。

      如果我们想要处理一个延时操作，一般可以通过Thread.sleep(times)使线程休眠几秒，然后再处理数据。但是再Android中是绝不能允许在主线程红进行休眠操作阻塞线程的，所以我们可以通过Handler来发送延迟消息的方式实现延时操作。

消息处理机制 

      Android的消息处理机制表面上只是使用了Handler，但其实还用到了其他的东西，比如说ThreadLocal，Looper，MessageQuery等，这些组合在一起使用，才构成了整个Android消息机制。

      我们先回顾一下Handler的使用：我们以 “在子线程处理完耗时操作，然后通过Handler发送消息到主线程更新UI”为例。首先要先在主线程创建一个Handler对象，重写它的handlerMessage()方法，处理更新UI的操作。然后我们在子线程进行处理耗时操作，当执行完成后，我们创建一个Message对象，将需要传递的数据存入Message对象中，再调用Handler对象的sendMessage()方法将该Message对象发送出去。之后我们就能在Handler的handlerMessage()方法中接收到该Message对象了，然后取出其中的数据，进行更新UI的操作即可，这样整个过程就算完成了。

      上面说的例子是从子线程发送消息回主线程，然后再主线程中处理消息。如果是通过主线程发送消息到子线程，然后在子线程处理消息，那又应该如何做呢？我们尝试直接在子线程中创建Handler对象，重写handlerMessage()方法，然后在主线程中发送消息，但程序运行后会报如下错误：

java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()

      意思是“不能够在一个没有执行过Looper.prepare()方法的线程中去创建Handler对象”，到这里我们终于能够看到Looper的影子了。那么这里就有一个问题，为什么在主线程中没有要求我们先调用Looper.prepare()方法呢，或者说与普通线程相比，主线程有什么特别的吗？

      其实这是因为在主线程中，系统已经调用过该方法了，所以不需要我们再去手动调用。代码如下，主线程在刚开始创建的时候它的Looper就已经调用了prepareMianLooper()方法，所以我们能直接创建Handler。

public final class ActivityThread { 
   public static void main(String[] args) {

        ...

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

      下面开始介绍消息机制中几个重要的类。

ThreadLocal

      ThreadLocal类通过泛型可以存储任何类型的对象，它内部主要的方法为set()和get()方法。它通过set()方法存储对象，通过get()方法拿到存储的对象。ThreadLocal类的特点是它会以线程为作用域来存储数据，比如我们创建一个ThreadLocal对象来存储Integer类型数据，首先我们在主线程中给这个ThreadLocal对象赋值为10，在子线程1中给这个对象赋值为20，在子线程2中不进行赋值操作，然后分别打印ThreadLocal中存储的数据的值。

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //在主线程中赋值为10
        mThreadLocal.set(10);
        //打印结果
        Log.e("test","Thread*main mThreadLocal:"+mThreadLocal.get());

        new Thread("Thread*1"){
            @Override
            public void run() {
                super.run();
                //在线程1中赋值为20
                mThreadLocal.set(20);
                //打印结果
                Log.e("test","Thread*1 mThreadLocal:"+mThreadLocal.get());
            }
        }.start();
        new Thread("Thread*2"){
            @Override
            public void run() {
                super.run();
                //在线程2中不进行赋值操作，打印结果
                Log.e("test","Thread*2 mThreadLocal:"+mThreadLocal.get());
            }
        }.start();
    }

      最终得到的结果如下：

11-19 23:13:42.422 15945-15945/com.weimore.demo1 E/test: Thread*main mThreadLocal:10
11-19 23:13:42.425 15945-15965/com.weimore.demo1 E/test: Thread*1 mThreadLocal:20
11-19 23:13:42.425 15945-15966/com.weimore.demo1 E/test: Thread*2 mThreadLocal:null

      可见在不同的线程中，对同一个ThreadLoccal对象进行赋值，但最后的结果是不同的。ThreadLocal以线程为作用域来存储对象，保证了对象在不同线程中的数据独立性和唯一性。当然，要想真正了解ThreadLocal是如何做到分线程存储数据的，还是得看set()和get()方法的源码。

      在set()方法中，首先会获得当前线程对象，然后调用getMap()方法，在getMap()方法中其实就是获取当前线程中的成员变量threadlocals，它是一个ThreadLocalMap对象，其实就是以Map的形式存储数据。如果该对象存在，则将数据存入，否则就创建该对象，然后再存入数据。所以通过set()方法，我们知道了，数据其实最终是保存在当前线程的一个成员变量threadlocals中。

    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

      而get()方法其实就是从获取当前所在线程的threadlocals对象，然后从中取出存储的数据。如果之前没有通过ThreadLocal存储过数据，则返回null。

   public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null)
                return (T)e.value;
        }
        return setInitialValue();
    }

      因此，我们知道了，原来通过ThreadLocal存储数据，最终其实存储在线程的成员变量中的，所以我们在不同的线程中取得的数据不是同一个对象，所以赋值过后，得到的结果会不同。

      ThreadLocal类在消息机制中主要是负责存储Looper的，系统通过ThreadLocal来存储和获得Looper对象，从而保证每个线程的Looper是独立且唯一的。

MessageQuery

      MessageQuery虽然叫做消息队列，但其实内部是以单链表的方式存储消息的。MessageQuery是在Looper初始化时被创建的，它负责和Looper，Handler一起协作来维持整个消息机制的运作。MessageQuery中重要的方法有两个：enqueueMessage()，next()。

      enqueueMessage()方法的作用是插入一个消息到链表中，当Handler调用sendMessage()方法时会调用enqueueMessage()方法。而next()方法的作用就是循环地从链表中返回和移除消息并交由Handler去处理消息，该方法会Looper的loop()方法中被调用。

Handler

      Handler的使用我们已经非常熟悉了，Handler中比较常用的方法就是post()或postDelayed()方法,还有sendMessage()和sendMessageDelayed()方法等，其实这四个方法最后都是调用sendMessageDelayed()方法，而sendMessageDelayed()方法又是调用sendMessageAtTime(方法。在sendMessageAtTime()中我们发现了如下代码：

 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()方法，并将mQueue对象传入其中，可以看到这个mQueue是一个MessgaeQuery对象，那么它是从何而来？难道Handler的内部也有一个MessagerQuery队列？我们查看Handler初始化的方法，发现这个mQueue是从当前线程的Looper中得到的。

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

      那么Handler的enqueueMessage()方法到底做了什么呢？

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

      我们看它的源码，发现在该方法中Handler将自己存储在了Message对象的成员变量target中，然后调用用了消息队列的enqueueMessage()方法将Message对象传入。前面已经说过，MessageQuery中的enqueueMessage()负责将消息存入消息队列中，而这里就是该方法具体被调用的地方。也就是说我们在使用Handler的sendMessage()方法时，其实是将Handler自身存入了消息中，然后再将消息存入了Looper中的消息队列中。

      Handler中还有一个比较重要的方法就是dispatchMessage()方法。该方法会在Looper的方法中被调用，它的主要作用是将从消息队列中取出的消息发送到Handler的handlerMessage()方法中。如下：

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

      

Looper

      Looper算是消息机制的核心类，它负责创建消息队列，以及开启循环。当消息队列中有消息存在时，就将消息从消息队列中取出，并交由Handler处理。因此一个线程中如果想要使用Handler，就必须先创建Looperd对象，否则无法开启消息循环，更别说发送接收消息。又因为一个线程中不能存在多个消息队列，所以每个线程中Looper只允许被创建一次。而主线程中因为已经在内部创建过Looper对象了，所以可以直接使用Handler，如果在主线程再创建Looper实例的化，就会报Looper重复创建的异常。

      Looper类中主要的方法有以下几个：prepare()，getMainLooper()，loop()，myLooper()。

      其中getMainLooper()方法可以获取到主线程的Looper对象，myLooper()方法可以获取到当前线程的Looper对象，我们可以通过对比这两个方法得到的Looper对象是否为同一个对象，从而判断当前线程是否是主线程。

      在Looper.prepare()方法中，主要负责创建Looper对象和创建消息队列。我们找到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));
    }

      可以看到，首先要判断当前线程是否已拥有Looper对象。这里的sThreadLocal其实就是ThreadLocal类的对象。如果发现ThreadLocal对象在当前线程中已经存储过Looper了，说明Looper被重复创建了，则抛出“only one Looper may be created per thread”异常，如果ThreadLocal中还未存储Looper，则创建Looper，并存储到ThreadLocal中。

      我们再接着看Looper的构造方法：

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

      在Looper的构造方法中会创建一个MessageQuery(消息队列)，并将当前线程赋值给mThread变量。这里我们可以知道消息队列确实是由Looper创建的，如果不创建Looper，消息队列就不存在。

      我们接着看Looper的最后一个也是最重要的方法loop()。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();
        }
    }

      可以看到在loop()方法中存在一个无限for循环，它会不断的调用MessageQuery的next()方法，从消息队列中取出消息，而在下面还调用了msg.target的diapatchMessage()方法用来处理取出的消息。前面分析Handler时说到过，这个msg.target其实就是Handler自身，所以其实这里就是调用Handler的dispatchMessage()方法。上面也说了Handler的despatchMessage()方法最终会将消息发送到handlerMessage()中去处理。这里要注意的是，我们用Handler发送消息时可能是在别的线程中发送的，但最后消息是在Looper的loop()方法中被取出然后处理的，最后的handlerMessage()方法一定是在Looper所在的线程中被执行的。

由Handler引发的内存泄漏

      我们先来看一下平常我们在Activity中创建Handler可能会造成内存泄漏的写法：

public class MainActivity extends AppCompatActivity {

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

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //发送延迟消息
        handler.sendEmptyMessageDelayed(0, 1000 * 6);
    }

}

      像上面这种情况就非常由可能会造成内存泄漏。我们可以看到，上面在Activity中创建Handler，其实是使用了匿名内部类的方法创建的Handler对象。在Java中，非静态内部类（包括匿名内部类）是会持有外部类的引用的，所以这时的Handler就持有了Activity的引用。

       根据前面我们了解的Android的消息机制，明白了在主线程中创建Handler后，Handler发送的消息会被发送到主线程的Looper所创建的消息队列中，这时主线程的MessageQuery就持有了Message的引用，另外由于Message中的target变量其实就是Handler自身，所以Message其实也持有了Handler的引用。这样就导致了也许Handler正在发送或处理延迟消息时，Activity被销毁了，但Activity的引用被Handler所持有，所以造成了内存泄漏。

ActivityThread -> Looper -> MessageQuery -> Message -> Handler ->Activity

      解决这种内存泄漏的方法有几种：

      首先最简单的，就是将 Handler 声明为静态内部类，这样Handler就不会持有Activity的引用了，当然如果你确实需要Activity的引用来处理某些东西，那就使用WeakReference，让Handler持有Activity的弱引用，这样也不会造成内存泄漏。还有一种方法就是在Activity被销毁的时候调用Handler.removeCallbacksAndMessages()方法，移除消息队列中的所有消息和回调，这样就不会使Handler被MessageQuery持有引用，也就不会造成内存泄漏了。