本文共 15727 字，大约阅读时间需要 52 分钟。

一、Handler、Looper、MessageQueue、HandlerThread、ActivityThread、Message结构

1、Message：消息；其中包含了消息ID，消息对象以及处理的数据等，由MessageQueue统一列队管理，终由Handler处理

2、MessageQueue：消息队列；用来存放Handler发送过来的消息，并按照FIFO（先入先出队列）规则执行。当然，存放Message并非实际意义的保存，而是将Message以链表的方式串联起来的，等Looper的抽取。

3、Looper：消息泵，不断从MessageQueue中抽取Message执行。因此，一个线程中的MessageQueue需要一个Looper进行管理。Looper是当前线程创建的时候产生的（UI Thread即主线程是系统帮忙创建的Looper，而如果在子线程中，需要手动在创建线程后立即创建Looper[调用Looper.prepare()方法]）。也就是说，会在当前线程上绑定一个Looper对象。

4、Thread：线程；进程中执行运算的最小单位，亦即执行处理机调度的基本单位。某一进程中一路单独运行的程序。

5、HandlerThread：Thread+Looper；具有Looper功能的子线程。

6、ActivityThread：主线程；一个应用的主线程。

在上图中，Handler通过Looper向MessageQueue中插入消息，Looper从MessageQueue（单链表）取出消息再交给Handler处理。ActivityThread为系统主线程（Looper，非继承Thread），HandlerThread可以认为是子线程（Looper+Thread）。Handler默认是ActivityThread的Looper，也可以传入HandlerThread的Looper。通过上述模型，实现消息的跨线程通信。

二、Handler源码分析

1、构造函数

public Handler() {       this(null, false);   }    public Handler(Callback callback, boolean async) {       if (FIND_POTENTIAL_LEAKS) {           final Class
    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;   }

(a)校验是否可能内存泄漏

Handler的构造函数中首先判断了FIND_POTENTIAL_LEAKS的值，为true时，会获取该对象的运行时类，如果是匿名类，成员类，局部类的时候判断修饰符是否为static，不是则提示可能会造成内存泄漏。

问：为什么匿名类，成员类，局部类的修饰符不是static的时候可能会导致内存泄漏呢？ 答：因为，匿名类，成员类，局部类都是内部类，内部类持有外部类的引用，如果Activity销毁了，而Hanlder的任务还没有完成，那么Handler就会持有activity的引用，导致activity无法回收，则导致内存泄漏；静态内部类是外部类的一个静态成员，它不持有内部类的引用，故不会造成内存泄漏。

(b)初始化一个Looper mLooper

如果没有调用Looper.prepare()则不能再线程里创建handler！我们都知道，如果我们在UI线程创建handler，是不需要调用这个方法的，但是如果在其他线程创建handler的时候，则需要调用这个方法。

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));    }    public static Looper getMainLooper() {        synchronized (Looper.class) {            return 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();        }    }

第一步调用了prepare(false)，这个方法我们刚才已经看了，是创建一个Looper对象，然后存到sThreadLocal中；

然后判断sMainLooper是否为空，空则抛出异常 sMainLooper不为空，则sMainLooper = myLooper()

至此sMainLooper对象赋值成功，所以，我们需要知道prepareMainLooper()这个方法在哪调用的，跟一下代码，就发现在ActivityThread的main方法中调用了Looper.prepareMainLooper();。现在真相大白：

当我们在UI线程中创建Handler的时候sThreadLocal里的Looper是在ActivityThread的main函数中调用了prepareMainLooper()方法时初始化的。

(c)初始化一个MessageQueue mQueue

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

2、Handler发送消息

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

3、Handler接收消息

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

三、Looper源码分析

