Android 消息处理机制（Looper、Handler、MessageQueue,Message）

Android 消息处理机制

1.Android消息处理机制：

消息处理机制本质：一个线程开启循环模式持续监听并依次处理其他线程给它发的消息。

简单的说：一个线程开启一个无限循环模式，不断遍历自己的消息列表，如果有消息就
挨个拿出来做处理，如果列表没消息，自己就堵塞（相当于wait，让出cpu资源给其他
线程），其他线程如果想让该线程做什么事，就往该线程
的消息队列插入消息，该线程会不断从队列里拿出消息做处理。

---

2.Looper、Handler、MessageQueue,Message作用和存在的意义：

(1)Looper

我们知道一个线程是一段可执行的代码，当可执行代码执行完成后，线程生命周期便会
终止，线程就会退出，那么做为App的主线程，如果代码段执行完了会怎样？，那么就
会出现App启动后执行一段代码后就自动退出了，这是很不合理的。所以为了防止代码段
被执行完，只能在代码中插入一个死循环，那么代码就不会被执行完，然后
自动退出，怎么在在代码中插入一个死循环呢？那么Looper出现了，在主
线程中调用Looper.prepare()...Looper.loop()就会把当前线程变
成Looper线程（可以先简单理解：无限循环不退出的线
程），Looper.loop()方法里面有一段死循环的代码，所以主线程会进入
while(true){...}的代码段跳不出来，但是主线程也不能什么都不做
吧？其实所有做的事情都在while(true){...}里面做了，主线程会在死
循环中不断等其他线程给它发消息（消息包括：Activity启动，生命周
期，更新UI，控件事件等），一有消息就根据消息做相应的处理，Looper
的另外一部分工作就是在循环代码中会不断从消息队列挨个拿出消息给主线程处理。

(2)MessageQueue

MessageQueue 存在的原因很简单，就是同一线程在同一时间只能处理一
个消息，同一线程代码执行是不具有并发性，所以需要队列来保存消息和安
排每个消息的处理顺序。多个其他线程往UI线程发送消息，UI线程必须把
这些消息保持到一个列表（它同一时间不能处理那么多任务),然后挨个拿出
来处理，这种设计很简单，我们平时写代码其实也经常这么做。每一个
Looper线程都会维护这样一个队列，而且仅此一个，这个队列的消息只能
由该线程处理。

(3)Handler

简单说Handler用于同一个进程的线程间通信。Looper让主线程无限循环
地从自己的MessageQueue拿出消息处理，既然这样我们就知道处理消息肯
定是在主线程中处理的，那么怎样在其他的线程往主线程的队列里放入消息
呢？其实很简单，我们知道在同一进程中线程和线程之间资源是共享的，也
就是对于任何变量在任何线程都是可以访问和修改的，只要考虑并发性做好
同步就行了，那么只要拿到MessageQueue 的实例，就可以往主线程的
MessageQueue放入消息，主线程在轮询的时候就会在主线程处理这个消
息。那么怎么拿到主线程 MessageQueue的实例，是可以拿到的(在主线程下

mLooper = Looper.myLooper();mQueue = mLooper.mQueue;),
但是Google 为了统一添加消息和消息的回调处理，又专门构建了
Handler类，你只要在主线程构建Handler类，那么这个Handler实例就
获取主线程MessageQueue实例的引用（获取方式mLooper = 
Looper.myLooper();mQueue = mLooper.mQueue;），Handler 在
sendMessage的时候就通过这个引用往消息队列里插入新消息。
Handler 的另外一个作用，就是能统一处理消息的回调。这样一个
Handler发出消息又确保消息处理也是自己来做，这样的设计非常的赞。具
体做法就是在队列里面的Message持有Handler的引用（哪个handler 把
它放到队列里，message就持有了这个handler的引用），然后等到主线
程轮询到这个message的时候，就来回调我们经常重写的Handler的
handleMessage(Message msg)方法。



(4)Message

Message 很简单了，你想让主线程做什么事，总要告诉它吧，总要传递点数据给它吧，Message就是这个载体。

---

源码解析：

1.Looper ：

