[Framework] Android Handler 作业原理
Android 中的 Handler 都被人说烂了，可是还是想多说一次，由于在 Android 的体系中它真的十分重要而且它的机制并没有很复杂，无论是新手和内行都能够好好学习下，这对了解 Android 体系很重要，所以说学习的性价比十分高。
Android 中 IPC 跨进程通讯首要依托 Binder (参考我之前的文章 Android Binder 作业原理), 而同一个进程的通讯就首要依托 Handler。
这儿先简略描绘下 Handler 的作业流程：
首先在 Handler 处理使命的线程需求调用 Looper#prepare() 办法，来为当时线程创立一个 Looper 实例，这个实例经过 ThreadLocal 存放，也便是一个线程只能有一个这个实例；Looper 结构函数中会初始化一个 MessageQueue 目标，MessageQueue 目标便是用来封装使命的行列，它是用的链表完结，而使命行列的 Item 便是 Message 目标，也便是单个的使命；使命处理线程调用 Looper#prepare() 办法完结后，会调用 Looper#loop() 办法，这个时分使命线程就会堵塞去处理对应 Looper 中的 MessageQueue 中的使命，处理的办法便是一个死循环从 MessageQueue 中去获取最新的 Message 获取到后，然后调用对应的 Handler#handleMessage() 办法去履行它，履行完结后又去获取下一个使命，假如没有新的使命就会陷入堵塞，等有新的使命来的时分会唤醒这个堵塞（这个唤醒机制是用的 Linux 中的 epoll 机制），持续履行新的使命。
上面大致描绘了 Looper 和 MessageQueue 怎样从行列中获取新的使命和履行使命，这儿再简略描绘下怎样插入使命，首先要自定一个 Handler 目标，结构函数中需求传入上面所创立的 Looper 目标，其间自定义的 Handler#handleMessage 办法便是用来履行使命的办法，其他的线程需求向对应的 Looper 线程增加使命时，就调用上面 Handler 实例的 sendMessage 办法来增加使命，也便是向 MessageQueue 行列中增加使命，终究会在 Looper 所对应的线程履行，这样就完结了一次跨线程的通讯。
下面是一个简略的 Handler 运用的代码：
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
var handlerLooper: Looper? = null
val handlerThread = object : Thread() {
override fun run() {
super.run()
Looper.prepare()
handlerLooper = Looper.myLooper()
Looper.loop()
}
}
handlerThread.start()
while (handlerLooper == null) {
// 等候 HandlerThread 初始化完结
}
val handler = object : Handler(handlerLooper!!) {
override fun handleMessage(msg: Message) {
super.handleMessage(msg)
if (msg.what == 0) {
// TODO: 处理使命，该办法终究作业在 HandlerThread 线程
}
}
}
val msg = handler.obtainMessage(0)
// 发送的代码作业在主线程
handler.sendMessage(msg)
}
Android 中有现成的 HandlerThread，不必自定义，我这儿是为了展示这个进程。
Tips: 我后续的源码剖析都是根据 andorid 31
Looper
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();
}
// ...
初始化的进程十分简略，假如当时线程现已有 Looper 目标就直接报错，假如没有新建一个 Looper 目标放在 ThreadLocal 中，在 Looper 的结构函数中，创立了 MessageQueue 实例和保存了当时的 Thread 目标。
Looper 使命处理
// ...
public static void loop() {
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
if (me.mInLoop) {
Slog.w(TAG, "Loop again would have the queued messages be executed"
+ " before this one completed.");
}
me.mInLoop = true;
// ..
me.mSlowDeliveryDetected = false;
for (;;) {
if (!loopOnce(me, ident, thresholdOverride)) {
return;
}
}
}
// ...
Looper#loop() 办法也十分简略，修正了当时的 Looper 的一些状况，然后在死循环中无限调用 loopOnce() 办法去履行使命，假如该办法回来 false 就表明该 Looper 现已退出，就跳出循环。
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;
}
// 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);
}
// ...
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 (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
// ...
msg.recycleUnchecked();
return true;
}
直接调用 MessageQueue#next() 办法去获取 Message 目标，假如回来空就表明 Looper 现已退出了。这儿有一个 Printer 目标，在 Message 履行前后都会打印对应的日志，能够经过调用 Looper#setMessageLogging() 办法来自定义这个目标，根据打印的日志内容咱们就能够分辩是开端前还是开端后，在 APM 中常常经过这个办法来判别主线程的使命履行是否超时。履行使命会调用的是 handler.target#dispatchMessage() 办法，其实这个 target 目标便是 Handler，后续再剖析这个办法。
这次看代码还有新发现，这儿还多了一个 Observer 目标，我记住以前的旧版本是没有的，能够经过 Looper#setObserver() 办法来设置，它的接口如下：
public interface Observer {
/**
* Called right before a message is dispatched.
*
* <p> The token type is not specified to allow the implementation to specify its own type.
*
* @return a token used for collecting telemetry when dispatching a single message.
* The token token must be passed back exactly once to either
* {@link Observer#messageDispatched} or {@link Observer#dispatchingThrewException}
* and must not be reused again.
*
*/
Object messageDispatchStarting();
/**
* Called when a message was processed by a Handler.
*
* @param token Token obtained by previously calling
* {@link Observer#messageDispatchStarting} on the same Observer instance.
* @param msg The message that was dispatched.
*/
void messageDispatched(Object token, Message msg);
/**
* Called when an exception was thrown while processing a message.
*
* @param token Token obtained by previously calling
* {@link Observer#messageDispatchStarting} on the same Observer instance.
* @param msg The message that was dispatched and caused an exception.
* @param exception The exception that was thrown.
*/
void dispatchingThrewException(Object token, Message msg, Exception exception);
}
Observer 能够监听使命开端，完毕和反常，看上去它能够替换 Printer，不过它是对使用层躲藏的，需求骚操作。
Handler
Handler 初始化
public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
其间 Looper 和 MessageQueue 就不必多说了；其间 mCallback 目标便是能够优先于 Handler#handleMessage 办法处理使命，也能够阻拦使命不让 Handler#handleMessage 履行；async 是表明发送的音讯是否是异步音讯，这个和音讯屏障关系亲近，后续会再剖析。
Handler 发送音讯
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);
}
无论是调用 Handler 的哪个办法发送音讯，终究都会到 enqueueMessage() 办法里面去，在 Looper 中咱们说到 target 便是 Handler 目标，在这儿就得到验证了，假如 Handler 的结构函数中设置为异步，Message 也会被设置为异步，然后直接将处理好的 Message 经过 MessageQueue#enqueueMessage() 办法增加到行列中。
Handler 处理音讯
在 Looper 下发音讯时说到最终会调用 Handler 的 dispatchMessage() 办法：
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 就直接在对应的 Callback 中处理，不持续下发； 假如 Message 中没有设置 Callback，会先查看 Handler 是否有设置 mCallback，假如有设置，调用 mCallback 处理，mCallback 的 handleMessage 回来 true 就表明要阻拦该音讯，假如不阻拦就交由 Handler 的 handleMessage() 办法处理。
MessageQueue
MessageQueue 插入使命
在讲 Handler 的时分说到插入音讯会直接调用 MessageQueue#enqueueMessage() 办法：
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
synchronized (this) {
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
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;
}
假如 Message 没有设置 Handler 直接抛出反常；假如 Message 现已是 inUse 状况，直接抛出反常；假如 MessageQueue 现已退出，就直接收回 Message；依照使命的触发时刻由小到大，插入到 mMessage 链表中，最终假如需求唤醒 next() 办法中的 nativePollOnce() 办法，就会调用 nativeWake 办法，这是一个 C++ 完结的办法（内部完结其实是向一个管道 fd 中写入了一个数字 1，经过 epoll 机制，会监听到管道 fd 有数据写入，然后会唤醒 nativePollOnce() 办法，然后去读取新的 Message）。
MessageQueue 读取使命
在讲 Looper 时讲到最终获取使命是经过 MessageQueue#next() 办法：
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();
}
// 等候 epoll 唤醒，唤醒是等候 nativeWake() 办法调用或许超时(超时时刻为 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;
// target 为空，就表明这是一个屏障的音讯
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.
// 当时音讯的时刻大于当时的时刻，表明还没有抵达履行的时刻，核算距离，等候从头进入 nativePollOnce 办法
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;
}
// 后续便是在没有音讯时回调 IdleHandler
// 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.
// 假如 pendingIdleHandlerCount 小于 0 就表明当时的这一次 next() 办法调用，还没有履行过 IdleHandler，就需求去读取 IdleHandler 的数量，在一次 next() 办法调用时最多履行一次 IdleHandler。
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// 这儿就表明 IdleHandler 为空，或许现已履行过了。
// 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 {
// 履行 idleHandler
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.
// 这儿设置为 0 后，IdleHandler 就不会再次履行，需求等候下次的 next() 办法调用
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;
}
}
经过 nativePollOnce() 办法等候唤醒(经过调用 nativeWake() 办法)或许超时(超时时刻是 nextPollTimeoutMillis)，唤醒后直接获取最新的一条 Message（先越过同步音讯逻辑），然后判别使命履行的时刻，假如大于当时时刻就持续等候，直到能够履行，假如小于当时时刻直接回来，同时把这条音讯从行列中移除（先越过 IdleHandler 逻辑）。
同步音讯和音讯屏障
假如 target 目标为空就表明该音讯是一个同步屏障，假如是同步屏障的话他就会从头再去取该同步屏障音讯后边的最新一个异步音讯去履行，假如没有异步音讯就会去等候。
经过以下办法增加屏障音讯：
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;
}
}
其实便是在音讯行列中增加了一个 target 为空的音讯，同时在 Message 的 arg1 目标中增加 token 目标，然后这个 token 也会回来给调用方，这个 token 在移除屏障时需求用到。
经过以下办法能够移除这个音讯屏障：
public void removeSyncBarrier(int token) {
// Remove a sync barrier token from the queue.
// If the queue is no longer stalled by a barrier then wake it.
synchronized (this) {
Message prev = null;
Message p = mMessages;
while (p != null && (p.target != null || p.arg1 != token)) {
prev = p;
p = p.next;
}
if (p == null) {
throw new IllegalStateException("The specified message queue synchronization "
+ " barrier token has not been posted or has already been removed.");
}
final boolean needWake;
if (prev != null) {
prev.next = p.next;
needWake = false;
} else {
mMessages = p.next;
needWake = mMessages == null || mMessages.target != null;
}
p.recycleUnchecked();
// If the loop is quitting then it is already awake.
// We can assume mPtr != 0 when mQuitting is false.
if (needWake && !mQuitting) {
nativeWake(mPtr);
}
}
}
我之前在 [Framework] Android Choreographer 作业原理 有简略介绍过，在制作的时分就会用到同步音讯和音讯屏障来进步制作相关的 Message 的优先级。
请求制作终究会到 ViewRootImpl#scheduleTraversals() 办法中，在这个办法中就会增加一个屏障：
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
在 Choregorapher 收到 Vsync 信号后会发送一个 Handler 的异步 Message:
public void onVsync(long timestampNanos, long physicalDisplayId, int frame,
VsyncEventData vsyncEventData) {
// ..
Message msg = Message.obtain(mHandler, this);
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
// ..
}
在制作完结后会调用 ViewRootImpl#unscheduleTraversals() 办法移除这个屏障：
void unscheduleTraversals() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
mChoreographer.removeCallbacks(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
}
}
IdleHandler
IdleHandler 便是在 next() 办法获取不到音讯时会履行一次，next() 办法调用一次最多只能履行一次 IdleHandler，履行 IdleHandler 的时分就表明当时的 Looper 比较闲暇，IdleHandler 的数量最多为 4 个 (在 Activity 的 onDestroy() 回调便是在 IdleHandler 中履行的，可能写这部分代码的人，认为 onDestroy() 相对其他的生命周期没有那么重要，可是由于 IdleHandler 的特性也会引发一些问题，后续有时刻会剖析这个问题) 。
能够经过以下办法增加 IdleHandler：
public void addIdleHandler(@NonNull IdleHandler handler) {
if (handler == null) {
throw new NullPointerException("Can't add a null IdleHandler");
}
synchronized (this) {
mIdleHandlers.add(handler);
}
}
epoll 在 Handler 中的作业办法
在 MessageQueue 的结构函数中会经过 Native 办法 nativeInit() 初始化 epoll，初始化流程会先经过 epoll_create() 办法创立一个 EpollFd，然后构建一个管道的 fd 用于 epoll 来监听它的读写状况，这个 fd 被命名为 WakeFd，然后经过 epoll_ctl() 办法将 WakeFd 增加到 EpollFd 中，以供后续经过 EpollFd 能够监听 WakeFd 的状况。
在 MessageQueue 的 next() 办法中会经过 Native 办法 nativePollOnce() 办法去监听上面所说到 WakeFd 的状况，Native 层是经过 epoll_wait() 办法去监听状况，这个办法会比及超时或许 WakeFd 有数据写入就会回来。
在 MessageQueue 的 enqueueMessage() 办法中插入 Message 后，会判别是否需求唤醒 next() 中的 nativePollOnce() 办法，假如需求唤醒就会调用 Native 办法 nativeWake() 办法，Native 层就会向 WakeFd 中写入一个数字 1，然后 nativePollOnce() 间听到这个 WakeFd 写状况后就会回来，也就免除 next() 办法的堵塞去读取新的 Message。
最终聊一聊主线程
在 Android Framework 中有两个首要的主线程 Handler，一个是 ActivityThread 中的 H，它首要来处理四大组建的各种生命周期；还有一个是 Choreographer 中的 FrameHandler，它首要担任制作，动画，输入等操作。这两个 Handler 担任的作业和用户体会都极为亲近，主线程也能够说十分忙。
在项目中我常常发现许多的代码都会在主线程履行，分明有的操作不需求主线程履行。比如说在一个网络请求的通用办法中，在网络完结的回调中就会自动切换到主线程，分明许多地方的代码不需求用到主线程，我个人的观念是必定需求切换主线程时再切换，在必定程度上能够缓解使用卡顿的问题。
参考文章
Android音讯机制2-Handler(Native层)
select/poll/epoll对比剖析