public static final void loop() {        Looper me = myLooper();          MessageQueue queue = me.mQueue;          // 开始了死循环        while (true) {              Message msg = queue.next(); // 无消息或者等待时会阻塞            if (msg != null) {                if (msg.target == null) {                      return;                  }                  if (me.mLogging!= null){     　　　　　　　   me.mLogging.println(   ">>>>> Dispatching to " + msg.target + " "    + msg.callback + ": " + msg.what   );      　　　　　　  }                msg.target.dispatchMessage(msg);  //target为msg对应的handler                if (me.mLogging!= null) {    　　　　　　　    me.mLogging.println(    "<<<<< Finished to    " + msg.target + " "   + msg.callback);      　　　　　　  }                msg.recycle();              }        }    }

Looper的loop()方法死循环读取MessageQueue的消息，然后交给Handler处理，msg.target.dispatchMessage(msg);  //target为msg对应的handler。

四、MessageQueue源码分析

MessageQueue中最重要的就是两个方法：

1.enqueueMessage向队列中插入消息 2.next 从队列中取出消息

enqueueMessage代码分析：

boolean enqueueMessage(Message msg, long when) {        if (msg.target == null) {//msg.target就是发送此消息的Handler            throw new IllegalArgumentException("Message must have a target.");        }        if (msg.isInUse()) {//表示此消息正在被使用            throw new IllegalStateException(msg + " This message is already in use.");        }        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;//将延迟时间封装到msg内部            Message p = mMessages;//消息队列的第一个元素            boolean needWake;            if (p == null || when == 0 || when < p.when) {               //如果此队列中头部元素是null(空的队列，一般是第一次)，或者此消息不是延时的消息，则此消息需要被立即处理，此时会将这个消息作为新的头部元素，并将此消息的next指向旧的头部元素，然后判断如果Looper获取消息的线程如果是阻塞状态则唤醒它，让它立刻去拿消息处理                          msg.next = p;                mMessages = msg;                needWake = mBlocked;            } else {                //如果此消息是延时的消息，则将其添加到队列中，原理就是链表的添加新元素，按照when，也就是延迟的时间来插入的，延迟的时间越长，越靠后，这样就得到一条有序的延时消息链表，取出消息的时候，延迟时间越小的，就被先获取了。插入延时消息不需要唤醒Looper线程。                  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;            }            // We can assume mPtr != 0 because mQuitting is false.            if (needWake) {//唤醒线程                nativeWake(mPtr);            }        }        return true;    }

源码中主要的地方我给了注释，可以参考参考。

由此可以看出： MessageQueue中enqueueMessage方法的目的有两个： 1.插入消息到消息队列 2.唤醒Looper中等待的线程(如果是及时消息并且线程是阻塞状态) 同时我们知道了MessageQueue的底层数据结构是单向链表，MessageQueue中的成员变量mMessages指向的就是该链表的头部元素。

接下来我们再来分析一下取出消息的方法next()：

next()方法代码比较多，下面是主要部分

Message next() {            final long ptr = mPtr;        if (ptr == 0) {           //从注释可以看出，只有looper被放弃的时候（调用了quit方法）才返回null，mPtr是MessageQueue的一个long型成员变量，关联的是一个在C++层的MessageQueue，阻塞操作就是通过底层的这个MessageQueue来操作的；当队列被放弃的时候其变为0。            return null;        }        int pendingIdleHandlerCount = -1; // -1 only during first iteration        int nextPollTimeoutMillis = 0;        for (;;) {            if (nextPollTimeoutMillis != 0) {                Binder.flushPendingCommands();            }            //阻塞方法，主要是通过native层的epoll监听文件描述符的写入事件来实现的。           //如果nextPollTimeoutMillis=-1，一直阻塞不会超时。           //如果nextPollTimeoutMillis=0，不会阻塞，立即返回。           //如果nextPollTimeoutMillis>0，最长阻塞nextPollTimeoutMillis毫秒(超时)，如果期间有程序唤醒会立即返回。            nativePollOnce(ptr, nextPollTimeoutMillis);            synchronized (this) {                           final long now = SystemClock.uptimeMillis();                Message prevMsg = null;                Message msg = mMessages;                if (msg != null && msg.target == null) {                    //msg.target == null表示此消息为消息屏障（通过postSyncBarrier方法发送来的）                    //如果发现了一个消息屏障，会循环找出第一个异步消息（如果有异步消息的话），所有同步消息都将忽略（平常发送的一般都是同步消息）                    do {                        prevMsg = msg;                        msg = msg.next;                    } while (msg != null && !msg.isAsynchronous());                }                if (msg != null) {                    if (now < msg.when) {                        // 如果消息此刻还没有到时间，设置一下阻塞时间nextPollTimeoutMillis，进入下次循环的时候会调用nativePollOnce(ptr, nextPollTimeoutMillis)进行阻塞；                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);                    } else {                        //正常取出消息                        //设置mBlocked = false代表目前没有阻塞                        mBlocked = false;                        if (prevMsg != null) {                            prevMsg.next = msg.next;                        } else {                            mMessages = msg.next;                        }                        msg.next = null;                        msg.markInUse();                        return msg;                    }                } else {                    //没有消息，会一直阻塞，直到被唤醒                    nextPollTimeoutMillis = -1;                }                if (mQuitting) {                    dispose();                    return null;                }            pendingIdleHandlerCount = 0;            nextPollTimeoutMillis = 0;        }    }

由此可以看出：

1.当首次进入或所有消息队列已经处理完成，由于此刻队列中没有消息（mMessages为null），这时nextPollTimeoutMillis = -1 ，然后会处理一些不紧急的任务（IdleHandler），之后线程会一直阻塞，直到被主动唤醒（插入消息后根据消息类型决定是否需要唤醒）。 2.读取列表中的消息，如果发现消息屏障，则跳过后面的同步消息。 3.如果拿到的消息还没有到时间，则重新赋值nextPollTimeoutMillis = 延时的时间，线程会阻塞，直到时间到后自动唤醒 4.如果消息是及时消息或延时消息的时间到了，则会返回此消息给looper处理。

通过enqueueMessage和next两个方法的分析我们不难得出：

消息的入列和出列是一个生产-消费者模式，Looper.loop()在一个线程中调用next()不断的取出消息，另外一个线程则通过enqueueMessage向队列中插入消息，所以在这两个方法中使用了synchronized (this) {}同步机制，其中this为MessageQueue对象，不管在哪个线程，这个对象都是同一个，因为Handler中的mQueue指向的是Looper中的mQueue，这样防止了多个线程对同一个队列的同时操作。

五、HandlerThread源码分析

1、HandlerThread继承Thread

public class HandlerThread extends Thread {    int mPriority;    int mTid = -1;    Looper mLooper;    private @Nullable Handler mHandler;    public HandlerThread(String name) {        super(name);        mPriority = Process.THREAD_PRIORITY_DEFAULT;    }}

2、使用Looper

@Overridepublic void run() {    mTid = Process.myTid();    Looper.prepare();//初始化Looper    synchronized (this) {        mLooper = Looper.myLooper();        notifyAll();    }    Process.setThreadPriority(mPriority);    onLooperPrepared();    Looper.loop();//Loop循环    mTid = -1;}

六、ActivityThread源码分析

ActivityThread即Android的主线程，也就是UI线程，ActivityThread的main方法是一个APP的真正入口，MainLooper在它的main方法中被创建。

public static void main(String[] args) {        ...        Looper.prepareMainLooper();        ActivityThread thread = new ActivityThread();        thread.attach(false);        if (sMainThreadHandler == null) {            sMainThreadHandler = thread.getHandler();//主线程Handler        }        if (false) {            Looper.myLooper().setMessageLogging(new                    LogPrinter(Log.DEBUG, "ActivityThread"));        }        // End of event ActivityThreadMain.        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);        Looper.loop();//启动Looper        throw new RuntimeException("Main thread loop unexpectedly exited");    }

首先 ActivityThread 并不是一个 Thread，就只是一个 final 类而已。我们常说的主线程就是从这个类的 main 方法开始，main 方法很简短，一眼就能看全（如上），我们看到里面有 Looper 了，那么接下来就找找 ActivityThread 对应的 Handler 啊，就是内部类 H，其继承 Handler，贴出 handleMessage 的小部分：

public void handleMessage(Message msg) {            if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));            switch (msg.what) {                case LAUNCH_ACTIVITY: {                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");                    final ActivityClientRecord r = (ActivityClientRecord) msg.obj;                    r.packageInfo = getPackageInfoNoCheck( r.activityInfo.applicationInfo, r.compatInfo);                    handleLaunchActivity(r, null);                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                } break;                case RELAUNCH_ACTIVITY: {                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityRestart");                    ActivityClientRecord r = (ActivityClientRecord)msg.obj;                    handleRelaunchActivity(r);                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                } break;                case PAUSE_ACTIVITY:                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityPause");                    handlePauseActivity((IBinder)msg.obj, false, (msg.arg1&1) != 0, msg.arg2, (msg.arg1&2) != 0);                    maybeSnapshot();                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                    break;                case PAUSE_ACTIVITY_FINISHING:                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityPause");                    handlePauseActivity((IBinder)msg.obj, true, (msg.arg1&1) != 0, msg.arg2, (msg.arg1&1) != 0);                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                    break;                case STOP_ACTIVITY_SHOW:                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStop");                    handleStopActivity((IBinder)msg.obj, true, msg.arg2);                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                    break;                case STOP_ACTIVITY_HIDE:                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStop");                    handleStopActivity((IBinder)msg.obj, false, msg.arg2);                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                    break;                case SHOW_WINDOW:                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityShowWindow");                    handleWindowVisibility((IBinder)msg.obj, true);                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                    break;                case HIDE_WINDOW:                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityHideWindow");                    handleWindowVisibility((IBinder)msg.obj, false);                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                    break;                case RESUME_ACTIVITY:                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityResume");                    handleResumeActivity((IBinder) msg.obj, true, msg.arg1 != 0, true);                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                    break;                case SEND_RESULT:                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityDeliverResult");                    handleSendResult((ResultData)msg.obj);                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);                    break;            ...........}

如果你了解下linux的epoll你就知道为什么不会被卡住了，先说结论：阻塞是有的，但是不会卡住 

主要原因有2个

(1)epoll模型 

当没有消息的时候会epoll.wait，等待句柄写的时候再唤醒，这个时候其实是阻塞的。所有的ui操作都通过handler来发消息操作。 (MessageQueue源码里面有调用的native方法即为epoll模型)

(2)比如屏幕刷新16ms一个消息，你的各种点击事件，所以就会有句柄写操作，唤醒上文的wait操作，所以不会被卡死了。

七、Handler、Thread、HandlerThread区别

Handler：发送Message消息，接收Message回调消息，实现跨线程通信的操作者。

Thread：线程；进程中执行运算的最小单位，亦即执行处理机调度的基本单位。

HandlerThread：Thread+Looper；具有Looper功能的线程。相对于ActivityThread主线程而言，HandlerThread为子线程。

Handler的目标是解决子线程与主线程通信的问题，而HandlerThread则是解决子线程与子线程的通讯问题。

转载地址：http://osxab.baihongyu.com/