public final class Looper {
    // sThreadLocal 是static的变量，可以先简单理解它相当于map，key是线程，value是Looper，
    //那么你只要用当前的线程就能通过sThreadLocal获取当前线程所属的Looper。
    static final ThreadLocal sThreadLocal = new ThreadLocal();
    //主线程（UI线程）的Looper 单独处理，是static类型的，通过下面的方法getMainLooper() 
    //可以方便的获取主线程的Looper。
    private static Looper sMainLooper; 

    //Looper 所属的线程的消息队列
    final MessageQueue mQueue;
    //Looper 所属的线程
    final Thread mThread;

    public static void prepare() {
        prepare(true);
    }

    private static void prepare(boolean quitAllowed) {
         //如果线程的TLS已有数据，则会抛出异常，一个线程只能有一个Looper，prepare不能重复调用。
        if (sThreadLocal.get() != null) {
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        //往线程的TLS插入数据，简单理解相当于map.put(Thread.currentThread(),new Looper(quitAllowed));
        sThreadLocal.set(new Looper(quitAllowed));
    }

    //实际上是调用  prepare(false)，并然后给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();
        }
    }
    //static 方法，方便获取主线程的Looper.
    public static Looper getMainLooper() {
        synchronized (Looper.class) {
            return sMainLooper;
        }
    }

    public static @Nullable Looper myLooper() {
        //具体看ThreadLocal类的源码的get方法，
        //简单理解相当于map.get(Thread.currentThread()) 获取当前线程的Looper
        return sThreadLocal.get();
    }
}

---

注:看之前先稍微了解下ThreadLocal是什么？
ThreadLocal： 线程本地存储区（Thread Local Storage，简称为TLS），每个线程都有自己的私有的本地存储区域，不同线程之间彼此不能访问对方的TLS区域。这里线程自己的本地存储区域存放是线程自己的Looper。具体看下ThreadLocal.java 的源码！

---

    看了上面的代码（仔细看下注释），我们发现 Looper.prepareMainLooper()做的事件就是new了一个Looper实例并放入Looper类下面一个static的ThreadLocal sThreadLocal静态变量中，同时给sMainLooper赋值,给sMainLooper赋值是为了方便通过Looper.getMainLooper()快速获取主线程的Looper，sMainLooper是主线程的Looper可能获取会比较频繁，避免每次都到 sThreadLocal 去查找获取。

Looper的构造函数：

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

这时候给当前线程创建了消息队列MessageQueue，并且让Looper持有MessageQueue的引用。执行完Looper.prepareMainLooper() 之后，主线程从普通线程转成一个Looper线程。目前的主线程线程已经有一个Looper对象和一个消息队列mQueue

prepare()方法：

    public static final void prepare() {  
            if (sThreadLocal.get() != null) {  
                throw new RuntimeException("Only one Looper may be created per thread");  
            }  
            sThreadLocal.set(new Looper(true));  
    }  

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

loop()方法：

public static void loop() {
    final Looper me = myLooper();  //获取TLS存储的Looper对象,获取当前线程的Looper 
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }

    final MessageQueue queue = me.mQueue;  //获取Looper对象中的消息队列
    ....

    for (;;) { //主线程开启无限循环模式
        Message msg = queue.next(); //获取队列中的下一条消息，可能会线程阻塞
        if (msg == null) { //没有消息，则退出循环，退出消息循环，那么你的程序也就可以退出了
            return;
        }
        ....
        //分发Message，msg.target 是一个Handler对象，哪个Handler把这个Message发到队列里，
        //这个Message会持有这个Handler的引用，并放到自己的target变量中,这样就可以回调我们重写
        //的handler的handleMessage方法。
        msg.target.dispatchMessage(msg);
        ....
        ....
        msg.recycleUnchecked();  //将Message回收到消息池,下次要用的时候不需要重新创建，obtain()就可以了。
    }
}

         loop()方法，不断从MessageQueue中去取消息，交给消息的target属性的dispatchMessage去处理。

public static Looper myLooper() {
return sThreadLocal.get();
}
方法直接返回了sThreadLocal存储的Looper实例，如果me为null则抛出异常，也就是说looper方法必须在prepare方法之后运行



   问题：
     1、UI线程一直在这个循环里跳不出来，主线程不会因为Looper.loop()里的死循环卡死吗，那还怎么执行其他的操作呢？

