三年，感觉就是一个坎，最近压力有点大，总是在胡思乱想，想想自己的竞争力，除了知道自己从字节快手工
作过，剩下的就是CV操作，感觉啥都不会。特别是在这个大环境之下，感觉愈发慌乱了，想想，还是不要过于
紧张，把之前学到的，看到的，记录一个Doc吧，总结一些。
一定要学会的
Handler我们也用了很久了，内部的逻辑我想大家也都了然了，这我在记录一下。当然，我们还是提出问题，跟着问题去分析。
- Handler的简单实用方式和场景。
- Hanlder的消息机制实现的大概原理。
- 如何创建一个自己的Handler？
- Android系统是怎么创建的？
- HandlerThread简单原理。
详细解析
简单使用
现在我们用Handler大部分就是为了实现线程切换，发送一个消息，在主线程做一些我们预期的操作，比如更新UI等。没有很多特别需要讲解的。
Handler(Looper.getMainLooper()).post {
// do something
}
原理流程
发送消息
首先，我们通过Handler发送一个消息，我们分析一下。
public final boolean post(@NonNull Runnable r) {
return sendMessageDelayed(getPostMessage(r), 0);
}
- 首先通过getPostMessage构建一个消息对象Message。
- 第二个参数，就是希望当前消息的延迟执行的时间，单位毫秒，3000，就意味着希望当前的消息3s后被执行。
我们看一下，消息对象是如何构建的。
private static final int MAX_POOL_SIZE = 50;
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}
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方法，获取一个消息对象。
- 构建消息对象，这个sPool是一个缓存队列，是一个链表，维护的大小是MAX_POOL_SIZE。
- 当我们发送消息的时候就会构建一个消息对象，这个消息对象被使用之后，会清除标记位，放到缓存队列，方便下一次使用。
- 所以，经常建议，我们自己在构造Message对象的时候，不要new，要通过obtain方法获取。
- 获得消息对象之后，把当前的Runnable绑定到消息对象上，方便当前消息被执行的时候，回到给到外界。
值得学习的地方：这个缓存很值得我们学习，比如RecyclerView的缓存池。为什么呢？很多人说，不就是一个缓存吗，有很大用吗？不不不，很有用。首先我们要支持哪些场景需要缓存？
如果你的使用场景，存在频繁创建对象的时候，就需要用到缓存复用的思想。如果场景比较单一，大可不必（如果追求极致，使用也不是不可以。），比如Message对象的构建，频繁发生，如果频繁的创建对象，但是没有复用。那么就会导致虚拟机频繁GC，导致内存抖动，一旦GC就会Stop the world。带来的后果也是致命的，可能给用户直接的感受，就是卡顿，所以这点在性能优化上也很重要。
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
这个时候，获取系统开机时间，加上延迟执行的时间，就是预期消息执行的时间。很好理解。
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);
}
这里需要注意的是，mAsynchronous，如果这个值是true，就意味着，当前handler发送的消息都是异步消息，默认都是同步消息。这个和同步屏障有关，不要被名字迷惑了，很简单，后面说。
- 当前消息的target是当前的handler，持有一个引用
- 这个也就是一些内存泄露的原因，handler持有activity，Message持有handler，messagQueue持有message，MessageQueue主线程一直存在运行，导致Activity泄露。
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;
}
这个就是具体的，消息入队列的行为，Java层的行为。
- 首先判断mQuitting，如果当前消息循环关闭了，直接返回false。
- 没有很复杂，很好懂，就是拿到当前msg的预期执行时间，并且插到消息链表中，消息链表是根据时间先后排列的。
- needWake，需要唤醒消息循环
- 如果当前消息队列是空的，当前插入了一条消息，成为了头结点，需要把阻塞的消息轮询唤醒。很好理解，没有消息的时候，这个时候就会处于阻塞休眠状态，有了新的消息加入，如果阻塞就需要唤醒。
- 如果当前消息是最早的异步消息并且预期执行时间靠前，并且消息头结点是消息屏障，也需要换新阻塞状态的消息轮询。同样的，如果有消息屏障，会拦截同步消息，只会处理了异步消息。如果这个时候来了新的优先级更高的异步消息，就需要把阻塞态唤醒，如果优先级不高，前面的异步消息都在休眠，你着急个啥嘛，哈哈哈
处理消息
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));
}
首先是准备Looper，这个只能初始化一次，并且是ThreadLocal的，Looper适合线程绑定的，也就是说，是线程安全的，这个也是通过Handler实现线程切换的重要的一环。
public static void loop() {
final Looper me = myLooper();
......
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
......
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);
}
}
......
msg.recycleUnchecked();
}
}
这个也很好理解，通过消息队列MessageQueue获取消息，执行这个消息，并回收这个消息对象。
- 首先通过next()方法，去一个消息出来。
- msg.target.dispatchMessage(msg)，每一个消息持有一个handler的引用，回调给handler，去处理这个事件。
- msg.recycleUnchecked()，把这个消息重置，放到sPool缓存，方便下次使用。
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;
}
}
这个就是消息的具体轮询操作，依旧是一个死循环，知道有消息返回，否则我们就休眠，我们一起看看。
- nativePollOnce(ptr, nextPollTimeoutMillis) 这个方法是调用Native方法，休眠用的。我们之前说过，每一个Msg都有一个预期执行的时间，如果当前一个消息也没有获取到，也不会直接退出循环，会直接循环。具体的大家可以了解一下Epoll（现在面试也问，真他妈卷。）
- msg != null && msg.target == null，如果存在消息屏障，直接遍历message链表，找到异步消息，直接返回。
- 否则，就直接遍历链表，找到第一个节点（第一个节点预期执行时间最早），如果该执行了就直接返回，如果时间没找到，就阻塞等待。
- 如果还是没有找到消息msg对象，这个时候，就找到IdleHandler执行。
- IdleHandler，之前我来快手面过，我还不知道是啥？哈哈哈，这个IdleHandler就是等待没有消息执行，空闲的时候，执行。
- IdleHandler，通过不同的返回值，可以执行一次移除，还可以常驻，空闲就会重新执行一次。（我工作中目前没有用过，我们可以自行看看系统中哪些用到IdleHandler）。
什么是消息屏障
我之前第一次听说这个名词，也感觉很蒙，啥玩意儿，这么高深吗？难道有什么黑科技？其实不是，我们的消息执行，消息其实是一系列的Message，这些Message都有一个时间戳，标识当前要执行的时间。但是如果来了一条紧急的消息怎么办呢？是的，屏障的作用就体现了。
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;
}
}
一般我们构建Handler的实收或者创建Message对象的时候，传递asyncChronous=true，设置屏障消息。这里是MessageQueue设置消息屏障。
- 首先构造一个消息对象，设置特殊的标记位置。handler=null，回顾之前，我们发送消息的时候，都会把消息打上一个handler的引用，标识这个Msg是由哪一个handler发出来的。这里不需要，屏障消息不需要给handler反馈，就是充当消息队列的一个标识。
- 遍历消息队列，消息队列是根据执行时间从前到后排列的。屏障消息也是一样的，根据when插入到消息链表之中。
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());
}
在MessageQueue的next()方法获取消息的时候，如果当前存在消息屏障（msg.handler==null），这个时候，就获取消息屏障之后的异步消息（asyncChronous=true），忽略同步消息。（消息屏障在使用完毕之后，记得及时移除，否则屏障后面的同步消息就会得不到执行。）
所以消息屏障的目的就是优先处理异步消息，在Android绘制的时候，scheduleTraversals也是会发送一个这样的消息，目的就是保证绘制优先执行，UI尽可能快速的展示，防止画面出现卡顿。
自己的Handler
Handler不是主线程特有的，任何一个线程都可以有一个自己的Handler，实现自己的消息队列，具体的方式如下。
使用流程
val threadWithLooper = object : Thread() {
var threadLooper: Looper? = null
override fun run() {
Looper.prepare()
threadLooper = Looper.myLooper()
Looper.loop()
}
}
- 首先我们构建一个Thread，然后在run方法（线程启动的时候），启动消息循环
- 首先prepare，通过ThreadLocal构建一个Looper对象。（如果有人关心MessageQueue，这个也是在Looper初始化一起创建创建的，Looper适合MessageQueue绑定的，一比一的）。
- 然后把Looper取出来保存成局部变量。
这样会有什么问题吗？是的，并发问题。这是一个异步线程，如果你在主线程或者其他线程，要创建Handler，去获取ThreadWithLooper的Looper，这个时候Looper可能还没有创建好，出现问题，我们就不得不在获取Looper加锁了。那么有么有好的方式呢？是的，HandlerThread。我们一起看看。
HandlerThread
@Override
public void run() {
mTid = Process.myTid();
Looper.prepare();
synchronized (this) {
mLooper = Looper.myLooper();
notifyAll();
}
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
}
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;
}
为了保证安全，一定可以获得Looper，做了如下：
- 首先，在获取getLooper的时候，如果获取不到（looper是null），这个时候就wait阻塞，while循环，直到looper成功赋值。
- 在run方法的时候，给mLooper赋值，赋值成功之后，调用notifyAll，唤醒那些为了获取Looper，处于wait状态的线程。
系统是怎么创建的？
我们知道App的入口，其实就是ActivityThread，从main函数入口的。当应用点开，进程创建，就会反射创建ActivityThread，就开始构建消息的循环。
public static void main(String[] args) {
......
Looper.prepareMainLooper();
......
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
没有什么区别，也是先准备Looper，然后让消息队列循环起来。会不会有人问，为啥没有和HandlerThread一样，加锁，wait，以及notifyAll？我个人理解，因为这个是进程创建，刚开始的时候会就反射执行main方法，准备Looper，这个时候视图也没有创建，也不会有什么需求用到Handler去进行线程切换，去执行一些任务非要在主线程，应该是有依赖顺序的。
总结
Handler我们可以学到的，总结一下：
- handler，looper，queue之间的关系，分别是处理消息，获取消息，存消息，按照时间先后执行。
- 他们之间的数量关系，N：1：1的，handler是一个发送和处理的媒介，实现线程的切换。后面两者才是消息转起来的核心。
- 知道IdleHandler是什么东西，实现空闲调用。
- 知道常见内存泄露怎么引起的，怎么解决。
- HandlerThread的出现
- 可以异步调用，处理一些稍中的任务，不阻塞UI线程。当然和线程池比起来还是有不足，毕竟单线程的。
- 简化实现消息机制实现，解决并发打来的looper没有准备好的问题。
扩展学习：
- 学习缓存队列，MSG的复用。
- 这个很有用，别面对象大量创建，频繁GC。
