深入了解Handler消息机制（一）

在Android开发了一段时间之后，很多读者应该知道了一个知识点：UI不能在子线程中更新。这本来是一个伪命题，因为并不是UI不可以在子线程中更新，而是UI不可以在不是它创建的线程中更新。只是绝大多数情况下UI都是从UI线程中创建的，因此在其他线程更新时会抛出异常。在这种情况下，当我们在子线程中完成了耗时操作之后，通常会通过一个Handler将结果传递给UI线程，然后在UI线程中更新相关的视图。

那么Handler,Looper的工作原理又是什么呢？它们之间是如何协作的？

在此之前我们需要了解两个概念，即MessageQueue和Message。其实Android应用是事件驱动的，每个事件都会转化为一个系统消息，及Message。消息中包含了事件相关的信息以及这个事件的处理人–Handler。每个线程中都会有一个默认的MessageQueue。这个消息队列维护了一个待处理的消息列表，有一个消息循环不断地从这个队列中取出消息，处理消息，这样就使得应用动态的运作起来。他们的运作原理就像工厂的生产线一样，待加工的产品就是Message，“传送带”就是MessageQueue，电动机就是Looper，工人们就对应于处理事件的Handler。这么一来Message就必然会产生很多的对象，因为整个应用都是由事件驱动的，即Message来驱动的，系统需要不断的产生Message，处理Message，销毁Message，难道Android没有IOS流畅就是这个原因吗？答案显然不是的。

在Message文档中有：

/*
* <p class="note">While the constructor of Message is public, the best way to get
* one of these is to call {@link #obtain Message.obtain()} or one of the
* {@link Handler#obtainMessage Handler.obtainMessage()} methods, which will pull
* them from a pool of recycled objects.</p>
*/

意思很清楚，是建议我们在使用Message的obtain方法获取Message对象，而不是通过Message的构造函数，因为obtain方法会从被回收的对象池中获取Message对象。

下面看看obtain方法：

// sometimes we store linked lists of these things
/*package*/ Message next;
private static Message sPool;
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();
}

看到上面的代码，是不是有些熟悉。对，就是链表。这个next指向的下一个Message的。每个Message对象都有一个同类型的next字段。这样一来所有的可用的Message对象就通过next串联成一个可用的Message池。在obtain方法中，首先会声明一个Message对象m，并且让m指向sPool。sPool实际上指向了m1，因此，m实际上也指向了m1，这里相当于保存了m1这个元素。下一步就是sPool指向m1的下一个元素，也就是m2。sPool完成后移就会把m.next赋值为null， 此时再把链表中的元素的个数减1，这样链表中的第一个元素就成功的脱离了原来的消息池队伍了。

但是那些Message对象什么时候被放到链表中的呢?我们在obtain方法中只看到了从链表中获取，没有看到将Message对象放进对象池的代码，那么到底线索在哪呢？

不知道注意到上面的注释的最后一句话：

which will pull them from a pool of recycled objects

相信大家也都明白了，原来在创建的时候是不会把Message对象放在池中的，在回收该对象时才会将该对象添加到链表中。其实Message类中有类似于Bitmap那样的recycle函数，具体代码如下：

void recycleUnchecked() {
// Mark the message as in use while it remains in the recycled object pool.
// Clear out all other details.
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = -1;
when = 0;
target = null;
callback = null;
data = null;

synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}
public void recycle() {
//判断该消息是否还在被使用
if (isInUse()) {
if (gCheckRecycle) {
throw new IllegalStateException("This message cannot be recycled because it "
+ "is still in use.");
}
return;
}
//清空状态并将添加到消息池中
recycleUnchecked();
}

recycle函数会将一个Message对象回收到一个全局的池中，这个池也就是上文说到的链表。recycle函数首先判断该消息是否还在使用，如果还在使用就会抛出异常，否则调用recycleUnchecked函数处理该消息。recycleUnchecked函数中先清空该消息的各个字段，并且将flags设置为FLAG_IN_USE,表明该消息已经被使用，这个flag在obtain函数中会被设置为0，这样就能够追踪该消息的状态。然后判断是否要将该消息回收到消息池中，如果池的大小小于最大SIZE，则将自身添加到表头。当我们调用obtain方法的时候，如果池中有元素的话就会从池中获取表中的第一个元素。

现在已经很明朗了，Message通过在内部构建一个链表来维护一个被回收的Message对象的对象池，当用户调用obtain函数时会优先从池中获取，如果池中没有可以复用的对象则可以创建这个新的Message对象。这个新创建的Message对象在被使用完之后会被回收到这个对象池中，当下次再调用obtain函数时它们就会被复用。