Android线程间异步通信机制源码分析

    本文首先从整体架构分析了Android整个线程间消息传递机制，然后从源码角度介绍了各个组件的作用和完成的任务。文中并未对基础概念进行介绍，关于threadLacal和垃圾回收等等机制请自行研究。

基础架构

    首先，我们需要从整体架构上了解一下Android线程通信都做了哪些工作。我们都知道，进程是操作系统分配资源的最小单位，一个进程中可以启动多个线程来执行任务，这些线程可以共享进程的资源但不分配资源，这里讲的资源主要是只内存资源。Android的线程间消息传递机制其实和我们现实生活人们通信中很相似，我们可以类比一下两个人的通信过程：假设A要给B写信，首先将信写好装入信封（Message），交给B的邮递员（handler）投入B的信箱（messageQueue）中，B的管家（looper）发现有信件需要查收，就交给B来处理。下图是其余线程向主线程发送消息的示意图：

    整个过程如下：

1. 子线程通过主线程的handler发送一条消息给主线程；
2. 这条线程被放入主线程的消息队列中；
3. 整个消息队列是由looper来创建和管理的，通过轮询一旦发现有新消息存在就取出交给主线程处理。

组件源码分析

    了解过整个架构之后，我们就从源码的角度体会一下Android线程之间通信机制的精妙设计吧。

信封message

    Message类作为发送给handler的消息，其中封装了一份对于消息的描述以及需要传递的数据对象。关于消息回收机制我们放在后面的文章中介绍，这里先只把它当作封装了要传递数据的消息类。首先，两个int成员变量和一个obj对象用于存储被传递的数据：

• what： 用户自定义的消息码，用于消息接收者识别该消息的类型。
• arg1、arg2： 如果只传递int值，可以采用这两个参数存储。
• obj ： 可以存放需要传递的数据对象。

     还有一些成员变量也需要简单了解一下：

• int flags ： 该消息是否正在被取用
• long when ： 时间戳
• Bundle data ： 要传递的数据
• Handler target ： 指定处理该消息的目标handler.
• Runnable callback ：也可以指定处理该消息的回调函数
• message next： 指向下一个message，后面介绍messageQueue时再详细介绍。

 

    通过obtain方法可以获取一条message对象使用（工厂模式）：

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

    还有一些关于成员变量的存取方法，就不一一介绍了，我们使用的时候只需要获取到message对象，将要传递的数据放入该对象中就OK了。然后我们需要调用sendToTarget方法把这个消息发送出去：

/**
     * Sends this Message to the Handler specified by {@link #getTarget}.
     * Throws a null pointer exception if this field has not been set.
     */
    public void sendToTarget() {
        target.sendMessage(this);
    }

    当然，你要指明要把该消息交给哪个handler来处理，不然会报空指针哟。方法中调用了handler的sendMessage方法，下面我们来研究一下handler。

邮递员handler

    handler其实并不仅仅像是传统意义上的邮递员而已，因为handler既负责在子线程中发送消息到主线程的messageQueue中，又负责在主线程中从looper中取出消息进行处理，你见过有这么周到的邮递员吗？一个handler实例只为一个线程以及其消息队列服务，当你在某个线程中创建一个handler实例对象，那么该handler对象就与该线程和它的消息队列绑定在一起，并开始为它们进行服务了。另外需要提到的一点是，这里的消息并不仅仅是指数据，也可以是能被主线程执行的Runnable对象。

    当应用程序的进程创建后，它的主线程维护了一个消息队列用于管理那些顶层的应用组件（activity，broadcast receiver等）以及创建出来的窗口。而你自己开启的线程可以通过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();// 获取到当前线程的looper
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
       mQueue = mLooper.mQueue;// 获取到looper管理的消息队列
        mCallback = callback;// 自定义的回调函数
        mAsynchronous = async;
    }

    其中有关内存泄露问题我们稍后再谈。先关注一下我们的handler在创建时做了哪些工作。在谈论整个通信机制的时候我们说过，一个线程只能有一个looper用来轮询唯一的一个消息队列，即线程，looper，消息的队列的关系是一一对应的。而handler和looper之间是一对多的关系，即一个looper可以由多个handler来为它服务。在handler的构造函数中，主要工作就是把handler和它要服务的looper，消息队列关联起来。

    handler可以向队列中发送消息或者添加一个可执行的runnable对象，消息队列会安排在某一时刻进行消息处理或者执行runnable对象run方法：

