前言
Handler在Android开发中经常使用，比我我们在子线程中完成从服务端获取数据，因为Android系统是不允许我们在非主线程中去访问UI，这个时候我们需要用Handler把更新UI的操作切换到主线程中去操作。这里有一个误区就是很多开发者以为Handler只能用于访问UI，这是错误的，因为更新UI这是Handler的一种特殊的使用场景。其实Handler是用于进行Message Runnable的分发，让他们在指定的线程中去执行。
为什么Android系统不允许在非主线程（UI线程）外更新UI
在ViewRootImp类中做了UI检查，如果不是UI线程抛出的这个异常我想很多开发人员都遇到过吧。
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
Android的UI控件都不是线程安全的，如果允许其它线程更新UI，那么可能出现多线程并发的操作UI,那么会导致UI控件处于不可预期的状态。有的人会说那为什么系统不对UI控件的访问加上锁机制呢？这样做其实得不偿失，因为加上锁机制会让UI控件的逻辑变得复杂，还有加上锁机制会降低UI控件的访问效率。最简单高效的方式就是只允许一个线程也就是主线程才能访问UI。
概述
Android 的消息机制主要就是指Handler的运行机制，Handler的运行是需要Looper 和MessageQueue的支撑，其中MessageQueue是消息队列，负责存储消息列表，虽然它是一个队列的结构，但是它的底层实现却是单链表。Looper是负责不断的从消息队列中取出消息，发送到消息对象的Handler对象去处理。稍后我将会讲解Looper是怎么实现不断的从消息队列中取出消息的。
源码分析
首先我们对Looper进行源码分析，在实际开发中如果我们在子线程中创建Hander的时候都会遇到这样一个错误，
java.lang.RuntimeException: Can't create handler inside thread Thread[Thread-2,5,main] that has not called Looper.prepare()
那么我们先来分析一下Looper的prepare()，loop()方法中进行了什么操作。先分析prepare()方法
/** Initialize the current thread as a looper.
* This gives you a chance to create handlers that then reference
* this looper, before actually starting the loop. Be sure to call
* {@link #loop()} after calling this method, and end it by calling
* {@link #quit()}.
*/
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));
}
从代码中我们看到new 了一个Looper()对象，并且存在在sThreadLocal中，而这个sThreadLocal对象是一个ThreadLocal的实例对象。在new Looper对象之前先判断了sThreadLocal中.get()是否为空，如果不为空，那么就抛出throw new RuntimeException("Only one Looper may be created per thread");这样的错误。对于这个错误我相信很多开发者都遇到过。
这样判断的目的在于保证一个线程中只有一个Looper对象。接下来我们再看看Looper类的构造方法
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
在构造方法中我们发现初始化了我们之前一直说的消息队列也就是MessageQueue的实例，
接下来我们分析一下Looper类中的loop()方法
/**
* Run the message queue in this thread. Be sure to call
* {@link #quit()} to end the 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 slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
final long traceTag = me.mTraceTag;
if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
final long start = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
final long end;
try {
msg.target.dispatchMessage(msg);
end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
if (slowDispatchThresholdMs > 0) {
final long time = end - start;
if (time > slowDispatchThresholdMs) {
Slog.w(TAG, "Dispatch took " + time + "ms on "
+ Thread.currentThread().getName() + ", h=" +
msg.target + " cb=" + msg.callback + " msg=" + msg.what);
}
}
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方法中首先调用myLooper()方法
/**
* Return the Looper object associated with the current thread. Returns
* null if the calling thread is not associated with a Looper.
*/
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
方法中首先从sThreadLocal获取存储的当前线程的Looper对象，如果Looper对象为空，
就会抛出throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
这样一个异常信息。我相信不少开发人员都遇到过这个错误。这也就是我们为什么在调用loop方法之前必须先调用prepare()方法来初始化Looper对象。
在获取到了当前线程对应的Looper对象之后，在第11行代码从Looper对象中获取当前Looper的消息队列对象，然后进入我们之前提到无限循环中，在第14行不断的从消息队列中取出消息，如果没有消息，那么将进入阻塞状态。
当获取到消息，那么需要分发消息，那Looper是如何分发消息的呢？请看第27行代码
msg.target.dispatchMessage(msg);
这句代码是调用了message对象的target对象的dispachMessage(msg)来进行消息的分发。
这个message的target其实就是Handler。在后面我们分析Handler类中将会讲解。
Handler源码分析
Handler的工作主要是发送消息，接收消息，发送消息是通过一系列的send() post()方法来实现的。对于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();
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;
}
从这里我们看到Looper.myLooper()这个方法，看到是不是感觉有点熟悉，没错，就在之前我们分析Looper中的loop()方法的时候也遇到了这个方法，这个方法是获取线程对应的Loop er对象。如果获取到的Looper对象为空，那么将会抛出throw new RuntimeException("Can't create handler inside thread that has not called Looper.prepare()");这个异常，我相信也有人在子线程中new Handler对象的时候遇到过这个错误。
也许有人会问，为什么我们在主线程中初始化Handler的时候也没有调用Looper.prepare()方法，但是却没有报错呢？虽然线程默认是没有Looper的，但是我们的UI线程也就是(ActivityThread) 在被创建的时候就会初始化Looper。所以这就是为什么我们在主线程中创建Handler没有调用Looper.prepare()方法却没有报错的原因。
在上面的第19行，我们通过获取到的Looper对象获取的对应的消息队列。这样，我们就把Handler Looper MessageQueue联系在一起了。
现在是时候来讲解之前提到的msg.target.dispatchMessage(msg);说的target对象了，我之前说这个target对象就是Handler，为什么这样说呢？请看Handler发送消息的源码
public final boolean sendMessage(Message msg)
{
return sendMessageDelayed(msg, 0);
}
public final boolean sendEmptyMessage(int what)
{
return sendEmptyMessageDelayed(what, 0);
}
public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
Message msg = Message.obtain();
msg.what = what;
return sendMessageDelayed(msg, 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（）这个方法。我们接着看enqueueMessage()方法
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
第一行代码就设置msg对象的target对象为this，也即是发送消息的Handler对象。那么我们看Handler类的dispatchMessage(msg)方法。
/**
* Handle system messages here.
*/
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
这里我们可以看到首先判断msg的callBack对象是否为空，如果不为空调用handleCallback()方法，这个接下来分析，我们现在先看看handleMessage(msg)这个方法，我们看一下这个这个方法，
/**
* Subclasses must implement this to receive messages.
*/
public void handleMessage(Message msg) {
}
发现这个方法是个空方法，源码注释里面说的很清楚，这个是用来子类实现改方法用来接受消息，这也是为什么我么使用Handler的时候都会从写handleMessage(Message msg)的原因了。
接下来我们分析一下在dispatchMessage(Message msg)方法中提到的handleCallback(msg)这个方法
private static void handleCallback(Message message) {
message.callback.run();
}
我们发现是直接调用callback的run()方法，说明这个callback对象是一个Runnable对象
我们来验证一下我们的结论是否正确。
public final boolean post(Runnable r)
{
return sendMessageDelayed(getPostMessage(r), 0);
}
post(Runnable r)方法我们经常使用，我们分析一下getPostMessage(r)这个方法
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}
这里我们发现首先创建一个Message对象，这里创建Message对象看起来有点怪，其实Message内部维护了一个Message池用于Message的复用，避免使用new 重新分配内存
所以建议我们平时在使用的尽量使用Message.obtain()来获取一个Message对象。
这里我们发现是吧Runnable赋值给message的callback了。看来上面我们推理的是没有错的。
总结
- 首先Looper.prepare()在本线程中保存一个Looper实例，然后该实例中保存一个MessageQueue对象；因为Looper.prepare()在一个线程中只能调用一次，所以MessageQueue在一个线程中只会存在一个
- Looper.loop()会让当前线程进入一个无限循环，不断的从MessageQueue的实例中读取消息，如果没有消息，则会阻塞，然后回调msg.target.dispatchMessage(msg)方法
- Handler的构造方法，会首先得到当前线程中保存的Looper实例，从而实现与Looper实例中的MessageQueue的关联。
- Handler的sendMessage方法，会给msg的target赋值为Handler自身，然后加入MessageQueue中。
- 在构造Handler实例时，我们会重写handleMessage方法，也就是msg.target.dispatchMessage(msg)最终调用的方法。
建议
我们在使用Handler的时候很多开发人员喜欢直接在Activity中这样初始化
private Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
这样写法是错误的，是不行的，因为这样写可能导致内存泄漏。因为我们都知到非静态内部类是持有外部类的引用，这就是为什么我们可以在非静态内部类中访问外部类的变量，方法的原因，如果我们在退出Activity的时候Handler的消息队列中的消息不为空，会处理消息，这个Activity是无法销毁的，也就造成了内存泄漏。所以我们使用的时候可以采取下面这种写法
public static class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
}
如果需要在handleMessage()方法中使用当前的Activity，那么可以采用在Handler内部持有Activity的弱引用例如下面这样：
public static class MyHandler extends Handler {
private WeakReference<MainActivity> reference;
public MyHandler(MainActivity activity) {
this.reference = new WeakReference<>(activity);
}
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
}
