目录
- 一、简介
- 二、相关概念解释
- 2.1 Message（消息）
- 2.2 Handler（处理器）
- 2.2.1 Handler的构造方法
- 2.2.2 Handler sendMessage（）相关的方法
- 2.2.3 Handler dispatchMessage（）方法
- 2.3 MessageQueue（消息队列）
- 2.4 Looper（循环器）
- 三、引申问题
- 3.1 主线程的looper是如何创建的？
- 3.2 一个线程可以有几个Handler?Looper？
- 3.3 Handler线程间通信的原理是怎样的？
- 3.4 Handler的内存泄露原因？
- 3.5 为何主线程可以new Handler?如果想要在子线程中new Handler 要做什么准备？
- 3.6 子线程中维护的looper,消息队列无消息的时候的处理方案是什么？有什么用？主线程呢？
- 3.7 使用Message时如何创建?
- 3.8 handler的消息阻塞是怎么实现的？
一、简介
Handler是一套 Android 消息传递机制,主要用于线程间通信。
用最简单的话描述： handler其实就是主线程在起了一个子线程，子线程运行并生成Message，Looper获取message并传递给Handler，Handler逐个获取子线程中的Message并处理。
Binder/Socket用于进程间通信，而Handler消息机制用于同进程的线程间通信
可以说只要有异步线程与主线程通信的地方就一定会有 Handler。
在多线程的应用场景中，将工作线程中需更新UI的操作信息 传递到 UI主线程，从而实现 工作线程对UI的更新处理，最终实现异步消息的处理：
你想刷新主界面的TextView，无奈你不在主线程，此时你就会包装好Message，然后声明一个Handler，让Handler将你的Message送往主线程（Looper），Handler将你的Message送到主线程后，还需要排队等待，等轮到你的时候，主线程就会告诉Handler，这个Message可以处理了，你负责分发一下，于是，Handler将该Message分发到相应的回调或者handleMessage( ) 方法中，于是，你就在该方法中更新了UI。
二、相关概念解释
可以将Handler相关的原理机制形象的描述为以下情景：
Handler：快递员（属于某个快递公司的职员）
Message：包裹（可以放置很多东西的箱子）
MessageQueue：快递分拣中心（分拣快递的传送带）
Looper：快递公司（具有处理包裹去向的管理中心）
2.1 Message（消息）
Message.class位于android.os.包中。Message的构造函数为无参构造方法，且只有一个构造方法；
public Message() { }
除了构造方法可以创建实例对象外，还可以通过内部的静态方法来创建：
static Message obtain()
static Message obtain(Message orig)
static Message obtain(Handler h)
static Message obtain(Handler h, Runnable callback)
static Message obtain(Handler h, int what)
static Message obtain(Handler h, int what, Object obj)
static Message obtain(Handler h, int what, int arg1, int arg2)
static Message obtain(Handler h, int what, int arg1, int arg2, Object obj)
以上几个静态的方法里面都会首先调用第一个方法来创建一个Message对象，来看看源码
public static final Object sPoolSync = new Object(); //同步锁对象，用于同步访问消息池的对象。通过synchronized (sPoolSync)来确保在获取和释放消息对象时的线程安全性。
private static Message sPool; //全局的消息对象池，用于存储可重用的消息对象。
private static int sPoolSize = 0; //表示当前消息池中的消息对象数量。
/**
* 从全局池返回一个新的消息实例，允许我们在许多情况下避免分配新对象。
*/
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();
}
如果当前全局池的Message实例不为空，则返回第一个消息实例。所以，大多数情况下，使用obtain()来获得一个Message对象，可以避免消耗更多的内存资源。
对于其他 static obtain( ) 的重载方法，通过源码，可以发现，都是进行赋值操作，没有太多的可讨性。唯一得注意一下的是 obtain(Handler h, Runnable callback)这个静态方法：
/*package*/ Handler target;
/*package*/ Runnable callback;
public static Message obtain(Handler h, Runnable callback) {
Message m = obtain();
m.target = h;
m.callback = callback;
return m;
}
可以看到，也是赋值操作，target是保护级别的成员变量，即只有同包名空间可以访问，此变量意义重大。除了target，还有一个callback，这个callback也是配合着Handler来发挥作用的。
此时，需要记住的就几点：
Message有8个静态方法可以创建Message实例
Message有两个重要的成员变量，分别为target 和callback，一个是Handler，一个是Runnable。
Message有4个公开变量what、arg1、arg2、obj 可以存储消息进行传递
Message还有一个包间成员变量next，它是Message类型，后面会使用到，知道有这个next 就行
以上就是Message的基本秘密了，很简单，没有什么复杂的东西（作为一个包裹箱，就是这么简单，能装一些东西，然后附带一些关键信息）。
2.2 Handler（处理器）
Handler.class也位于android.os包中。Handler英文意思为：处理者，管理者，处理机。它在消息传递过程中扮演着重要的角色，是消息的主要处理者，说白了，就是收消息，最终处理消息（它就像一个快递员，收快递，然后领快递单，派送快递）。
2.2.1 Handler的构造方法
Handler()
Handler(Callback callback)
Handler(boolean async)
Handler(Callback callback, boolean async)
Handler(Looper looper)
Handler(Looper looper, Callback callback)
Handler(Looper looper, Callback callback, boolean async)
通过源码可以发现，上面的构造方法都是上面一个个往下调用的，第一个调用第二个，第二个调用第三个…所以，我们首先把目光放在最后一个方法上：
public Handler(Looper looper, Callback callback, boolean async) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
这是一个赋值的构造方法。再看另外一个构造方法：
public Handler(Callback callback, boolean async) {
//......
mLooper = Looper.myLooper(); //返回与当前线程关联的Looper对象，在后面Looper会讲到
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue; //返回Looper对象的消息队列，在后面MessageQueue会讲到
mCallback = callback; //接口回调
mAsynchronous = async; //是否异步
}
public interface Callback {
public boolean handleMessage(Message msg); //这个函数大家都很熟悉了，暂不细说，总之都知道是用来回调消息的
}
整个构造方法的过程中会确立以下几件事：
- 获取当前Handler实例所在线程的Looper对象：mLooper = Looper.myLooper()
- 如果Looper不为空，则获取Looper的消息队列，赋值给Handler的成员变量mQueue：mQueue = mLooper.mQueue
- 可以设置Callback 来处理消息回调：mCallback = callback
Handler是消息的处理者，但是它并不是最终处理消息的那个大佬，它有且只能有一个上级个领导，就是Looper，Handler是将消息上报给Looper（领导），然后排队等待，等Looper（领导）处理完消息了，就会通知Handler去领取消息，给Handler分配任务，Handler拿到消息后在自行往下分发，Handler只能听命与Looper（领导）。
举个实际运用中的情景
当你需要在子线程中更新主线程的UI时，你就会在当前的Activity下创建一个Handler对象，然后在它的handleMessage() 中更新UI。
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
//... 更新UI
}
};
在你创建这个mHandler 实例的时候，底层做了以下几件事情：
1、拿到mHandler所在线程的Looper，当前mHandler是在Activity中创建的，很明显，当前的线程就是主线程，所以 mHandler的成员变量mLooper = Looper.myLooper()，此处就已经将当前的主线程Looper赋值过去了。
2、紧接着，判断mLooper 是否为空，明显不为空，所以又会将主线程的消息队列赋值给mQueue。告诉Handler，你要是有消息，就送到这个消息队列中来，我（Looper）会一个个按顺序处理，处理完后我就会告诉你，你再处理。
由此我们可以得出结论
1、Handler有且只能绑定一个线程的Looper
2、Handler的消息是发送给Looper的消息队列MessageQueue，需要等待处理
所以，如果你在子线程中声明了一个Handler，是不能直接更新UI的，需要调用Handler相关的构造方法，传入主线程的Looper，这样创建的Handler实例，你才能进行UI的更新操作。另外的，需要注意的是，子线程默认是没有开启专属的Looper，所以，在子线程中创建Handler之前，你必须先开启子线程的Looper，否则就会爆出异常，然后GG。从上面贴出的构造方法中的部分就可以知道：
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
以上就是创建Handler的过程，有了Handler实例了，怎样传递消息呢？
2.2.2 Handler sendMessage（）相关的方法
首先上一幅图来表明sendXXXMessageXXX（）的相互调用关系：
可以看出，当我们调用Handler进行发送消息时，最终都会调用sendMessageAtTime（）方法，最后调用enqueueMessage( ) 发送到消息队列。
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQueue; //获得当前的消息队列
if (queue == null) { //若是在创建Handler时没有指定Looper，就不会有对应的消息队列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);
}
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this; //这个target就是前面我们说到过的
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
- msg.target = this
在发送消息到消息队列之前，明确的指定了消息的target为当前的Handler，以便于在后面Looper分发消息时用到。- queue.enqueueMessage(msg, uptimeMillis)
然后调用了消息队列的enqueueMessage（）方法，并传递了两个参数，一个Message，一个是long型的时间。
以上就是Handler的创建和发送消息的过程。
2.2.3 Handler dispatchMessage（）方法
前面说了消息的发送，交给Looper等待处理，处理完后会重新通知Handler处理，那么，是怎样通知Handler处理消息的呢？秘密就在dispatchMessage（）这个方法中：
/**
* 在这里处理系统消息
*/
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
/**
* 子类必须实现这个来接收消息
*/
public void handleMessage(Message msg) {
}
当Looper处理完Message后，会使用到Message的target，即上面说到的target，即发送消息的那个Handler，Looper会调用Handler的dispatchMessage（）方法分发消息，所以前面在enqueueMessage（）发送消息的时候，为什么非得指明Message的target就是这个道理。
回到dispatchMessage（）这个方法：
1、首先会判断Message的callback是否为空，此处的callback就是前面我们在Message中说到的，在静态方法创建Message时，可以指定的callback，若不为空，则将结果回调到callback中；
2、若Handler的mCallback 不为空，也一样的道理。
3、平时我们都没有传入这个callback，而是直接实现handleMessage（）这个方法，在这个方法中处理更新UI任务。
以上就是Handler发送和接收消息的基本过程：把消息发送到队列—>然后喝茶等待—>接收消息—>分发消息—>在回调中处理。
2.3 MessageQueue（消息队列）
前面我们知道，Handler发送消息会调用MessageQueue的enqueueMessage（）方法，直接上源码
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) { //判断msg的所属Handler
throw new IllegalArgumentException("Message must have a target.");
}
//......
synchronized (this) { //因为是队列，有先后之分，所以用了同步机制
//......
msg.when = when;
Message p = mMessages; //对列中排在最后的那个Message
//......
if (p == null || when == 0 || when < p.when) {
//若队列为空，或者等待时间为0，或者比前面那位的等待时间要短，就插队
msg.next = p; //此处的next就是前面我们在Message提到的，指向队列的下一个结点
mMessages = msg;
//......
} else {
//......
Message prev;
for (;;) {
//此处for循环是为了取出一个空的或者when比当前Message长的一个消息，然后进行插入
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
//......
}
msg.next = p; // 置换插入
prev.next = msg; // 置换插入
}
//......
}
return true;
}
以上就是消息队列插入消息的过程原理，通过链表的数据结构来存储消息。既然有了插入消息的方法供Handler插入消息，那么应该有对应的取出消息的方法，供Looper 调用取出消息处理，它就是Message next()这个方法，代码就不贴了，自行前往查看，过程还是挺简单的。
2.4 Looper（循环器）
Looper在Handler机制中扮演着关键的一环，他是循环处理消息的发动机，永不停息（永动鸡），它不断的从消息队列中取出的消息，处理，然后分发处理事件。每个线程都可以且只能绑定一个Looper。主线程之所以能处理消息，也是因为在APP启动时，在ActivityThread中的main（）方法中就已经启动了Looper循环。
下面直接上Looper关键方法loop( )的源码
public static void loop() {
final Looper me = myLooper(); //获得当前的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) {
// 如果消息为空，则跳过，继续执行下一个message
return;
}
//......
try {
msg.target.dispatchMessage(msg);
//......
} finally {
//......
}
//......
msg.recycleUnchecked(); //回收可能正在使用的消息
}
}
由此可见，Looper的处理消息的循环还是挺简单的，就是拿出消息，然后分发，然后回收 … …
综上所述，Handler机制可以简述为
Handler将Message发送到Looper的消息队列中，即MessageQueue，等待Looper的循环读取Message，处理Message，然后调用Message的target，即附属的Handler的dispatchMessage（）方法，将该消息回调到handleMessage（）方法中，然后完成更新UI操作。
三、引申问题
3.1 主线程的looper是如何创建的？
创建主线程时，会自动调用ActivityThread的1个静态的main（）；
而main（）内则会调用Looper.prepareMainLooper()为主线程生成1个Looper对象，同时也会生成其对应的MessageQueue对象。为进程中的管理进行初始化。
ActivityThread.java
public static void main(String[] args) {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
// Install selective syscall interception
AndroidOs.install();
// CloseGuard defaults to true and can be quite spammy. We
// disable it here, but selectively enable it later (via
// StrictMode) on debug builds, but using DropBox, not logs.
CloseGuard.setEnabled(false);
Environment.initForCurrentUser();
// Make sure TrustedCertificateStore looks in the right place for CA certificates
final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId());
TrustedCertificateStore.setDefaultUserDirectory(configDir);
// Call per-process mainline module initialization.
initializeMainlineModules();
Process.setArgV0("<pre-initialized>");
Looper.prepareMainLooper();
// Find the value for {@link #PROC_START_SEQ_IDENT} if provided on the command line.
// It will be in the format "seq=114"
long startSeq = 0;
if (args != null) {
for (int i = args.length - 1; i >= 0; --i) {
if (args[i] != null && args[i].startsWith(PROC_START_SEQ_IDENT)) {
startSeq = Long.parseLong(
args[i].substring(PROC_START_SEQ_IDENT.length()));
}
}
}
ActivityThread thread = new ActivityThread();
thread.attach(false, startSeq);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
3.2 一个线程可以有几个Handler?Looper？
可以创建多个Handler实例，但是只能能有一个Looper！
为什么？看一下Looper创建过程prepare，涉及到ThreadLocal机制，当从sThreadLocal(一个map缓存对象)获取不到时会报错
Only one Looper may be created per thread,一个线程只能创建一个looper,ThreadLocal机制的核心就在于线程隔离。
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));
}
在一个Android线程中，可以创建多个Handler实例，每个Handler实例都有自己的消息队列，并且能够独立地发送和处理消息。
每个线程只能拥有一个Looper对象，以确保消息的有序处理。
在主线程（UI线程）中，默认已经创建了一个Looper实例，因此可以直接使用Handler来发送和处理消息。在其他线程中，如果需要使用Handler进行消息通信，则需要显式地为该线程创建一个Looper实例。
一个线程中有几个Handler？几个Looper？怎么保证？
3.3 Handler线程间通信的原理是怎样的？
一般情况下：
子线程 发送MSG： handler.sendMessage()
主线程 取消息、处理消息：· handler.handleMessage()
消息发送过程：
Handler.java
sendMessage( Message msg) MessageQueue添加消息的过程 Handler.java
—>sendMessageDelayed(msg, 0)
—>sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis)
—>enqueueMessage(queue, msg, uptimeMillis)
—>MessageQueue.enqueueMessage(Message msg, long when) MessageQueue.java
处理消息过程：
ActivityThread.main() ActivityThread.java
—>Looper.loop() Looper.java
—>loopOnce(me, ident, thresholdOverride)
—>MessageQueue.next
—> msg.target.dispatchMessage(msg);
—> Handler.dispatchMessage(msg); Handler.java
—>Handler.handleMessage()
线程间内存共享 核心 ： MessageQueue 共享
每个Looper对象都有一个MessageQueue，用于存放待处理的消息。一个线程中的Handler可以往自己所关联的Looper的MessageQueue中发送消息，其他线程的Handler则可以通过向目标Handler所关联的Looper的MessageQueue中发送消息来实现线程间通信。
3.4 Handler的内存泄露原因？
主线程的Looper对象的生命周期 = 该应用程序的生命周期
在Java中，非静态内部类 & 匿名内部类都默认持有 外部类的引用
static ThreadLocal—》Looper—》MessageQueue—》Message—》Handler—》Activity.this
形成了一条持有链，只要有前面的不释放，导致后续的东西都不会被GC杀死，从而导致内存泄漏
泄露原因：
- 当Handler消息队列 还有未处理的消息 / 正在处理消息时，存在引用关系： “未被处理 / 正处理的消息 -> Handler实例 -> 外部类”
- 若出现 Handler的生命周期 > 外部类的生命周期 时（即 Handler消息队列 还有未处理的消息 / 正在处理消息 而 外部类需销毁时），将使得外部类无法被垃圾回收器（GC）回收，从而造成 内存泄露
解决方案:
静态内部类 + 弱引用的方式+当外部类结束生命周期时，清空Handler内消息队列
原理：静态内部类不默认持有外部类的引用，从而使得 “未被处理 / 正处理的消息 -> Handler实例 -> 外部类” 的引用关系 不存在。
弱引用的特点： 在垃圾回收器一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。 所以用户在关闭 Activity 之后，就算后台线程还没结束，但由于仅有一条来自 Handler 的弱引用指向 Activity，Activity 也会被回收掉。这样，内存泄露的问题就不会出现了。
static class MyHandler extends Handler {
WeakReference<Activity > mActivityReference;
MyHandler(Activity activity) {
mActivityReference= new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg) {
final Activity activity = mActivityReference.get();
if (activity != null) {
//...
}
}
}
@Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
// 外部类Activity生命周期结束时，同时清空消息队列 & 结束Handler生命周期
}
详解 Handler 内存泄露的原因
Handler造成内存泄漏的原因以及解决方案
3.5 为何主线程可以new Handler?如果想要在子线程中new Handler 要做什么准备？
主线程 在new Handler前已经有了loop的创建和循环
想要在子线程中new Handler，需要创建looper和loop循环
Looper. prepare(）以及Looper.loop()
3.6 子线程中维护的looper,消息队列无消息的时候的处理方案是什么？有什么用？主线程呢？
在子线程中维护的Looper和消息队列，当消息队列中没有消息时，一般会进入阻塞状态，等待新的消息到来或者手动退出循环，以节省CPU资源。
如何退出阻塞？
如果在子线程中创建了一个Handler，那么就必须做三个操作：
- prepare()；
- loop()；
- quit()；
也可以使用官方推荐的HandlerThread
loop()操作会让Looper一直处于一个阻塞状态。它就一直在等待，这个子线程也已经干不了其他的事情了，其实也被卡死了。
有什么用：释放线程
而在主线程中，通常是在UI线程中维护的Looper和消息队列。当消息队列无消息时，主线程仍需要保持响应，因此不能使用阻塞的方式等待新消息到来。在主线程中的消息队列无消息时，系统会继续处理UI事件，并执行UI线程中的其他任务。
参考链接：
子线程中：new Handler需要做哪些准备？
Android HandlerThread 详解
3.7 使用Message时如何创建?
创建一个Message对象，可以通过以下方式创建Message对象：
Message message = Message.obtain(); // 使用Message的obtain方法获取一个Message对象，Android会尝试从消息池中获取一个空闲对象，避免频繁创建对象
// 设置Message的参数
message.what = YOUR_WHAT_VALUE; // 设置消息类型标识，用于处理不同类型的消息
message.obj = YOUR_OBJECT; // 设置消息内容，可以是任意类型的对象
// 其他需要设置的参数，如arg1, arg2, data等
向Handler发送消息，使得Handler在自己关联的线程中处理这个消息：
handler.sendMessage(message); // 向Handler发送消息
3.8 handler的消息阻塞是怎么实现的？
handler的消息阻塞实现机制：
Loop.java
public static void loop() {
......
for (;;) {
if (!loopOnce(me, ident, thresholdOverride)) {
return;
}
......
}
loop方法虽然是一个死循环，但是内部会检测loopOnce的返回值，如果为false,那么还是会退出阻塞状态，退出loop循环。
再来看loopOnce方法，当发现队列里的消息为空时，会返回false。
private static boolean loopOnce(final Looper me,
final long ident, final int thresholdOverride) {
Message msg = me.mQueue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return false;
}
......
也就是说，如果loop发现消息为空时，看样子那么就会退出循环机制，否则将会阻塞接收、分发消息。
可是不对啊！子线程没有消息时，默认是阻塞的啊？
没错，其实me.mQueue.next()即MessageQueue的next()方法中，仍然有阻塞机制，
主线程的MessageQueue没有消息时，便阻塞在loop的queue.next()中的nativePollOnce()方法里，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生，通过往pipe管道写端写入数据来唤醒主线程工作。这里采用的epoll机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作，本质同步I/O，即读写是阻塞的。 所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源。 Gityuan–Handler(Native层)
Message next() {
// Return here if the message loop has already quit and been disposed.
// This can happen if the application tries to restart a looper after quit
// which is not supported.
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
nativePollOnce(ptr, nextPollTimeoutMillis);
......
主线程的Looper在初始化时，看代码
//子线程常用的Looper
public static void prepare() {
prepare(true);
}
//主线程的Looper
@Deprecated
public static void prepareMainLooper() {
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
//这里是重点 quitAllowed
sThreadLocal.set(new Looper(quitAllowed));
}
主线程和子线程初始化Looper的时候new Looper(quitAllowed）的值一个是true，一个是false，new Looper(quitAllowed)做了什么？
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
quitAllowed是MessageQueue初始化的构造参数，quitAllowed在里面干了什么？
MessageQueue(boolean quitAllowed) {
mQuitAllowed = quitAllowed;
mPtr = nativeInit();
}
MessageQueue代码中mQuitAllowed是一个boolean 类型，且只在quit方法中使用了。
// True if the message queue can be quit.
@UnsupportedAppUsage
private final boolean mQuitAllowed;
void quit(boolean safe) {
if (!mQuitAllowed) {
throw new IllegalStateException("Main thread not allowed to quit.");
}
synchronized (this) {
if (mQuitting) {
return;
}
mQuitting = true;
if (safe) {
removeAllFutureMessagesLocked();
} else {
removeAllMessagesLocked();
}
// We can assume mPtr != 0 because mQuitting was previously false.
nativeWake(mPtr);
}
}
主线程的mQuitAllowed值false,默认消息队列永远不会退出！
子线程可以通过quit方法最后唤醒，而主线程默认永远不会退出
void quit(boolean safe) {
if (!mQuitAllowed) {//注意，主线程是不能退出消息循环的
throw new IllegalStateException("Main thread not allowed to quit.");
}
synchronized (this) {
if (mQuitting) {//如果当前循环消息已经退出了，直接返回
return;
}
mQuitting = true;//该标记十分重要，十分重要
if (safe) {//如果是安全退出
removeAllFutureMessagesLocked();
} else {//如果不是安全退出
removeAllMessagesLocked();
}
nativeWake(mPtr);//叫醒等待
}
}
另外看一下如果子线程looper.loop()，那么默认会阻塞，如果此时调用quit()方法
nativeWake(mPtr)这个函数的调用，就会叫醒等待的地方，醒来之后，就接着往下执行。
//native的方法，在没有消息的时候回阻塞管道读取端，只有nativePollOnce返回之后才能往下执行
//阻塞操作，等待nextPollTimeoutMillis时长
nativePollOnce(ptr, nextPollTimeoutMillis);
往下执行后，发现 Message msg = mMessages; 是空的，然后就执行了这个，就接着往下走。
if (msg != null) {
......
} else {
// No more messages.
//没有消息，nextPollTimeoutMillis复位
nextPollTimeoutMillis = -1;
}
然后又调用了这个方法，并且return了null。
// Process the quit message now that all pending messages have been handled.
//如果消息队列正在处于退出状态返回null，调用dispose();释放该消息队列
if (mQuitting) {
dispose();
return null;
}
所以说，这个时候Looper就结束了(跳出了死循环)，则达成了第二个作用：释放线程。
![[图解]建模相关的基础知识-12](https://img-blog.csdnimg.cn/direct/58c970fd961f4a1ea528b85fc52fd422.png)
