很早之前就Handler的分析，不过感觉有点乱乱的，所以趁着有时间就将其改了改。
Handler是我们android开发中经常使用的一个类，一般我们在子线程中做了耗时操作后使用handler来发送一个消息到主线程中去刷新UI，因为Android要求UI的刷新必须在主线程中来执行，所以使用handler来实现我们的目的是非常方便的。我们一般会使用handler来做刷新UI的操作，但是handler提供的功能可不仅仅只是在UI线程中来处理，它也可以子线程中处理消息。说起Handler一般都会和Looper、Message、MessageQueue联系起来，Looper是一个循环器不停的从MessageQueue中Message息交给Handler来处理。
我们一般使用的时候就是直接new Handler()然后覆写handleMessage()方法就可以在主线程中处理任务了。为什么没有看到Looper和MessageQueue的身影了，如果我们在子线程中去new Handler()会发生什么情况呢？
下面我们从源码的角度来看看handler是怎么工作的。
我们知道，Android应用启动的入口在ActivityThread这个类，里面就能看到看到我们在学习java的时候main函数的身影，在main方法中，会自动在线程中初始化Looper，所以我们在主线程中去new Handler()的时候是不需要关心这个的，因为已经帮我们做好了。我们先来看看main方法中到底做了什么：
public static void main(String[] args) {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
...//不相关的内容
//初始化Looper
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
...
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
//开启循环，此处looper来陷入一个死循环中不停的取出消息并处理，一旦looper停止，那么我们的应用也就结束
Looper.loop();
//looper停止的话就会走到这里抛出异常
throw new RuntimeException("Main thread loop unexpectedly exited");
}
在一进入main方法中就调用了Looper.prepareMainLooper()这个方法，然后就调用了Looper.loop()方法，我们接着跳进去看看里面做了什么
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
public static void prepareMainLooper() {
//创建一个主线程使用的looper
prepare(false);
synchronized (Looper.class) {
//如果已经存在了main looper抛出异常
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
//保存主线程中的looper
sMainLooper = myLooper();
}
}
private static void prepare(boolean quitAllowed) {
//如果重复创建抛出异常
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
//使用threadLocal来保存looper对象，该looper对象只能被主线程访问
sThreadLocal.set(new Looper(quitAllowed));
}
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
看到Looper里面也没有神秘的东西，还是挺简单的，Looper里面使用了一个ThreadLocal，它能够提供线程独立的数据，线程之间使用ThreadLocal保存的数据互不干扰，对于不清楚ThreadLocal的可以参考ThreadLocal源码分析
可以看到prepareMainLooper只是创建了一个looper对象跟主线程关联起来。
public static void loop() {
//当前线程为主线程，所以取到的looper就是一个主线程中的looper
final Looper me = myLooper();
if (me == null) {
//这里告诉我们，如果在子线程中使用looper的话，不调用Looper.prepare()是会gg的，看到这个异常是不是很熟悉啊
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
//在Looper的构造方法中就会初始化一个MeesageQueue对象，就一行代码，这里就不贴了
final MessageQueue queue = me.mQueue;
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) {
//如果MeesageQueue没有消息，这里会阻塞等待知道有消息过来
Message msg = queue.next(); // might block
if (msg == null) {
//如果这里为null，说明MessageQueue停止运行了，也就不能处理主线程的逻辑了，程序就退出了
return;
}
final Printer logging = me.mLogging;
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中取出Handler对象，然后调用handler.dispatchMessage()方法
//在handler发送消息的时候，会将自己也封装在message中，所以这里我们才能处理消息
msg.target.dispatchMessage(msg);
end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
...
msg.recycleUnchecked();
}
}
在looper中我们看到了一个神奇的东西for (;;)，一个死循环，在该死循环中不停的取出message消息，如果没有消息MessageQueue就阻塞。有些小伙伴可能会惊讶，这里阻塞了那主线程的其他地方怎么执行啊？可以告诉你，在应用实际运行中，处理ActivityThread.main()中在Looper.loop()之前，其他主线程的代码都是在这个死循环中执行的，一样这个循环退出，应用也就结束了，我们也看到Looper.loop()是在main()方法的最后才调用的就是这么一个道理。
在loop()方法中做的事情很简单，就是不停的取消息然后交给handler来处理，如果没有消息了就阻塞等待直到有消息为止。
Looper的初始化就这么简单。我们接下来看看Handler中有什么，经常用它们也不能不知道它里面到底有啥。
我们先从sendMessage()这里说起，它是我们发消息的出发点。
//sendEmptyMessage
public final boolean sendEmptyMessage(int what)
{
return sendEmptyMessageDelayed(what, 0);
}
//sendEmptyMessageDelayed
public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
Message msg = Message.obtain();
msg.what = what;
return sendMessageDelayed(msg, delayMillis);
}
//sendEmptyMessageAtTime
public final boolean sendEmptyMessageAtTime(int what, long uptimeMillis) {
Message msg = Message.obtain();
msg.what = what;
return sendMessageAtTime(msg, uptimeMillis);
}
//sendMessage
public final boolean sendMessage(Message msg){
return sendMessageDelayed(msg, 0);
}
//sendMessageDelayed
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
//sendMessageAtTime
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);
}
//sendMessageAtFrontOfQueue
public final boolean sendMessageAtFrontOfQueue(Message msg) {
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, 0);
}
handler里面封装了好几种发送消息的方法，但是最终它们调用enqueueMessage()，所以我们来看看它里面到底是怎么实现的
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
//将handler本身赋值给target
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
//将消息添加到队列
return queue.enqueueMessage(msg, uptimeMillis);
}
这里先将handler本身赋值给msg.target，然后调用queue.enqueueMessage将消息添加到消息队列里面。这也就是为什么在looper的死循环里面从消息中取出handler的原因，要是这里不设置我们的handler，消息是不能在我们自己的handler中处理的。其中queue是handler在构造方法中初始化的时候从主线程的looper中拿到的
public Handler(Looper looper, Callback callback, boolean async) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
到这里，是不是感觉整个Handler的流程一下就顿悟了很多。
我们接着上面的说，在looper中最终会调用我们的handler的dispatchMessage()方法，来看看：
public void dispatchMessage(Message msg) {
//如果有msg中有callback，那么在callback中处理消息
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
//如果我们在创建handler的时候设置了callback，那么也在这个callback中处理消息
//这个callback和msg.callback不是一个东西，不要搞混了
if (mCallback.handleMessage(msg)) {
//如果消息处理成功就退出
return;
}
}
//如果以上都没有处理或者是mCallback返回false，那么调用handleMessage()来处理
handleMessage(msg);
}
}
看到了啥，handleMessage()竟然是在这里被调用的，一下子又哦哦哦了。
不过发现handleMessage()是最好才被处理的。那前面几个callback是什么呢？
先说msg.callback()，除了handler提供了几个sendxxxMessage()方法外，还提供了几个post方法来发送消息。
public final boolean post(Runnable r){
return sendMessageDelayed(getPostMessage(r), 0);
}
public final boolean postAtTime(Runnable r, long uptimeMillis){
return sendMessageAtTime(getPostMessage(r), uptimeMillis);
}
public final boolean postAtTime(Runnable r, Object token, long uptimeMillis){
return sendMessageAtTime(getPostMessage(r, token), uptimeMillis);
}
public final boolean postDelayed(Runnable r, long delayMillis){
return sendMessageDelayed(getPostMessage(r), delayMillis);
}
public final boolean postAtFrontOfQueue(Runnable r){
return sendMessageAtFrontOfQueue(getPostMessage(r));
}
竟然还是调用了我们的send方法来发送消息，简直了就是。不过这里的message好像有点不一样，看看这里做了什么。
private static Message getPostMessage(Runnable r, Object token) {
Message m = Message.obtain();
m.obj = token;
m.callback = r;
return m;
}
看到了啥，msg.callback就是我们在post中传递的runnable对象，这里还有一个重载方法getPostMessage(Runnable r)，它们处理token不一样，其他都一样就不说了。我们知道了msg.callback就是一个Runnable，那就看看在handleCallback(msg)中做了什么。
private static void handleCallback(Message message) {
message.callback.run();
}
好吧，就是这么简单。
再说mCallback，它是我们在创建Handler的时候在构造方法中传递的参数。不过这个callback也没有啥，除了有一个返回值的变化。
public interface Callback {
public boolean handleMessage(Message msg);
}
到此Handler的源码分析就结束了。
网友评论