在looper启动后，主线程上执行的任何代码都是被looper从消息队列里取出来执行的。也就是说主线程之后都是通过其他线程给它发消息来实现执行其他操作的。生命周期的回调也是如此的，系统服务ActivityManagerService通过Binder发送IPC调用给APP进程，App进程接到到调用后，通过App进程的Binder线程给主线程的消息队列插入一条消息来实现的。

2、主线程是UI线程和用户交互的线程，优先级应该很高，主线程的死循环一直运行是不是会特别消耗CPU资源吗？App进程的其他线程怎么办？

这基本是一个类似生产者消费者的模型，简单说如果在主线程的MessageQueue没有消息时，就会阻塞在loop的queue.next()方法里，这时候主线程会释放CPU资源进入休眠状态，直到有下个消息进来时候就会唤醒主线程，在2.2 版本以前，这套机制是用我们熟悉的线程的wait和notify 来实现的，之后的版本涉及到Linux pipe/epoll机制，通过往pipe管道写端写入数据来唤醒主线程工作。原理类似于I/O,读写是堵塞的，不占用CPU资源。

---

2.Handler

 public Handler() {
        this(null, false);
 }
 public Handler(Callback callback, boolean async) {
        //不是static 发出可能内存泄露的警告！
        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());
            }
        }
        //获取当前线程的Looper，还记得前面讲过 Looper.myLooper()方法了吗？
        //Looper.myLooper()内部实现可以先简单理解成：map.get(Thread.currentThread()) 
        //获取当前线程的Looper
        mLooper = Looper.myLooper();
        if (mLooper == null) {
            //当前线程不是Looper 线程，没有调用Looper.prepare()给线程创建Looper对象
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
        //让Handler 持有当前线程消息队列的引用
        mQueue = mLooper.mQueue;
        //这些callback先不管，主要用于handler的消息发送的回调，优先级是比handlerMessage高，但是不常用
        mCallback = callback;
        mAsynchronous = async;
    }

---

通过Looper.myLooper()获取了当前线程保存的Looper实例，然后在19行又获取了这个Looper实例中保存的MessageQueue（消息队列），这样就保证了handler的实例与我们Looper实例中MessageQueue关联上了。

---

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

辗转反则最后调用了sendMessageAtTime，在此方法内部有直接获取MessageQueue然后调用了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，【如果大家还记得Looper的loop方法会取出每个msg然后交给msg,target.dispatchMessage(msg)去处理消息】，也就是把当前的handler作为msg的target属性。最终会调用queue的enqueueMessage的方法，也就是说handler发出的消息，最终会保存到消息队列中去。


现在已经很清楚了Looper会调用prepare()和loop()方法，在当前执行的线程中保存一个Looper实例，这个实例会保存一个MessageQueue对象，然后当前线程进入一个无限循环中去，不断从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方法

/** 
   * Subclasses must implement this to receive messages. 
   */  
  public void handleMessage(Message msg) {  
  }  

可以看到这是一个空方法，为什么呢，因为消息的最终回调是由我们控制的，我们在创建handler的时候都是复写handleMessage方法，然后根据msg.what进行消息处理。

例如：

    private Handler mHandler = new Handler()  
        {  
            public void handleMessage(android.os.Message msg)  
            {  
                switch (msg.what)  
                {  
                case value:  

                    break;  

                default:  
                    break;  
                }  
            };  
        };  

---

1、首先Looper.prepare()在本线程中保存一个Looper实例，然后该实例中保存一个MessageQueue对象；因为Looper.prepare()在一个线程中只能调用一次，所以MessageQueue在一个线程中只会存在一个。

2、Looper.loop()会让当前线程进入一个无限循环，不端从MessageQueue的实例中读取消息，然后回调msg.target.dispatchMessage(msg)方法。

3、Handler的构造方法，会首先得到当前线程中保存的Looper实例，进而与Looper实例中的MessageQueue想关联。

4、Handler的sendMessage方法，会给msg的target赋值为handler自身，然后加入MessageQueue中。

5、在构造Handler实例时，我们会重写handleMessage方法，也就是msg.target.dispatchMessage(msg)最终调用的方法。

好了，总结完成，大家可能还会问，那么在Activity中，我们并没有显示的调用Looper.prepare()和Looper.loop()方法，为啥Handler可以成功创建呢，这是因为在Activity的启动代码中，已经在当前UI线程调用了Looper.prepare()和Looper.loop()方法。