1. 前言
在之前的图解Handler原理最后留下了几个课后题，如果还没看过那篇文章的，建议先看那篇文章，课后题如下：
- Android中，有哪些是基于Handler来实现通信的？
- 处理Handler消息，是在哪个线程？一定是创建Handler的线程么？
- 消息是如何插入到MessageQueue中的？
- 当MessageQueue没有消息时，它的next方法是阻塞的，会导致App ANR么？
- 子线程中可以使用Toast么？
- Looper.loop()是死循环，可以停止么？
- Handler内存泄露怎么解决？
2. Android中基于Handler的实现
我们来看看Android中Handler机制的应用，可能比你想象的要多，举例只是说明Handler的重要性。
2.1 保证App的运行
之前，我们说到，App的入口其实是ActivityThread的main方法，下面是这个方法省略版
public static void main(String[] args) {
// 创建主线程中的Looper
Looper.prepareMainLooper();
// 创建ActivityThread对象
ActivityThread thread = new ActivityThread();
thread.attach(false);
if (sMainThreadHandler == null) {
// 创建用于通信的Handler
sMainThreadHandler = thread.getHandler();
}
// 执行loop方法
Looper.loop();
}
可以看到这个main方法中，主要有如下几步：
- 创建了主线程中的Looper，创建Looper时，会创建一个MessageQueue用于存放消息。
- 创建了ActivityThread对象，并调用了它的attach方法，这个方法就是去创建Application、调用Application的onCreate方法以及告诉ActivityManagerService现在App启动了。
- 创建了用于通信的Handler，它是一个H对象。
- 调用Looper.loop方法，开始循环从主线程中的MessageQueue中取出消息来处理。
我们回顾下，Handler机制的原理图。
可以知道，App启动后，因为Looper.loop是一个死循环，导致main方法一直没有执行完，也就是说，我们后续App中的所有操作，都是发生在Looper.loop中的。
那Handler机制，是怎么保证App的运行的呢？我们来看看ActivityThread中用于通信的Handler的定义。
private class H extends Handler {
public static final int LAUNCH_ACTIVITY = 100;
public static final int PAUSE_ACTIVITY = 101;
public static final int PAUSE_ACTIVITY_FINISHING= 102;
public static final int STOP_ACTIVITY_SHOW = 103;
public static final int STOP_ACTIVITY_HIDE = 104;
// 省略部分代码
String codeToString(int code) {
if (DEBUG_MESSAGES) {
switch (code) {
case LAUNCH_ACTIVITY: return "LAUNCH_ACTIVITY";
case PAUSE_ACTIVITY: return "PAUSE_ACTIVITY";
case PAUSE_ACTIVITY_FINISHING: return "PAUSE_ACTIVITY_FINISHING";
case STOP_ACTIVITY_SHOW: return "STOP_ACTIVITY_SHOW";
case STOP_ACTIVITY_HIDE: return "STOP_ACTIVITY_HIDE";
// 省略部分代码
}
}
return Integer.toString(code);
}
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;
// 省略部分代码
}
if (DEBUG_MESSAGES) Slog.v(TAG, "<<< done: " + codeToString(msg.what));
}
通过代码可以看到，H继承于Handler，定义了很多消息的类型，比如启动Activity、停止Activity、显示Window、电量过低等，它重写了handleMessage方法，用于处理这些消息。
那发消息是在哪里发的呢？我们以锁屏调用Activity的onStop生命周期为例，其实就是在ApplicationThread中，它是一个ActivityThread的内部类我们拿启动Activity这个消息举例，ActivityManagerService会先通过binder调用ApplicationThread中的scheduleStopActivity方法（牵涉到进程间通信，不懂可以略过），这个方法是在我们App的Bindler线程池中执行的，那看看它是怎么切换到主线程去启动Activity的。
public final void scheduleStopActivity(IBinder token, boolean showWindow,
int configChanges) {
sendMessage(
showWindow ? H.STOP_ACTIVITY_SHOW : H.STOP_ACTIVITY_HIDE,
token, 0, configChanges);
}
我们看到，这里就是调用sendMessage方法，第一个参数，不就是上面H中定义的消息类型么？接着看 sendMessage方法，它最后会调用到如下这个多参的构造方法：
private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) {
if (DEBUG_MESSAGES) Slog.v(
TAG, "SCHEDULE " + what + " " + mH.codeToString(what)
+ ": " + arg1 + " / " + obj);
Message msg = Message.obtain();
msg.what = what;
msg.obj = obj;
msg.arg1 = arg1;
msg.arg2 = arg2;
if (async) {
msg.setAsynchronous(true);
}
mH.sendMessage(msg);
}
可以看到，就是使用mH发送一个消息，而mH就是ActivityThread中定义的类型为H的成员变量，定义如下：
final H mH = new H();
所以，调用锁屏时，调用Activity的onStop方法，流程如下：
- ActivityManagerService通过binder方式，调用ApplicationThread的scheduleStopActivity方法
- ApplicationThread的scheduleStopActivity方法，通过H把消息加入到主线线程的MessageQueue中
- 主线程的Looper遍历MessageQueue，取到该消息时，调用H的handleMessage方法进行处理
- 在H的handleMessage中，调用Activity的onStop方法
流程图如下：
那么，我们App运行原理就出来了，App的运行依赖于Handler机制，当主线程当MessageQueue有消息时，主线程的Looper.loop会不断从主线程中的MessageQueue中取出消息来处理（比如Activity的onCreate其实就是属于对MessageQueue中取出的一个消息的处理），这样就保证了App运行
当MessageQueue没有消息时，MessageQueue的next方法会阻赛，导致当前线程挂起，等有消息（一般为系统进程通过binder调用App的ApplicationThread中的方法，注意，方法在binder线程池中执行，然后ApplicationThread使用ActivityThread中的H对象发送消息，加入消息到主线程的MessageQueue中，当发现主线程被挂起了，则会唤醒主线程）
所以，当没有任何消息时，我们的App的主线程，是属于挂起的状态。有消息来时（锁屏、点击等），主线程会被唤醒，所以说，Handler机制保证了App的运行。
2.2 Handler更新UI
我们知道，如果在子线程直接更新UI会抛出异常，异常如下：
我们可以使用Handler在子线程中更新UI，常用的方式有如下几种：
- Handler的sendMessage方式
- Handler的post方式
- Activity的runOnUiThread方法
- View的post方式
2.2.1 Handler的sendMessage
final Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
btn.setText("handler.sendMessage方式");
}
};
new Thread(new Runnable() {
@Override
public void run() {
// 使用sendMessage方式
Message msg = Message.obtain();
msg.what = 100;
handler.sendMessage(msg);
}
}).start();
这种方式，我们在上一篇文章中介绍过，就是在子线程中，用主线程中创建的hander调用sendMessage发送消息，把Message加入到主线程的MessageQueue中，等主线程的Looper从MessageQueue中取到这个消息时，会调用这个Message的target的handleMessage方法，这个target其实就是我们发消息用到的handler，也就是调用了我们重写的handleMessage方法。
发消息：Handler.sendMessage(Message)
处理消息：Message.target.handleMessage(其中target就是发消息的handler)
2.2.2 Handler的post方法
final Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
btn.setText("handler.sendMessage方式");
}
};
new Thread(new Runnable() {
@Override
public void run() {
// 使用post
handler.post(new Runnable() {
@Override
public void run() {
btn.setText("handler.post方式");
}
});
}
}).start();
在子线程中使用handler的post方法，也是可以更新UI的，post方法需要传入一个Runnalbe对象。我们来看看post方法源码
public final boolean post(Runnable r)
{
return sendMessageDelayed(getPostMessage(r), 0);
}
可以看到，先调用了getPostMessage构建了一个Message对象，然后调用了sendMessageDelayed方法，前面知道，sendMessage也是调用的这个方法，所以我们只要关注怎么构建的Message对象，看getPostMessage方法。
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
// post方法传入的Runnable对象作为Message的callback
m.callback = r;
return m;
}
其实很简单，就是把post方法传入的参数作为Message的callback来创建一个Message。
我们再来回顾一下从MessageQueue中取出消息来对消息对处理，方法是Handler对dispatchMessage方法
public void dispatchMessage(Message msg) {
// callback其实就是post方法传入对Runnable对象
if (msg.callback != null) {
handleCallback(msg);
} else {
// 不会执行到这里
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
private static void handleCallback(Message message) {
// 相当于调用了post方法传入对Runnable对象对run方法
message.callback.run();
}
可以知道，我们使用post发送消息，就是使用传入对Runnable对象封装成一个Message，然后加入到主线程中的MessageQueue，等主线程的Looper取出该消息处理时，因为Message.callback不为空，而调用其run方法，也就是我们调用post方法传入的Runnable对象的run方法，且不会调用Hander的handleMessage方法。
发送消息：Handler.post(Runnable)
处理消息：Message.callback.run(callback为调用post方法传入的Runnable)
2.2.3 Activity的runOnUiThread方法
new Thread(new Runnable() {
@Override
public void run() {
activity.runOnUiThread(new Runnable() {
@Override
public void run() {
btn.setText("Activity的runOnUiThread方法");
}
});
}
}).start();
我们如果能在子线程中获取到Activity对象，是可以调用其runOnUiThread方法，来更新UI。我们来看看Activity的runOnUiThread源码。
public final void runOnUiThread(Runnable action) {
// 如果不是UI线程，则调用Handler的post
if (Thread.currentThread() != mUiThread) {
mHandler.post(action);
} else {
// 如果是ui线程，则直接回调Runnable的run方法
action.run();
}
}
如果是UI线程，就直接调用了传入的Runnable对象的run方法，我们主要是看非UI线程的逻辑。
如果不是UI线程，则直接使用mHandler的post方法，看来Activity的runOnUiThread方法也是基于Handler的post方法来实现的，后面的逻辑就是把传入的Runnable封装成Message发送出去，上面讲过了，就不再复述了。
我们再看看这个mHandler的定义，其实就是Activity的成员属性
final Handler mHandler = new Handler();
Activity是在主线程创建的，所以这个Handler也是在主线程中创建的，且持有的Looper为主线程的Looper。那么使用这个Handler调用post方法发出的消息，是加入到主线程的MessageQueue中，这样就完成了子线程跟主线程的通信。
发送消息：Activity. runOnUiThread(Runnable)
处理消息：Message.callback.run(callback为runOnUiThread方法传入的Runnable)
2.2.4 View的post方法
new Thread(new Runnable() {
@Override
public void run() {
// 调用View的post方法
btn.post(new Runnable() {
@Override
public void run() {
btn.setText("View.post方式");
}
});
}
}).start();
我们直接看View的post方法
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
// Assume that post will succeed later
ViewRootImpl.getRunQueue().post(action);
return true;
}
可以看到这里也是调用的Handler的post方法，跟Activity. runOnUiThread类似。
发送消息：View.post(Runnable)
处理消息：Message.callback.run(callback为post方法传入的Runnable对象)
总结一下：
- Handler.sendMessage: 把消息加入到主线程的MessageQueue中，主线程中的Looper从MessageQueue中取出消息，调用Message.target.handleMessage方法
- Handler.post: 基于Handler.sendMessage，把消息加入到主线程的MessageQueue中，主线程中的Looper从MessageQueue中取出消息，调用Message.callback.run方法
- Activity.runOnUiThread: 基于Handler.post
- View.post: 基于Handler.post
所以，以上子线程更新主线程UI的所有方式，都是依赖于Handler机制。
2.3 AsyncTask
当我们想在子线程中做耗时任务时，会考虑使用AsyncTask，我们来举个栗子，在子线程中去创建自定义的MyAsyncTask并执行它，在doInBackground中去模拟耗时操作，
public class AsyncTaskActivity extends AppCompatActivity {
private static final String TAG = "AsyncTaskActivity";
private Button btn;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_asynctask);
btn = (Button) findViewById(R.id.btn);
// 开启一个子线程，去执行异步任务
new Thread(new Runnable() {
@Override
public void run() {
Log.e(TAG, "run, thread name:" + Thread.currentThread().getName());
MyAsyncTask asyncTask = new MyAsyncTask();
asyncTask.execute();
}
}).start();
}
// 自定义AsyncTask，并重写相关方法，并打印执行所在线程
class MyAsyncTask extends AsyncTask<Void, Integer, Void>{
@Override
protected Void doInBackground(Void... voids) {
Log.e(TAG, "doInBackground, thread name:" + Thread.currentThread().getName());
// 模拟耗时任务
for (int i = 0; i < 5; i ++) {
SystemClock.sleep(1000);
publishProgress(i);
}
return null;
}
@Override
protected void onPreExecute() {
Log.e(TAG, "onPreExecute, thread name:" + Thread.currentThread().getName());
}
@Override
protected void onPostExecute(Void aVoid) {
Log.e(TAG, "onPostExecute, thread name:" + Thread.currentThread().getName());
btn.setText("执行完了！");
}
@Override
protected void onProgressUpdate(Integer... values) {
super.onProgressUpdate(values);
Log.e(TAG, "onProgressUpdate, thread name:" + Thread.currentThread().getName());
}
}
}
可以看到，我们创建的子线程名为Thread-4,而AsyncTask的方法所在线程如下：
- onPreExecute: Thread-4，其实就是调用AsyncTask的execute方法的线程
- doInBackground: AsyncTask #1，这其实是AsyncTask的线程池中的一个线程
- onProgressUpdate: main，即主线程
- onPostExecute: main，即主线程
关于onPreExecute，这很好实现，不需要切换线程，直接回调就可以；而doInBackground方法的执行，可以直接取AsyncTask维持的线程池来执行就可以。我们重点关注onProgressUpdate和onPostExecute方法，是怎么从子线程切换到主线程的。
我们从AsyncTask的源码中可以看到这样一个内部类
private static class InternalHandler extends Handler {
public InternalHandler() {
// 使用主线程的Looper去创建Handler
super(Looper.getMainLooper());
}
@SuppressWarnings({"unchecked", "RawUseOfParameterizedType"})
@Override
public void handleMessage(Message msg) {
AsyncTaskResult<?> result = (AsyncTaskResult<?>) msg.obj;
switch (msg.what) {
case MESSAGE_POST_RESULT:
// finish中主要调用onPostExecute
result.mTask.finish(result.mData[0]);
break;
case MESSAGE_POST_PROGRESS:
// 调用onProgressUpdate
result.mTask.onProgressUpdate(result.mData);
break;
}
}
}
从handleMessage方法看到，这里切换到主线程，也是使用的Handler机制来实现的，但是为什么我们不管在任何线程创建的AsyncTask去执行，最后都可以在主线程去回调这两个方法呢？主要是创建InternalHandler时，使用的是主线程的Looper，这样使用这个InternalHandler发送消息时，消息就会加入到主线程Looper对应的MessageQueue中，所以主线程Looper取出消息处理时，InternalHandler的handleMessage方法就是在主线程中回调的了。
所以AsyncTask其实就是基于线程池+Handler机制来实现的。
2.4 其他使用Handler的地方
- RxJava: 子线程切换到主线程执行观察者的回调方法
- Glide：图片准备好以后的回显
- LocalBroadcastManager: 传统的广播是基于binder实现的，本地广播LocalBroadcastManager是基于Handler实现的
其实还有很多使用到handler机制的地方，就不一一举例了，反正记住，Handler机制很重要。
3. 处理消息的线程
以前总觉得，处理消息的线程，就是创建Handler的线程，但是上一篇文章的分析，我们知道这样说其实是不准确的（因为我们创建Handler通常使用的默认Looper）。
处理消息的线程，其实是发送handler所持有的Looper所在的线程。
其实原理很好理解，我们知道Handler的原理如图
所以，消息的处理分发所在线程完全取决于消息所在MessageQueue的线程，如果想要在某个线程中处理消息，只要做到把消息加入到那个线程所对应的MessageQueue中。
就像上面讲到AsyncTask的例子，就算我们在子线程创建了AsyncTask（即在子线程创建了用于通信的Handler），但只要我们创建Handler的时候，通过Looper.getMainLooper()传入主线程的Looper ，那么消息就加入到了主线程所对应的MessageQueue中，消息就是在主线程中处理的。
如下，我们在子线程中创建一个handler，然后在主线程发送消息，因为创建handler使用的是子线程中的Looper，所以消息是在主线程中处理的。代码如下：
public class ThreadActivity extends AppCompatActivity {
private static final String TAG = "ThreadActivity";
private Button btn;
private Handler mHandler;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_refresh);
btn = (Button) findViewById(R.id.btn);
// 开启一个子线程，去创建Handler
new Thread(new Runnable() {
@Override
public void run() {
Log.e(TAG, "run: , thread name: " + Thread.currentThread().getName());
Looper.prepare();
mHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
Log.e(TAG, "handleMessage, thread name: " + Thread.currentThread().getName());
}
};
Looper.loop();
}
}).start();
btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
// 发送一个消息
mHandler.sendEmptyMessage(100);
}
});
}
}
log输出，可以看出，处理消息是在子线程中。
按照之前的说法，如果我们想在主线程中处理消息，只要把消息加入到主线程的MessageQueue中，所以我们可以创建Looper时，传入主线程的Looper，代码如下：
public class ThreadActivity extends AppCompatActivity {
private static final String TAG = "ThreadActivity";
private Button btn;
private Handler mHandler;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_refresh);
btn = (Button) findViewById(R.id.btn);
// 开启一个子线程，去创建Handler
new Thread(new Runnable() {
@Override
public void run() {
Log.e(TAG, "run: , thread name: " + Thread.currentThread().getName());
Looper.prepare();
// 创建Handler传入主线程的Looper
mHandler = new Handler(Looper.getMainLooper()){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
Log.e(TAG, "handleMessage, thread name: " + Thread.currentThread().getName());
}
};
Looper.loop();
}
}).start();
btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
// 发送一个消息
mHandler.sendEmptyMessage(100);
}
});
}
}
可以看到，创建Handler使用了主线程的Looper后，的确消息是在主线程中处理的了。
4. 是如何插入到MessageQueue中
我们之前说，所有handler.post和handler.sendMessage都会调用到Handler的sendMessageDelayed方法，方法如下：
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
这里逻辑就很简单了，直接调用了sendMessageAtTime方法，第一个参数为Message，第二个参数为SystemClock.uptimeMillis() + delayMillis，其中delayMillis为延时的时间，单位为毫秒，SystemClock.uptimeMillis() 为开机到现在的时间(不包括休眠时间)，单位为毫秒。第二个参数主要是决定该Message在MessageQueue的顺序，比如现在开机时间为100s，发送一个延时20s的消息，则两者之和为120s; 过了5秒，又发了一个延时5s的消息，则两者只喝为105+5 = 110s。
sendMessageAtTime最后会调用到MessageQueue的enqueueMessage方法，我们来看看这个方法。
boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
// when = 开机到目前的时间 + 延时时间
msg.when = when;
Message p = mMessages;
boolean needWake;
// 如果当前消息队列为空或者当前when小于队头when
// 则把消息插入到队头
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
// 死循环，根据when寻找Message插入到MessageQueue合适的位置
for (;;) {
prev = p;
p = p.next;
// MessageQueue中依次往后找到第一个Message.when大于当前Message.when的Message
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
// 把当前Message插入到MessageQueue的合适位置
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
// 如果需要唤醒，则调用nativeWake去唤醒处理线程
nativeWake(mPtr);
}
}
return true;
}
从上面的代码，可以很容易看出，Message在MessageQueue中是根据when从小到大来排队的，when是开机到现在的时间+延时时间。
比如，我们假设开机时间为100s，此时MessageQueue没有消息，这时候发一个延时20s的消息，即when为120000，则MessageQueue中的消息情况如图
过了5s，我们又发了一个延时10s的消息，则when为115000，此时MessageQueue如图：
又过了5s，我们发了一个不延时的消息，即when为110000，此时MessageQueue如图：
所以，Message在MessageQueue中是根据when从小到大来排队的，when是开机到现在的时间+延时时间。
5. MessageQueue的next会造成App的ANR么
我们知道Activity如果5s的事件都不能相应用户的请求，则会ANR。我们在来回顾下Looper.loop方法：
public static void loop() {
final Looper me = myLooper();
// 取到当前线程的MessageQueue
final MessageQueue queue = me.mQueue;
// 死循环
for (;;) {
// 调用MessageQueue.next，从队列中取出消息
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
// 对消息对分发
msg.target.dispatchMessage(msg);
// 省略无关代码
}
}
在前面讲过Looper.loop方法维持了App的运行，它是里面使用了一个死循环，我们App平常的操作（Activity的生命周期、点击事件等）都是属于调用了 msg.target.dispatchMessage(msg)对消息的处理。但是如果MessageQueue中没有消息时，MessageQueue的next方法会阻塞，那它会导致App对ANR么？
我们来看看MessageQueue的next方法
Message next() {
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
// 死循环
for (;;) {
// 阻塞MessageQueue
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// 如果是延时消息，则算出需要阻塞的时间nextPollTimeoutMillis
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// 如果不是延时显示，则直接把消息返回，以供处理
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
// 没有消息时，设置nextPollTimeoutMillis为-1，阻塞MessageQueue
nextPollTimeoutMillis = -1;
}
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
// 一般都会满足if条件，然后mBlocked设置为true，继续continue
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
// 省略无关代码
}
pendingIdleHandlerCount = 0;
nextPollTimeoutMillis = 0;
}
}
next方法中，首先设置一个死循环，然后调用nativePollOnce(ptr, nextPollTimeoutMillis)方法，它是一个native方法，用于阻塞MessageQueue，主要是关注它的第二个参数nextPollTimeoutMillis，有如下三种可能：
- 如果nextPollTimeoutMillis=-1，一直阻塞不会超时。
- 如果nextPollTimeoutMillis=0，不会阻塞，立即返回。
- 如果nextPollTimeoutMillis>0，最长阻塞nextPollTimeoutMillis毫秒(超时)，如果其间有程序唤醒会立即返回。
我们先继续往下看，开始nextPollTimeoutMillis为0，也就是不会阻塞，则继续往下，这时候有三种情况
- 延时消息，则直接算出目前需要延时的时间nextPollTimeoutMillis，注意，这时候并没有把消息返回，而是继续往下，设置mBlocked为true，表示消息队列已阻塞，并continue执行for循环体，再次执行nativePollOnce方法，这时候nextPollTimeoutMillis>0，则会导致MessageQueue休眠nextPollTimeoutMillis毫秒，接着应该会走到情况2.
- 不是延时消息，则设置mBlocked为false，表示消息队列没有阻塞，直接把消息返回，且把消息出队。
- 如果消息为空，则调用位置nextPollTimeoutMillis为-1，继续往下，设置mBlocked为true，表示消息队列已阻塞，并continue继续for循环，这时候调用nativePollOnce会一直阻塞，且不会超时。
所以，当消息队列为空时，其实是调用本地方法nativePollOnce，且第二个参数为-1，它会导致当前线程阻塞，且不会超时，所以不会出现ANR的情况，其实这是由Linux的管道机制(pipe)来保证的，当线程阻塞时，对CPU等资源等消耗时极低的，具体的原理可以自行查阅。
那线程阻塞以后，什么时候才能再唤醒呢？记得之前我们说消息加入MessageQueue的逻辑么？我们再来回顾一下enqueueMessage的流程：
boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
// 如果MessageQueue为空
needWake = mBlocked;
} else {
// 如果MessageQueue中有消息
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;
}
// 如果需要唤醒当前线程，则调用nativeWake方法
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
其实就是使用Handler发送消息，把消息加入到MessageQueue时，会判断当前MessageQueue是否阻塞，如果阻塞了，则需要调用nativeWake方法去唤醒线程，而这个阻塞是在前面提到的MessageQueue的next方法中，MessageQueue没有消息或者消息为延时消息时设置的。
所以MessageQueue的next方法可能会阻塞线程，但不会造成ANR。
- 当MessageQueue没有消息时，next方法中调用nativePollOnce导致线程阻塞，直到有新消息加入MesssageQueue时调用nativeWake来唤醒线程
- 当MessageQueue有消息时且队头消息为延时消息时，next方法调用nativePollOnce导致线程阻塞nextPollTimeoutMillis的时间，中途有新消息加入MessageQueue时调用nativeWake可以唤醒线程，也可以等nextPollTimeoutMillis后自动唤醒线程
6. 子线程使用Toast
有时候，我们需要在子线程中直接弹出Toast来提示一些信息,代码如下
public class ToastActivity extends AppCompatActivity {
private static final String TAG = "ToastActivity";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_toast);
new Thread(new Runnable() {
@Override
public void run() {
// 子线程中弹出toast
Toast.makeText(ToastActivity.this, "提示一下！", Toast.LENGTH_LONG).show();
}
}).start();
}
}
运行程序，会发现程序会崩溃。是因为子线程不能更新UI么？其实不是不这样的。
- Toast是属于系统Window，不受子线程更新UI限制。
- onCreate方法中，子线程可能可以更新UI，因为子线程不能更新UI的检测是在ViewRootImpl的checkThread完成的，而onCreate方法中，ViewRootImpl还没有创建，所以不会去检测。
既然不是这两方面的原因，我们来看看报错的log吧
这跟我们在子线程中直接使用handler好像报的错误类似，那我们也跟使用hendler的套路一样，先调用Looper.prepare然后再调用Looper.loop呢？代码如下：
new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
// 子线程中弹出toast
Toast.makeText(ToastActivity.this, "提示一下！", Toast.LENGTH_LONG).show();
Looper.loop();
}
}).start();
发现就可以了，可以看出Toast也是需要使用Handler，我们来看看Toast的实现，直接看Toast中的一个内部类TN，它是一个IBinder实现类，我们来看它的定义：
private static class TN extends ITransientNotification.Stub {
final Runnable mShow = new Runnable() {
@Override
public void run() {
// 调用handleShow，处理显示逻辑
handleShow();
}
}
final Handler mHandler = new Handler();
// 省略无关代码
WindowManager mWM;
TN() {
// XXX This should be changed to use a Dialog, with a Theme.Toast
// defined that sets up the layout params appropriately.
final WindowManager.LayoutParams params = mParams;
params.height = WindowManager.LayoutParams.WRAP_CONTENT;
params.width = WindowManager.LayoutParams.WRAP_CONTENT;
params.format = PixelFormat.TRANSLUCENT;
params.windowAnimations = com.android.internal.R.style.Animation_Toast;
params.type = WindowManager.LayoutParams.TYPE_TOAST;
params.setTitle("Toast");
params.flags = WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON
| WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE
| WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE;
}
/**
* schedule handleShow into the right thread
*/
@Override
public void show() {
if (localLOGV) Log.v(TAG, "SHOW: " + this);
// 这里是Binder线程池，用handler切换到有Looper的线程
mHandler.post(mShow);
}
// Toast的真实显示
public void handleShow() {
if (mView != mNextView) {
mView = mNextView;
// 省略无关代码
// 把View加入到Window上
mWM.addView(mView, mParams);
}
}
//省略无关代码
}
可以看出，Toast的显示，使用了Binder通信，其实就是WindowManagerService会拿到TN对象，调用其show方法，但是这是Binder线程池中执行的，所以使用handler切换到调用Toast的show方法所在的线程去执行，这里使用的就是handler.post，所以就需要调用Toast.show方法所在线程有Looper。最后调用的就是handleShow方法，把View加载到Window上。
总结一下Handler:
- Toast是系统Window来实现的
- Toast的显示使用了IPC
- Toast的显示使用了Handler机制
- 子线程可以使用Toast，不过需要使用Handler的套路
7. Looper.loop可以停止么？
前面我们知道，loop方法中是一个死循环，又因为代码是顺序执行的，所以它之后的代码是得不到执行的，如下：
public class LooperActivity extends AppCompatActivity {
private static final String TAG = "LooperActivity";
private Button btn;
private Handler mHandler;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_looper);
btn = (Button) findViewById(R.id.btn);
// 开启一个子线程，去执行异步任务
new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
Log.e(TAG, "Looper.loop之前" );
// Looper.loop方法是一个死循环
Looper.loop();
// 得不到执行
Log.e(TAG, "Looper.loop之后" );
}
}).start();
}
}
log如图，只会打印loop方法之前的，loop之后的代码得不到执行。
这样我们就要考虑一个问题了，并不是所有线程都需要像主线程一样一直运行下去，有些线程希望做完耗时任务后能回收，但是因为Looper.loop方法，导致线程只是阻塞，随时有被唤醒的可能，不能释放。那有什么办法能停止loop方法么？
其实Looper提供了quit和quitSafely方法来停止Looper，我们先来看看quit的用法，在点击事件中调用了Looper的quit方法，修改后的代码如下
public class LooperActivity extends AppCompatActivity {
private static final String TAG = "LooperActivity";
private Button btn;
private Handler mHandler;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_looper);
btn = (Button) findViewById(R.id.btn);
// 开启一个子线程，去执行异步任务
new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
Log.e(TAG, "Looper.loop之前" );
// Looper.loop方法是一个死循环
Looper.loop();
// 得不到执行
Log.e(TAG, "Looper.loop之后" );
}
}).start();
btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
// 调用Looper的quit方法，停止Looper
mHandler.getLooper().quit();
}
});
}
}
开始和之前一样，Looper.loop后的方法不会得到执行，我们点击按钮后，Looper会停止，Looper.loop之后的代码也可以得到执行，log如下：
我们来看看Looper的quit和quitSafely的源码：
public void quit() {
mQueue.quit(false);
}
public void quitSafely() {
mQueue.quit(true);
}
我们发现，两个方法都是调用了MessageQueue的quit方法，只是传入的参数不同，我们来看看MessageQueue的quit方法：
void quit(boolean safe) {
synchronized (this) {
if (mQuitting) {
return;
}
// MessageQueue正在停止，用于next方法退出死循环
mQuitting = true;
if (safe) {
// 删除MessageQueue中的延时消息
removeAllFutureMessagesLocked();
} else {
// 删除MessageQueue中的所有消息
removeAllMessagesLocked();
}
// We can assume mPtr != 0 because mQuitting was previously false.
nativeWake(mPtr);
}
}
首先把mQuitting设置为true，主要用于MessageQueue的next方法退出死循环，然后通过safe去判断逻辑逻辑，这里就可以看出Looper的quit和quitSafely的区别了
- quit: 删除MesageQueue中所有消息
- quitSafely: 删除MessageQueue中的延时消息
我们继续看mQuitting对MessageQueue的next方法的影响，回到next方法，我们只看关键性代码：
Message next() {
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
// No more messages.
nextPollTimeoutMillis = -1;
}
// 判断mQuitting
if (mQuitting) {
dispose();
return null;
}
}
}
}
直接看最后的部分，对mQuitting做判断，我们之前在MessageQueue的quit方法中，会把这个属性设置为true，其实就是会影响到这里。满足条件以后，调用了dispose方法，并返回了null。
我们先来看dispose方法
private void dispose() {
if (mPtr != 0) {
nativeDestroy(mPtr);
mPtr = 0;
}
}
其实就是调用了nativeDestroy方法，它是一个native方法，用于在底层停止MessageQueue。
这里只是停止了MessageQueue的next中的死循环，Looper.loop方法中的死循环还是没有退出，我们继续看Looper.loop方法。
public static void loop() {
final Looper me = myLooper();
final MessageQueue queue = me.mQueue;
for (;;) {
// 当mQuitting为true，queue.next方法返回了null
Message msg = queue.next(); // might block
if (msg == null) {
// 直接return，退出loop的死循环
return;
}
// 省略无关代码
}
}
前面我们知道，当调用了Looper的quit或者quitSafely时，会设置当前线程的MessageQueue的 mQuitting为true，然后导致了MessageQueue的next返回了null，然后直接return了，退出了loop中的死循环，这样就完成了停止Looper的逻辑。
8. Handler的内存泄漏
我们通常会使用如下的方式去使用handler来通信
public class HandlerActivity extends AppCompatActivity {
private static final String TAG = "HandlerActivity";
private Handler mHandler;
private Button btn;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler);
// 匿名内部类
mHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
// 处理消息
}
};
btn = (Button) findViewById(R.id.btn);
btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
// 发送延时100s的消息
mHandler.sendEmptyMessageDelayed(100, 100 * 1000);
}
});
}
@Override
protected void onDestroy() {
super.onDestroy();
// 使用leakcanary做内存泄漏检测
RefWatcher refWatcher = MyApplication.getRefWatcher(this);
if (refWatcher != null) {
refWatcher.watch(this);
}
}
}
但是会有一个问题，我们进入这个页面然后点击按钮，发送一个延时100s的消息，再退出这个Activity，这时候可能导致内存泄漏。
根本原因是因为我们创建的匿名内部类Handler对象持有了外部类Activity的对象，我们知道，当使用handler发送消息时，会把handler作为Message的target保存到MessageQueue，由于延时了100s，所以这个Message暂时没有得到处理，这时候它们的引用关系为MessageQueue持有了Message，Message持有了Handler，Handler持有了Activity，如下图所示
当退出这个Activity时，因为Handler还持有Activity，所以gc时不能回收该Activity，导致了内存泄漏，使用LeakCanary检测，效果如下图所示：
当然，过了100s，延时消息得到了处理，Activity对象属于不可达的状态时，会被回收。
那怎么来解决Handler泄漏呢？主要有如下两种方式：
- 静态内部类+弱引用
- 移除MessageQueue中的消息
8.1 静态内部类+弱引用
我们知道，静态内部类是不会引用外部类的对象的，但是既然静态内部类对象没有持有外部类的对象，那么我们怎么去调用外部类Activity的方法呢？答案是使用弱引用。代码如下：
public class HandlerActivity extends AppCompatActivity {
private static final String TAG = "HandlerActivity";
private Handler mHandler;
private Button btn;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler);
// 创建Handler对象，把Activity对象传入
mHandler = new MyHandler(HandlerActivity.this);
btn = (Button) findViewById(R.id.btn);
btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
// 发送延时100s的消息
mHandler.sendEmptyMessageDelayed(100, 100 * 1000);
}
});
}
// 静态内部类
static class MyHandler extends Handler {
private WeakReference<Activity> activityWeakReference;
public MyHandler(Activity activity) {
activityWeakReference = new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
// 处理消息
if (activityWeakReference != null) {
Activity activity = activityWeakReference.get();
// 拿到activity对象以后，调用activity的方法
if (activity != null) {
}
}
}
}
}
首先，我们自定义了一个静态内部类MyHandler，然后创建MyHandler对象时传入当前Activity的对象，供Hander以弱应用的方式持有，这个时候Activity就被强引用和弱引用两种方式引用了，我们继续发起一个延时100s的消息，然后退出当前Activity，这个时候Activity的强引用就不存在了，只存在弱引用，gc运行时会回收掉只有弱引用的Activity，这样就不会造成内存泄漏了。
但这个延时消息还是存在于MessageQueue中，得到这个Message被取出时，还是会进行分发处理，只是这时候Activity被回收掉了，activity为null，不能再继续调用Activity的方法了。所以，其实这是Activity可以被回收了，而Handler、Message都不能被回收。
至于为什么使用弱引用而没有使用软引用，其实很简单，对比下两者回收前提条件就清楚了
- 弱引用(WeakReference): gc运行时，无论内存是否充足，只有弱引用的对象就会被回收
- 软引用(SoftReference): gc运行时，只有内存不足时，只有软引用的对象就会被回收
很明显，当我们Activity退出时，我们希望不管内存是否足够，都应该回收Activity对象，所以使用弱引用合适。
8.2 移除MessageQueue中的消息
我们知道，内存泄漏的源头是MessageQueue持有的Message持有了Handler持有了Activity，那我们在合适的地方把Message从MessageQueue中移除，不就可以解决内存泄漏了么？
Handler为我们提供了removeCallbacksAndMessages等方法用于移除消息，比如，在Activity的onDestroy中调用Handler的removeCallbacksAndMessages，代码如下：
@Override
protected void onDestroy() {
super.onDestroy();
// 移除MessageQueue中target为该mHandler的Message
mHandler.removeCallbacksAndMessages(null);
}
其实就是在Activity的onDestroy方法中调用mHandler.removeCallbacksAndMessages(null)，这样就移除了MessageQueue中target为该mHandler的Message，因为MessageQueue没有引用该Handler发送的Message了，所以当Activity退出时，Message、Handler、Activity都是可回收的了，这样就能解决内存泄漏的问题了。
9. 总结
- Android中，有哪些是基于Handler来实现通信的？
答：App的运行、更新UI、AsyncTask、Glide、RxJava等 - 处理Handler消息，是在哪个线程？一定是创建Handler的线程么？
答：创建Handler所使用的Looper所在的线程 - 消息是如何插入到MessageQueue中的？
答： 是根据when在MessageQueue中升序排序的，when=开机到现在的毫秒数+延时毫秒数 - 当MessageQueue没有消息时，它的next方法是阻塞的，会导致App ANR么？
答：不会导致App的ANR，是Linux的pipe机制保证的，阻塞时，线程挂起；需要时，唤醒线程 - 子线程中可以使用Toast么？
答：可以使用，但是Toast的显示是基于Handler实现的，所以需要先创建Looper，然后调用Looper.loop。 - Looper.loop()是死循环，可以停止么？
答：可以停止，Looper提供了quit和quitSafely方法 - Handler内存泄露怎么解决？
答： 静态内部类+弱引用 、Handler的removeCallbacksAndMessages等方法移除MessageQueue中的消息