• post(Runnable r)：将runnable对象加入消息队列，该runnable对象将会被消息队列所在线程执行。
• postAtTime(Runnable, long)： 将runnable对象加入消息队列，在指定的时间执行该runnable对象。
• postDelayed(Runnable r, long delayMillis)：将runnable对象加入消息队列，经过指定延迟时间后执行。
• sendEmptyMessage(int what)：将一条仅包含what值的消息发送给消息队列
• sendMessage(Message msg)：将一条消息加入消息队列
• sendMessageAtTime(Message msg, long uptimeMillis)：在指定时间将一条消息加入队列尾部
• sendMessageDelayed(Message msg, long delayMillis)： 在经过指定时间延迟后，将一条消息加入队列尾部

    通过这些方法，handler将message对象交给了消息队列messageQueue。looper从消息队列中取出message后，会调用message所持有的handlerdispatch方法，分发给handler来处理该消息：

public void dispatchMessage(Message msg) {
        if (msg.callback != null) {// 如果message对象持有回调对象，则执行它
            handleCallback(msg);
        } else {
            if (mCallback != null) {// 如果当前handler持有消息处理的回调函数，则执行它
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);// 如果都没有，则执行用户自定义的消息处理方法
        }
    }

管家Looper和信箱MessageQueue

    从上面的分析我们可以了解，message对象是通过handler间接的加入到消息队列中的，然后消息队列将message对象组织成一个队列提供给looper分发。如果只看名字，我们会猜想这个类中使用队列这种数据结构来组织message，然而并不是这样的。MessageQueue将message对象按时间顺序组织成一个链表的形式来管理。

    在创建handler对象的时候，我们通过looper.myLooper方法从threadLocal中获取到与当前线程一一对应的looper对象。那么当前线程是何时创建了整个looper对象并将其放入threadLocal呢？在Android的UI线程中，早已自动替我们创建好了looper；而如果是我们自己创建的线程，那么就需要调用prepare方法来创建出looper对象：

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

    在创建looper对象的时候也创建了它要轮询的消息队列，并获取了当前线程的引用：

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

    由于线程和looper对象是一一对应的关系，所以我们有时候判断当前线程是否为UI线程的时候，会调用getMainLooper方法来判断：

public static Looper getMainLooper() {
        synchronized (Looper.class) {
            return sMainLooper;
        }
}

    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，有可能会阻塞
            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
            Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }
            // 把从队列中取到的message交给handler来处理
            msg.target.dispatchMessage(msg);

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

    到此为止，在子线程中创建的message对象就被处理好了。下面我们需要谈论一下handler的泄露问题以及解决方法。

Handler泄露问题

    谈论整个问题之前，我们需要了解JAVA的GC机制，这里就不做详细介绍了。当我们在activity中创建一个handler对象时，往往会继承一个匿名内部类，里面复写了handler的handleMessage方法。这时，该匿名内部类就会持有当前activity的对象引用。同时，持有该handler的子线程对象往往会进行一些耗时的操作，创建message对象并把handler对象的引用赋给它。此时如果用户关闭了activity，那么此activity对象是应该被系统回收的。但是，由于子线程的耗时操作，并且它和未处理的message对象都持有handler的引用，而handler又持有activity的引用，这就会导致该activity无法回收，出现内存泄露。

    目前主要有两种解决方案：

• 第一种，在activity关闭时，停掉该子线程，然后调用handler的removeCallbacks方法，把消息队列中的message删除掉。
• 第二种，让匿名内部类作为一个静态内部类出现，这样就不持有activity的对象引用了，activity就可以被回收掉了。但是，不持有activity的引用，怎么操作其中的对象呢？只好自己声明一个弱引用了：

  static class myHandler extends Handler {
      WeakReference<Activity > mActivityReference;
  
      myHandler(Activity activity) {
          mActivityReference= new WeakReference<Activity>(activity);
      }
  
      @Override
      public void handleMessage(Message msg) {
      //消息处理......
      }
  }

   

    弱引用在垃圾回收的时候会被忽略，所以可以被安全回收。