Android知识点整理1：handler机制全面解析
目录
1、简介
2、主要组成部分：Handler、Looper、Message和MessageQueue
3、简述handler消息机制的主要流程
3、Handler send 消息 和 post 有什么区别？为甚么Message的创建建议用obtain方法？有什么优势？
4、子线程能直接新建Handler并使用吗？子线程能通过Handler直接向UI线程发消息的原因是什么？主线程怎么向子线程发消息？HandlerThread的原理
5、Handler同步屏障
6、MessageQueue相关操作，插入和取出
7、为什么loop不会阻塞主线程？死循环不会卡死UI线程吗？主线程都阻塞了怎么响应用户操作和生命周期方法？主线程的死循环一直运行是不是特别消耗CPU资源呢？
1、简介
Handler机制主要为线程间通信而生，是Android中定义的一套消息传递机制，主要是为了解决子线程执行完耗时操作后，怎么回调到主（UI）线程的问题。
2、主要组成部分：Handler、Looper、Message和MessageQueue
Handler负责发送Message到MessageQueue
Looper负责从MessageQueue读取消息，并通过Message的target，调用handler的消息分发处理
Handler负责处理消息回调
3、简述handler消息机制的主要流程
消息发送过程：Handler在子线程发送Message，由于Handler初始化的时候有持有当前线程的Looper和Looper中的MessageQueue，而这个Handler在主线程初始化，也就是该Handler持有主线程Looper和MessageQueue，发送普通消息会给Message的target赋值Handler本身，发送消息会最终会调用MessageQueue的enqueueMessage方法。
消息插入过程：根据系统相对时间+延迟时间 按照顺序 插入到单链表MessageQueue中，如果在表头，会判断是否有阻塞，有阻塞会调用native层的nativeWake方法唤醒线程，如果在表中间或表尾会判断该消息是否是异步消息，且阻塞的话，也会调用native层的nativeWake方法唤醒线程。
消息取出过程：Looper循环loop方法，会调用MessageQueue的next方法，这个方法在源码上面显示有可能会阻塞，MessageQueue next 也有一个死循环操作，如果上一个取出的消息有阻塞时间，会先调用native层的nativePollOnce方法进行阻塞，然后会判断是否是屏障Message，如果是屏障消息先过滤掉普通消息，先获取异步消息。如果Message消息的when大于当前系统相对时间则会设置需要阻塞的时间，如果Message消息的when小于或者等于当前系统相对时间，会取出这个消息。如果有阻塞的情况，还会调用IdleHandler的回调。通过MessageQueue取出Messgae后，会通过Message的target（target就是发送该Message的Handler）调用 Handler的dispatchMessage方法处理消息分发。
消息分发过程：如果Message callback不为空，代表是通过post的方式发送消息，调用Runnable的 run方法；如果Handler中的mCallback不为空，调用mCallbcak的 handleMessage；否则会调用handleMessage回调。
3、Handler send 消息 和 post 有什么区别？为甚么Message的创建建议用obtain方法？有什么优势？
（1)、send方式和post方式本质没有区别，都是发送Message，只不过post方式会把Runnable对象赋值给Message的callback，在最后消息分发的时候会回调Runnable的run方法。
先看下 Handler post的源码：
public final boolean post(@NonNull Runnable r) {
return sendMessageDelayed(getPostMessage(r), 0);
}
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}我们从源码可以看到无论是 send方式 还是 post方式 最终都是调用 sendMessageAtTime 这个 方法，不同的是post方式，会通过getPostMessage(r)获得一个Message，代码如下：
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}这里会把Runnable对象赋值给Message 的 callback，我们再来看看Handler最终处理消息分发的方法：
/**
* Handle system messages here.
*/
public void dispatchMessage(@NonNull Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}如果Message 中 callback 不为空，回调Message的callback；如果Handler对象中的mCallback不为空，回调这个mCallback的方法；只有前两个为空，才会回调handlerMessage方法。
第三种是我们最常用的方式，Handler无参构造，其中第二种是 Handler有参构造，源码如下：
public Handler() {
this(null, false);
}
public Handler(@Nullable Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class 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 " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}总结：send 方式 和 post 方式 本质没有区别，都是发送Message，只不过在最后dispatchMessage分发的时候处理不一样。
（2）Message 本身包含两个Message对象，一个是sPool，一个是next，但通过看源码可知道sPool是一个static对象，是所有对象共有，Message sPool就是一个单链表结构，Message就是单链表中的一个节点。
使用obtain方法，取的是Message 的 sPool ，改变sPool指向sPool的next，取出sPool本身，并清空该Message的flags和next。这样的好处是是可避免重复创建多个实例对象，可以取消息池子之前已经存在的消息。相关源码如下：
我们来看看Message的obtain方法
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();
}我们再来看看sPool的定义
@UnsupportedAppUsage
/*package*/ Message next;
/** @hide */
public static final Object sPoolSync = new Object();
private static Message sPool;
private static int sPoolSize = 0;
private static final int MAX_POOL_SIZE = 50;
private static boolean gCheckRecycle = true;4、子线程能直接新建Handler并使用吗？子线程能通过Handler直接向UI线程发消息的原因是什么？主线程怎么向子线程发消息？HandlerThread的原理
（1）、子线程并不能直接新建Handler并使用，原因可以看Handler的源码：
public Handler(@Nullable Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class 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 " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}在构造Handler方法中 Handler会持有该线程的Looper 和 Looper中的MessageQueue，Handler的使用必须是结合Looper，而子线程中并没有绑定Looper，所以会报错。
这里特别要提醒因为Handler的构造方法中可以传递Looper：handler对象所绑定的线程其实并不取决于该handler对象由哪个线程构建，而是取决于该handler对象所绑定的Looper属于哪个线程。
所以有的面试官会问 handleMessage 方法执行的线程一定是在创建Handler的线程吗？答案是否定的，是在绑定Looper所属于的那个线程
（2）、为什么主线程却不用创建Looper，直接使用Handler呢？我们可以从源码角度来看，实际上主线程创建的时候程序已经自动帮我们创建Looper了
应用的启动 离不开 ActivityThread、ActivityManageService 两个进程，我们来看程序入口main方法：
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);
Process.setArgV0("");
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");
} 我们可以看到Looper.prepareMainLooper(); 和 Looper.loop(); 这两个关键的方法，一个是创建Looper，一个是启动Looper循环。再跟进prepareMainLooper（） 这个方法：
public static void prepareMainLooper() {
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}说明主线程的Looper是在程序入口处创建的，所以才不用自己去新建一个Looper
再看看 prepare这个方法：
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));
}
PS：ThreadLocal是为了提供线程内部的局部变量，方便在本线程内随时随地的读取，并且与其他线程隔离
主线程的prepare(false),所以是不可退出的Looper
每一个线程 只有一个Looper、一个Looper只有一个MessageQueue。
那么怎么保证Looper、MessageQueue唯一性呢？ 就是利用到了 ThreadLocal特性，同时利用私有构造方法 只能在类里面被访问，无法被类外访问。
权限修饰符可以看这里：https://blog.csdn.net/wuqiqi1992/article/details/107868770
所以构造一个Looper对象只能通过prepare方法，这里面有判断如果不为空 会抛异常。
我们来看看Looper的构造方法和prepare方法来保证 线程中Looper唯一性：
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));
}
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}看上面代码MessageQueue 是在Looper构造方法中初始化的，所以保证了Looper唯一性，也就保证了MessageQueue的唯一性。
（3）、主线程要想向子线程发送消息，需要在子线程中调用Looper.prepare() 这个方法，并且之后再启动looper循环可以在run中写类似代码：
Looper.prepare();
handler=new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
//做事情,做完后要退出循环
handler.getLooper().quitSafely();
}
};
Looper.loop();其中Looper的quit 和 quitSafely 区别是 ：前者会清空MessageQueue所有消息，后者只会清空MessageQueue消息池中所有的延迟消息，并将消息池中所有的非延迟消息派发出去让Handler去处理。
（4）、HandlerThread其实就是一个自己封装好Looper的线程
先看构造方法：
public HandlerThread(String name, int priority) {
super(name);
mPriority = priority;
}会传入线程名称和优先级，再看看run方法
@Override
public void run() {
mTid = Process.myTid();
Looper.prepare();
synchronized (this) {
mLooper = Looper.myLooper();
notifyAll();
}
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
}就是自己准备Looper，开启loop循环，我们注意到有个notfiyAll方法，再结合下面这个方法，如果线程已经被开启，但looper是null就会阻塞wait，直到被唤醒，然后判断looper不为null，就跳出循环。run方法这里就是Looper已经prepare() 创建了 才唤醒notifyAll
这里sleep和wait的区别 可以 看 https://blog.csdn.net/wuqiqi1992/article/details/107878581
/**
* This method returns the Looper associated with this thread. If this thread not been started
* or for any reason isAlive() returns false, this method will return null. If this thread
* has been started, this method will block until the looper has been initialized.
* @return The looper.
*/
public Looper getLooper() {
if (!isAlive()) {
return null;
}
// If the thread has been started, wait until the looper has been created.
synchronized (this) {
while (isAlive() && mLooper == null) {
try {
wait();
} catch (InterruptedException e) {
}
}
}
return mLooper;
}
5、Handler同步屏障
（1）Message消息主要分为三种：同步消息、屏障消息、异步消息
（2）同步屏障就是通过屏障消息来屏蔽所有同步消息，处理后续异步消息
（3）核心代码我们可以先看看 MessageQueue 取消息的代码：
@UnsupportedAppUsage
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);
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) {
// 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;
}
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// Run the idle handlers.
// We only ever reach this code block during the first iteration.
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
// Reset the idle handler count to 0 so we do not run them again.
pendingIdleHandlerCount = 0;
// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
}
}最核心的是的判断是这段代码
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());
}屏障消息主要是起一个屏蔽作用，所以不需要有handler 处理消息分发，所以target为null。
如果有屏障消息，且消息不是异步的则继续取下一个，直到遇到异步消息。
（4）异步消息如何设置：
可以直接调用Message的 方法
public void setAsynchronous(boolean async) {
if (async) {
flags |= FLAG_ASYNCHRONOUS;
} else {
flags &= ~FLAG_ASYNCHRONOUS;
}
}然后Handler构造方法的时候发现也可以设置 Handler的mAsynchronous，但是hide方法，我们可以通过反射去调用，也是可以的。再来看看 Handler发送消息，插入MessageQueue队列的代码：
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
long uptimeMillis) {
msg.target = this;
msg.workSourceUid = ThreadLocalWorkSource.getUid();
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}（5）如何设置同步屏障
屏障消息和一般的消息区别就是没有 target，可以看下MessageQueue的源码
private int postSyncBarrier(long when) {
// Enqueue a new sync barrier token.
// We don't need to wake the queue because the purpose of a barrier is to stall it.
synchronized (this) {
final int token = mNextBarrierToken++;
final Message msg = Message.obtain();
msg.markInUse();
msg.when = when;
msg.arg1 = token;
Message prev = null;
Message p = mMessages;
if (when != 0) {
while (p != null && p.when <= when) {
prev = p;
p = p.next;
}
}
if (prev != null) { // invariant: p == prev.next
msg.next = p;
prev.next = msg;
} else {
msg.next = p;
mMessages = msg;
}
return token;
}
}按照时间顺序插入到队列里面
（6）同步屏障的应用
举例：屏幕刷新机制
Android 每隔16.6ms会刷新一次屏幕，每个Activity对应一个 DecorView 根布局View树，初始化过程中DecorView会被添加到
viewRootImp setView的过程：
viewRootImp.setView() —> viewRootImp.requestLayout() —>
viewRootImp.scheduleTraversals() —> viewRootImp.doTraversal() —> viewRootImp.performTraversals()—>这里我们主要看scheduleTraversals这个方法：
@UnsupportedAppUsage
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}其中 mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); 这行代码就是设置同步屏障
mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); 这行代码跟踪@TestApi
public void postCallback(int callbackType, Runnable action, Object token) {
postCallbackDelayed(callbackType, action, token, 0);
}
@TestApi
public void postCallbackDelayed(int callbackType,
Runnable action, Object token, long delayMillis) {
if (action == null) {
throw new IllegalArgumentException("action must not be null");
}
if (callbackType < 0 || callbackType > CALLBACK_LAST) {
throw new IllegalArgumentException("callbackType is invalid");
}
postCallbackDelayedInternal(callbackType, action, token, delayMillis);
}
private void postCallbackDelayedInternal(int callbackType,
Object action, Object token, long delayMillis) {
if (DEBUG_FRAMES) {
Log.d(TAG, "PostCallback: type=" + callbackType
+ ", action=" + action + ", token=" + token
+ ", delayMillis=" + delayMillis);
}
synchronized (mLock) {
final long now = SystemClock.uptimeMillis();
final long dueTime = now + delayMillis;
mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);
if (dueTime <= now) {
scheduleFrameLocked(now);
} else {
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
msg.arg1 = callbackType;
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);
}
}
}看到最后 发现发送了一个异步消息
由于同步屏障的作用 异步消息优先于同步消息，异步消息先执行，保证了屏幕刷新的及时性和优先级。
6、MessageQueue相关操作，插入和取出
MessageQueue的底层数据结构是单向链表
（1）插入操作
通过源码可以看到添加消息到队列是根据Message中的when来保证顺序性的，这个when的值是由SystemClock.uptimeMilis()+delayMillis 决定的，这个uptimeMilis是相对于系统启动的相对时间，为什么不用SystemClock. currentTimeMillis()，因为这个时间可以通过调整系统时间进行修改，可能会不准确。
可以看到Handler发送消息源码：
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
public boolean sendMessageAtTime(@NonNull 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);
}
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
long uptimeMillis) {
msg.target = this;
msg.workSourceUid = ThreadLocalWorkSource.getUid();
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}然后我们再来看看MessageQueue中 enqueueMessage方法，是怎么插入队列的
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
if (mQuitting) {
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w(TAG, e.getMessage(), e);
msg.recycle();
return false;
}
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;
needWake = mBlocked;
} else {
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
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;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}可以看出 如果 if(p==null || when==0|| when 否则代表此消息是延时消息，然后按照延时顺序插入 （2）取出操作 看看Looper 中 loop 循环操作源码： MessageQueue的 next方法就是取出操作 再来看看 next对应源码： 上面代码我做了详细注释，这里我特别讲下这个IdleHandle 的使用场景 比如需要懒加载，例子：测量某控件的高宽，等到UI线程消息执行完再来执行相关代码： 有时候感觉这些问题有毛病，当消息队列为空时候就是会阻塞线程啊，本身就是有阻塞主线程的时候，第一个问题问的就是错的。如果不死循环，线程不直接退出去了，怎么保证主线程一直运行，代码一直死循环不就可以了。 网上有一篇我觉得写的还可以，想看答案的看这个文章吧 https://blog.csdn.net/qq_34681580/article/details/104760530 /**
* 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();
// Allow overriding a threshold with a system prop. e.g.
// adb shell 'setprop log.looper.1000.main.slow 1 && stop && start'
final int thresholdOverride =
SystemProperties.getInt("log.looper."
+ Process.myUid() + "."
+ Thread.currentThread().getName()
+ ".slow", 0);
boolean slowDeliveryDetected = false;
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);
}
// Make sure the observer won't change while processing a transaction.
final Observer observer = sObserver;
final long traceTag = me.mTraceTag;
long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
long slowDeliveryThresholdMs = me.mSlowDeliveryThresholdMs;
if (thresholdOverride > 0) {
slowDispatchThresholdMs = thresholdOverride;
slowDeliveryThresholdMs = thresholdOverride;
}
final boolean logSlowDelivery = (slowDeliveryThresholdMs > 0) && (msg.when > 0);
final boolean logSlowDispatch = (slowDispatchThresholdMs > 0);
final boolean needStartTime = logSlowDelivery || logSlowDispatch;
final boolean needEndTime = logSlowDispatch;
if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
final long dispatchStart = needStartTime ? SystemClock.uptimeMillis() : 0;
final long dispatchEnd;
Object token = null;
if (observer != null) {
token = observer.messageDispatchStarting();
}
long origWorkSource = ThreadLocalWorkSource.setUid(msg.workSourceUid);
try {
msg.target.dispatchMessage(msg);
if (observer != null) {
observer.messageDispatched(token, msg);
}
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
} catch (Exception exception) {
if (observer != null) {
observer.dispatchingThrewException(token, msg, exception);
}
throw exception;
} finally {
ThreadLocalWorkSource.restore(origWorkSource);
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
if (logSlowDelivery) {
if (slowDeliveryDetected) {
if ((dispatchStart - msg.when) <= 10) {
Slog.w(TAG, "Drained");
slowDeliveryDetected = false;
}
} else {
if (showSlowLog(slowDeliveryThresholdMs, msg.when, dispatchStart, "delivery",
msg)) {
// Once we write a slow delivery log, suppress until the queue drains.
slowDeliveryDetected = true;
}
}
}
if (logSlowDispatch) {
showSlowLog(slowDispatchThresholdMs, dispatchStart, dispatchEnd, "dispatch", msg);
}
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();
}
} @UnsupportedAppUsage
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) {
/**代表队列为空，一半是Looper调用了 quit方法，可以看到mPtr的定义 used by native code,代表被 nativie层使用，关联的是C++层的MessageQueue，其中阻塞操作就是C++层的MessageQueue来操作的
*/
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
/**
阻塞方法，阻塞方法，通过native层的epoll监听文件描述符的写入事件来实现的。
nextPollTimeoutMillis = -1，代表一直阻塞，直到被唤醒，0代表不会阻塞，立即返回，>0代表阻塞时间不超过nextPollTimeoutMillis ，期间有程序唤醒立即返回
*/
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，进入下次循环的时候会调用nativePollOnce(ptr, nextPollTimeoutMillis)进行阻塞*/
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
正常取出消息 设置mBlocked = false代表目前没有阻塞
// 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 {
// 没有消息，会一直阻塞，直到被唤醒
nextPollTimeoutMillis = -1;
}
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
//下面是IdleHandler的处理监听 ,IdleHandler默认数量为-1，只有当 消息为空，或者当前消息还没有到//时间才会赋值IdleHandlerCount
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
//这里会调用idlerd的 queueIdle方法，会判断是否移除该空闲监听
// Run the idle handlers.
// We only ever reach this code block during the first iteration.
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
// Reset the idle handler count to 0 so we do not run them again.
pendingIdleHandlerCount = 0;
// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
}
}
比如在framework层中，需要系统GC回收 就用到了这个监听，只有在cpu空闲的时候才执行GC操作，void scheduleGcIdler() {
if (!mGcIdlerScheduled) {
mGcIdlerScheduled = true;
Looper.myQueue().addIdleHandler(mGcIdler);
}
mH.removeMessages(H.GC_WHEN_IDLE);
}
final class GcIdler implements MessageQueue.IdleHandler {
@Override
public final boolean queueIdle() {
doGcIfNeeded();
return false;
}
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
Looper.myQueue().addIdleHandler {
//todo
false
}
}
7、为什么loop不会阻塞主线程？死循环不会卡死UI线程吗？主线程都阻塞了怎么响应用户操作和生命周期方法？主线程的死循环一直运行是不是特别消耗CPU资源呢？