【拒绝一问就懵】之从Thread讲到Handle
背景介绍
咱们在Android开发过程当中，几乎都离不开线程。可是你对线程的了解有多少呢？它完美运行的背后，究竟隐藏了多少鲜为人知的秘密呢？线程间互通暗语，传递信息到底是如何作到的呢？Looper、Handler、MessageQueue究竟在这背后进行了怎样的运做。本期，让咱们一块儿从Thread开始，逐步探寻这个完美的线程链背后的秘密。
注意，大部分分析在代码中，因此请仔细关注代码哦！php
从Tread的建立流程开始
在这一个环节，咱们将一块儿一步步的分析Thread的建立流程。
话很少说，直接代码里看。java
线程建立的起始点init()
// 建立Thread的公有构造函数，都调用的都是这个私有的init()方法。咱们看看到底干什么了。
/** * * @param 线程组 * @param 就是咱们平时接触最多的Runnable同窗 * @param 指定线程的名称 * @param 指定线程堆栈的大小 */
private void init(ThreadGroup g, Runnable target, String name, long stackSize) {
// 获取当前正在运行的线程
// 当前正在运行的线程就是该咱们要建立的线程的父线程
// 咱们要建立的线程会从父线程那继承一些参数过来
// 注意哦，此时仍然是在原来的线程，新线程此时尚未建立的哦！
Thread parent = currentThread();
if (g == null) {
g = parent.getThreadGroup(); //若是没有指定ThreadGroup，将获取父线程的TreadGroup
}
g.addUnstarted(); //将ThreadGroup中的就绪线程计数器增长一。注意，此时线程还并无被真正加入到ThreadGroup中。
this.group = g; //将Thread实例的group赋值。从这里开始线程就拥有ThreadGroup了。
this.target = target; //给Thread实例设置Runnable。之后start()的时候执行的就是它了。
this.priority = parent.getPriority(); //设置线程的优先权重为父线程的权重
this.daemon = parent.isDaemon(); //根据父线程是不是守护线程来肯定Thread实例是不是守护线程。
setName(name); //设置线程的名称
init2(parent); //纳尼？又一个初始化，参数仍是父线程。不急，稍后在看。
/* Stash the specified stack size in case the VM cares */
this.stackSize = stackSize; //设置线程的堆栈大小
tid = nextThreadID(); //线程的id。这是个静态变量，调用这个方法会自增，而后做为线程的id。
}
复制代码
在Thread的init()方法中，比较重要的是会经过一个currentThread()这样的native函数经过底层从虚拟机中获取到当前运行的线程。android
因此在Thread初始化的时候，仍然是在建立它的线程中。不难猜想出，其实Java层的Thread只是对底层的封装而已。c++
第二个init2()
private void init2(Thread parent) {
this.contextClassLoader = parent.getContextClassLoader(); //设置ClassLoader成员变量
this.inheritedAccessControlContext = AccessController.getContext(); //设置访问权限控制环境
if (parent.inheritableThreadLocals != null) {
this.inheritableThreadLocals = ThreadLocal.createInheritedMap( //建立Thread实例的ThreadLoacaleMap。须要用到父线程的ThreadLocaleMap，目的是为了将父线程中的变量副本拷贝一份到当前线程中。
//ThreadLocaleMap是一个Entry型的数组，Thread实例会将变量副本保存在这里面。
parent.inheritableThreadLocals);
}
}
复制代码
至此，咱们的Thread就初始化完成了，Thread的几个重要成员变量都赋值了。数组
启动线程，开车啦！
一般，咱们这样了启动一条线程。缓存
Thread threadDemo = new Thread(() -> {
});
threadDemo.start();
复制代码
那么start()背后究竟隐藏着什么样不可告人的秘密呢？是人性的扭曲？仍是道德的沦丧？让咱们一块儿点进start()。探寻start()背后的秘密。安全
//如咱们所见，这个方法是加了锁的。缘由是避免开发者在其它线程调用同一个Thread实例的这个方法，从而尽可能避免抛出异常。
//这个方法之因此可以执行咱们传入的Runnable里的run()方法，是应为JVM调用了Thread实例的run()方法。
public synchronized void start() {
//检查线程状态是否为0，为0表示是一个新状态，即还没被start()过。不为0就抛出异常。
//就是说，咱们一个Thread实例，咱们只能调用一次start()方法。
if (threadStatus != 0)
throw new IllegalThreadStateException();
//从这里开始才真正的线程加入到ThreadGroup组里。再重复一次，前面只是把nUnstartedThreads这个计数器进行了增量，并无添加线程。
//同时，当线程启动了以后，nUnstartedThreads计数器会-1。由于就绪状态的线程少了一条啊！
group.add(this);
started = false;
try {
//又是个Native方法。这里交由JVM处理，会调用Thread实例的run()方法。
nativeCreate(this, stackSize, daemon);
started = true;
} finally {
try {
if (!started) {
group.threadStartFailed(this); //若是没有被启动成功，Thread将会被移除ThreadGroup，同时，nUnstartedThreads计数器又增量1了。
}
} catch (Throwable ignore) {
}
}
}
复制代码
好把，最精华的函数是nativeCreate(this, stackSize, daemon)，会去调用底层的JNI函数Thread_nativeCreate()，进一步的会调用底层的Thread类的Thread::CreateNativeThread()函数。数据结构
Thread::CreateNativeThread()函数在/art/runtime/thread.cc文件中（注：CoorChice用的是6.0.0-r1的源码）。它会在去建立一个c/c++层的Thread对象，而且会关联Java层的Thread对象（其实就是保存一个Java层Thread对象的引用而已）。接着，会经过c/c++层的pthread_create()函数去建立并启动一个新线程。这条代码必需要看看了：多线程
pthread_create_result = pthread_create(&new_pthread, &attr,
Thread::CreateCallback, child_thread);
复制代码
这里咱们须要注意第三个参数位置的Thread::CreateCallback，它会返回一个Java层Thread类的run()方法指针，在Linux层的pthread线程建立成功后，将会调用这个run()方法。这就是为何咱们调用start()方法后，run()方法会被调用的缘由。并发
从上面的分析咱们能够知道，其实Java的线程Thread仍是用的Linux那一套 pthread 的东西，而且一条线程真正建立并运行在虚拟机中时，是在调用start()方法以后。因此，若是你建立了一条线程，可是从没调用过它的start()方法，就不会有条新线程生成，此时的Thread对象和主线程里的一个普通对象没什么区别。若是你企图调用 run() 方法去试图启动你的线程，那真是大错特错了！这样不过至关于在主线程中调用了一个Java方法而已。
因此，Java中的线程在Android中实际上走的仍是Linux的pthread那一套。
//没错，就是这么简单！仅仅调用了Runnable类型的成员变量target的run()方法。至此，咱们须要执行的代码就执行起来了。
//至于这个@Overrid的存在，彻底是由于Thread自己也是一个Runnable！就是说，咱们的Thread也能够做为一个Runnable来使用。
@Override
public void run() {
if (target != null) {
target.run();
}
}
复制代码
看，若是不调用start()方法，你能够把Thread看成一个Handler去使用！！
public void test_1() {
Thread thread1 = new Thread(() -> {
System.out.println(Thread.currentThread().getName());
}, "Thread_1");
Thread thread2 = new Thread(thread1, "Thread_2");
thread2.start();
}
---
输出：
Thread_2
复制代码
几个常见的线程手段(操做)
Thread.sleep()那不可告人的秘密
咱们平时使用Thread.sleep()的频率也比较高，因此咱们在一块儿研究研究Thread.sleep()被调用的时候发生了什么。
在开始以前，先介绍一个概念——纳秒。1纳秒=十亿分之一秒。可见用它计时将会很是的精准。可是因为设备限制，这个值有时候并非那么准确，但仍是比毫秒的控制粒度小不少。
//平时咱们调用的Thread.sleep(long)最后调用到这个方法来，后一个陌生一点的参数就是纳秒。
//你能够在纳秒级控制线程。
public static void sleep(long millis, int nanos) throws InterruptedException {
//下面三个检测毫秒和纳秒的设置是否合法。
if (millis < 0) {
throw new IllegalArgumentException("millis < 0: " + millis);
}
if (nanos < 0) {
throw new IllegalArgumentException("nanos < 0: " + nanos);
}
if (nanos > 999999) {
throw new IllegalArgumentException("nanos > 999999: " + nanos);
}
if (millis == 0 && nanos == 0) {
if (Thread.interrupted()) { //当睡眠时间为0时，检测线程是否中断，并清除线程的中断状态标记。这是个Native的方法。
throw new InterruptedException(); //若是线程被设置了中断状态为true了(调用Thread.interrupt())。那么他将抛出异常。若是在catch住这个异常以后return线程，那么线程就中止了。
//须要注意，在调用了Thread.sleep()以后，再调用isInterrupted()获得的结果永远是False。别忘了Thread.interrupted()在检测的同时还会清除标记位置哦！
}
return;
}
long start = System.nanoTime(); //相似System.currentTimeMillis()。可是获取的是纳秒，可能不许。
long duration = (millis * NANOS_PER_MILLI) + nanos;
Object lock = currentThread().lock; //得到当前线程的锁。
synchronized (lock) { //对当前线程的锁对象进行同步操做
while (true) {
sleep(lock, millis, nanos); //这里又是一个Native的方法，而且也会抛出InterruptedException异常。
//据我估计，调用这个函数睡眠的时长是不肯定的。
long now = System.nanoTime();
long elapsed = now - start; //计算线程睡了多久了
if (elapsed >= duration) { //若是当前睡眠时长，已经知足咱们的需求，就退出循环，睡眠结束。
break;
}
duration -= elapsed; //减去已经睡眠的时间，从新计算须要睡眠的时长。
start = now;
millis = duration / NANOS_PER_MILLI; //从新计算毫秒部分
nanos = (int) (duration % NANOS_PER_MILLI); //从新计算微秒部分
}
}
}
复制代码
经过上面的分析能够知道，使线程休眠的核心方法就是一个Native函数sleep(lock, millis, nanos)。这个sleep()对应底层的一个JNI函数，这个JNI函数最终会调用到c/c++中对应的Thread的条件变量的 TimedWait()函数。这个条件变量是应该是Android中本身定义的条件变量，固然，这里的TimedWait()函数天然也是Android本身实现的。在这个函数里，Android直接使用了Linux的futex()函数。这个futex()函数会调用syscall()函数，经过一种名为【快速用户区互斥锁】的锁去执行锁定的。futex()的效率比phtread_cond_wait()要高不少。
Android为了确保休眠的准确性，在这里还使用了一个while()循环，在每次线程从底层被唤醒后，检查一下是否休眠够了足够的时长。若是不够就让它继续休眠。
同时，须要注意一点，若是线程的interruted状态在调用sleep()方法时被设置为true，那么在开始休眠循环前会抛出InterruptedException异常。
Thread.yield()究竟隐藏了什么？
这个方法是Native的。调用这个方法能够提示cpu，当前线程将放弃目前cpu的使用权，和其它线程从新一块儿争夺新的cpu使用权限。当前线程可能再次得到执行，也可能没得到。就酱。
无处不在的wait()到底是什么？
你们必定常常见到，不管是哪个对象的实例，都会在最下面出现几个名为wait()的方法。等待？它们到底是怎样的一种存在，让咱们一块儿点击去看看。
哎哟我去，都是Native函数啊。
那就看看文档它究竟是什么吧。
根据文档的描述，wait()配合notify()和notifyAll()可以实现线程间通信，即同步。在线程中调用wait()必须在同步代码块中调用，不然会抛出IllegalMonitorStateException异常。由于wait()函数须要释放相应对象的锁。当线程执行到wait()时，对象会把当前线程放入本身的线程池中，而且释放锁，而后阻塞在这个地方。直到该对象调用了notify()或者notifyAll()后，该线程才能从新得到，或者有可能得到对象的锁，而后继续执行后面的语句。
呃。。。好吧，在说明一下notify()和notifyAll()的区别。
- notify()
调用notify()后，对象会从本身的线程池中(也就是对该对象调用了wait()函数的线程)随机挑选一条线程去唤醒它。也就是一次只能唤醒一条线程。若是在多线程状况下，只调用一次notify()，那么只有一条线程能被唤醒，其它线程会一直在 - notifyAll()
调用notifyAll()后，对象会唤醒本身的线程池中的全部线程，而后这些线程就会一块儿抢夺对象的锁。
扒一扒Looper、Handler、MessageQueue之间的爱恨情仇
咱们可能过去都写过形如这样的代码：
new Thread(()->{
...
Looper.prepare();
Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
Looper.loop();
}).start()
复制代码
不少同窗知道，在线程中使用Handler时(除了Android主线程)必须把它放在Looper.prepare()和Looper.loop()之间。不然会抛出RuntimeException异常。可是为何要这么作呢？下面咱们一块儿来扒一扒这其中的内幕。
从Looper.prepare()开始
当Looper.prepare()被调用时，发生了什么？
public static void prepare() {
prepare(true); //最终其实执行的是私有方法prepare(boolean quitAllowed)中的逻辑
}
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) { //先尝试获取是否已经存在一个Looper在当前线程中，若是有就抛个异常。
//这就是为何咱们不能在一个Thread中调用两次Looper.prepare()的缘由。
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed)); //首次调用的话，就建立一个新的Looper。
}
//Looper的私有构造函数
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed); //建立新的MessageQueue，稍后在来扒它。
mThread = Thread.currentThread(); //把当前的线程赋值给mThread。
}
复制代码
通过上面的分析，咱们已经知道Looper.prepare()调用以后发生了什么。
可是问题来了！sThreadLocal是个静态的ThreadLocal<Looper> 实例(在Android中ThreadLocal的范型固定为Looper)。那么，Looper.prepare()既然是个静态方法，Looper是如何肯定如今应该和哪个线程创建绑定关系的呢？咱们接着往里扒。
来看看ThreadLocal的get()、set()方法。
public void set(T value) {
Thread t = Thread.currentThread(); //一样先获取到当前的线程
ThreadLocalMap map = getMap(t); //获取线程的ThreadLocalMap
if (map != null)
map.set(this, value); //储存键值对
else
createMap(t, value);
}
public T get() {
Thread t = Thread.currentThread(); //重点啊！获取到了当前运行的线程。
ThreadLocalMap map = getMap(t); //取出当前线程的ThreadLocalMap。这个东西是个重点，前面已经提到过。忘了的同窗在前面再看看。
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
//能够看出，每条线程的ThreadLocalMap中都有一个<ThreadLocal,Looper>键值对。绑定关系就是经过这个键值对创建的。
if (e != null)
return (T)e.value;
}
return setInitialValue();
}
复制代码
ThreadLocal是Looper类中的静态常量，因此它对全部线程来讲都是可见的。从上面代码也能够看出，调用ThreadLocal的set/get方法，实际操做的是Thread的ThreadLocalMap，也就是说每一个Thread的ThreadLocalMap是Thread私有的。这样的设计，使得即便在并发的状况下，每一个线程都invoke ThreadLocal的get/set方法，可是因为每一个线程实际操做的都是本身的ThreadLocalMap，互不影响，因此是线程安全的。关于线程的内存你能够在CoorChice的这两篇文章中找到点线索：《【拒绝一问就懵】之有必要单独讲讲线程：https://juejin.im/post/5cdc164af265da0353790245》，《【拒绝一问就懵】之你多少要懂点内存回收机制：https://juejin.im/post/5cdc0faf51882568666dfe2f》。
思考一下：即然TheadLocalMap是每一个线程本身持有的，为何每次使用的是时候不直接取得Thread以后，而后再取得它的ThreadLocalMap来操做，而是要经过ThreadLocal去间接的操做呢？
这样设计主要仍是为了将逻辑分离出去，由于实现方案可能会改变。若是之后修改了ThreadLocalMap的管理逻辑，只要接口功能没变，Looper和Thread就不会受到影响。而这套逻辑也能够直接拿来给其它方案使用。便于修改，便于复用。
建立Handler
Handler能够用来实现线程间的通行。在Android中咱们在子线程做完数据处理工做时，就经常须要经过Handler来通知主线程更新UI。平时咱们都使用new Handler()来在一个线程中建立Handler实例，可是它是如何知道本身应该处理那个线程的任务呢。下面就一块儿扒一扒Handler。
public Handler() {
this(null, false);
}
public Handler(Callback callback, boolean async) { //能够看到，最终调用了这个方法。
if (FIND_POTENTIAL_LEAKS) {
final Class<? extends Handler> 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(); //重点啊！在这里Handler和当前Thread的Looper绑定了。Looper.myLooper()就是从ThreadLocale中取出当前线程的Looper。
if (mLooper == null) {
//若是子线程中new Handler()以前没有调用Looper.prepare()，那么当前线程的Looper就还没建立。就会抛出这个异常。
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue; //赋值Looper的MessageQueue给Handler。
mCallback = callback;
mAsynchronous = async;
}
复制代码
Looper.loop()
咱们都知道，在Handler建立以后，还须要调用一下Looper.loop()，否则发送消息到Handler没有用！接下来，扒一扒Looper究竟有什么样的魔力，可以把消息准确的送到Handler中处理。
public static void loop() {
final Looper me = myLooper(); //这个方法前面已经提到过了，就是获取到当前线程中的Looper对象。
if (me == null) {
//没有Looper.prepare()是要报错的！
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue; //获取到Looper的MessageQueue成员变量，这是在Looper建立的时候new的。
//这是个Native方法，做用就是检测一下当前线程是否属于当前进程。而且会持续跟踪其真实的身份。
//在IPC机制中，这个方法用来清除IPCThreadState的pid和uid信息。而且返回一个身份，便于使用restoreCallingIdentity()来恢复。
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) { //重点(敲黑板)！这里是个死循环，一直等待抽取消息、发送消息。
Message msg = queue.next(); // 从MessageQueue中抽取一条消息。至于怎么取的，咱们稍后再看。
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);
}
final long traceTag = me.mTraceTag; //取得MessageQueue的跟踪标记
if (traceTag != 0) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg)); //开始跟踪本线程的MessageQueue中的当前消息，是Native的方法。
}
try {
msg.target.dispatchMessage(msg); //尝试分派消息到和Message绑定的Handler中
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag); //这个和Trace.traceBegin()配套使用。
}
}
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
final long newIdent = Binder.clearCallingIdentity(); //what？又调用这个Native方法了。这里主要是为了再次验证，线程所在的进程是否发生改变。
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(); //回收释放消息。
}
}
复制代码
从上面的分析能够知道，当调用了Looper.loop()以后，线程就就会被一个for(;;)死循环阻塞，每次等待MessageQueue的next()方法取出一条Message才开始往下继续执行。而后经过Message获取到相应的Handler (就是target成员变量)，Handler再经过dispatchMessage()方法，把Message派发到handleMessage()中处理。
这里须要注意，当线程loop起来是时，线程就一直在循环中。就是说Looper.loop()后面的代码就不能被执行了。想要执行，须要先退出loop。
Looper myLooper = Looper.myLoop();
myLooper.quit(); //普通退出方式。
myLooper.quitSafely(); //安全的退出方式。
复制代码
如今又产生一个疑问，MessageQueue的next()方法是如何阻塞住线程的呢？接下来，扒一扒这个幕后黑手MessageQueue。
幕后黑手MessageQueue
MessageQueue是一个用单链的数据结构来维护消息列表。
Message next() {
//检查loop是否已经为退出状态。mPrt是Native层的MessageQueue的地址。经过这个地址能够和Native层的MessageQueue互动。
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1;
int nextPollTimeoutMillis = 0; //时间标记，当且仅当第一次获取消息时才为0。由于它在死循环外面啊！
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
//若是不是第一次获取消息，调用Native的函数，让虚拟机刷新全部的饿Binder命令，确保进程在执行可能阻塞的任务以前，释放以前的对象。
}
//这是一个Native的方法。
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) { //锁住MessageQueue
//获取当前的系统时间，用于后面和msg.when进行比较。
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages; //得到当前MessageQueue中的第一条消息
if (msg != null && msg.target == null) {
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) { //这个判断的意义在于只有到了Message应该被发送的时刻才去发送，不然继续循环。
//计算下一条消息的时间。注意最大就是Integer.MAX_VALUE。
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; //返回一条消息给Looper。
}
} else {
// 若是取到的Message为null，将时间标记设置为-1。
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;
}
}
复制代码
能够看到。MessageQueue在取消息(调用next())时，会进入一个死循环，直到取出一条Message返回。这就是为何Looper.loop()会在queue.next()处等待的缘由。
在这个方法中须要注意一个参数mPtr，它是底层的MessageQueue对象的地址。就是说Android的c/c++层也有一套与Java层对应的Handler机制，而咱们的MessageQueue因为持有了一个底层的引用，天然就成了Java层的Handler机制和底层的沟通桥梁了。
上面方法中出现了一个nativePollOnce(ptr, nextPollTimeoutMillis);函数的调用。线程会被阻塞在这个地方。这个native方法会调用到底层的JNI函数android_os_MessageQueue_nativePollOnce()，进一步调用c/c++层的nativeMessageQueue的pollOnce()函数，在这个函数中又会经过本线程在底层的Looper的pollOnce()函数，进而调用pollInner()函数。在pollInner()函数中会调用epoll_wait()函数，这个函数会将线程阻塞在这，直到被超时或者检测到pipe中有事件发生。那么阻塞在这怎么唤醒呢，咱们下面在说。
那么，一条Message是如何添加到MessageQueue中呢？要弄明白最后的真相，咱们须要调查一下mHandler.post()这个方法。
Handler究竟对Message作了什么？
Handler的post()系列方法，最终调用的都是下面这个方法：
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this; //在这里给Message的target赋值。
if (mAsynchronous) {
msg.setAsynchronous(true); //若是是异步，就标记为异步
}
return queue.enqueueMessage(msg, uptimeMillis); //就是这个方法把Message添加到线程的MessageQueue中的。
}
复制代码
接下来就看看MessageQueue的enqueueMessage()做了什么。
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) { //没Handler调用是会抛异常的啊
throw new IllegalArgumentException("Message must have a target.");
}
if (msg.isInUse()) { //不能使用一条正在使用中的Message。
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) { //锁住MessageQueue再往里添加消息。
if (mQuitting) { //若是MessageQueue被标记为退出，就返回。
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(); //切换Message的使用状态为未使用。
msg.when = when; //咱们设置的延迟发送的时间。
//通过下面的逻辑，Message将会被“储存”在MessageQueue中。实际上，Message在MessageQueue中的储存方式，
//是使用Message.next逐个向后指向的单链表结构来储存的。好比：A.next = B, B.next = C...
Message p = mMessages; //尝试获取当前Message
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// 若是为null，说明是第一条。
msg.next = p;
mMessages = msg; //设置当前的Message为传入的Message，也就是做为第一条。
needWake = mBlocked;
} else {
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
//不知足做为第一条Message的条件时，经过下面的逐步变换，将它放在最后面。这样便把Message“储存”到MessageQueue中了。
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p;
prev.next = msg;
}
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
复制代码
上一节面CoorChice说过，MessageQueue在next()方法中会阻塞在nativePollOnce()这个地方，其实是阻塞在了底层的Looper的epoll_wait()这个地方等待唤醒呢。看到上面这段代码的最后面没？nativeWake()，赤裸裸的代表就是唤醒。实际上这个nativeWake()函数代表pipe写端有write事件发生，从而让epoll_wait()退出等待。
至此，咱们已经揭露了Looper、Handler、MessageQueue隐藏的秘密。
另外一个疑问？
也许你已经注意到在主线程中能够直接使用Handler，而不须要Looper.prepare()和Looper.loop()。为何能够作到这样呢？根据以前的分析能够知道，主线程中必然存在Looper.prepare()和Looper.loop()。既然如此，为何主线程没有被loop()阻塞呢？看一下ActivityThread来弄清楚究竟是怎么回事。
//这个main()方法能够认为是Android应用的起点
public static void main(String[] args) {
。
。
。
Looper.prepareMainLooper(); //主要做用和咱们平时调用的Looper.prepare()差很少
ActivityThread thread = new ActivityThread(); //建立本类实例
thread.attach(false);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler(); //重点啊！这里取得了处理主线程事物的Handler。
}
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
Looper.loop(); //开始循环。能够看到，主线程本质上是阻塞的！
。
。
。
}
复制代码
注意ActivityThread并无继承Thread，它的Handler是继承Handler的私有内部类H.class。在H.class的handleMessage()中，它接受并执行主线程中的各类生命周期状态消息。UI的16ms的绘制也是经过Handler来实现的。也就是说，主线程中的全部操做都是在Looper.prepareMainLooper()和Looper.loop()之间进行的。进一步说是在主Handler中进行的。
总结
- Android中Thread在建立时进行初始化，会使用当前线程做为父线程，并继承它的一些配置。
- Thread初始化时会被添加到指定/父线程的ThreadGroup中进行管理。
- Thread正真启动是一个native函数完成的。
- 在Android的线程间通讯中，须要先建立Looper，就是调用Looper.prepare()。这个过程当中会自动依赖当前Thread，而且建立MessageQueue。通过上一步，就能够建立Handler了，默认状况下，Handler会自动依赖当前线程的Looper，从而依赖相应的MessageQueue，也就知道该把消息放在哪一个地方了。MessageQueue经过Message.next实现了一个单链表结构来缓存Message。消息须要送达Handler处理，还必须调用Looper.loop()启动线程的消息泵送循环。loop()内部是无限循环，阻塞在MessageQueue的next()方法上，由于next()方法内部也是一个无限循环，直到成功从链表中抽取一条消息返回为止。而后，在loop()方法中继续进行处理，主要就是把消息派送到目标Handler中。接着进入下一次循环，等待下一条消息。因为这个机制，线程就至关于阻塞在loop()这了。
通过上面的揭露，咱们已经对线程及其相互之间通信的秘密有所了解。掌握了这些之后，相信在之后的开发过程当中咱们能够思路清晰的进行线程的使用，而且可以吸取Android在设计过程当中的精华思想。
感受不错就关注我，都不干就点个赞！😘
- 1. 【拒绝一问就懵】之有必要单独讲讲线程
- 2. 【拒绝一问就懵】之Activity的启动流程
- 3. 【拒绝一问就懵】之没据说过内存抖动吧
- 4. 【拒绝一问就懵】之不可忽视的内存泄露
- 5. 【拒绝一问就懵】之你多少要懂点内存回收机制
- 6. jmap Exception in thread "main" java.io.IOException: 拒绝访问。
- 7. Python 之 pip拒绝访问
- 8. java.io.FileNotFoundException: ……(拒绝访问。)
- 9. java.io.FileNotFoundException (拒绝访问。)
- 10. 运行rsop.msc 访问遭到拒绝
- 更多相关文章...
- • Rust 输出到命令行 - RUST 教程
- • 一对一关联查询 - MyBatis教程
- • RxJava操作符（一）Creating Observables
- • Kotlin学习（一）基本语法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. python的安装和Hello，World编写
- 2. 重磅解读：K8s Cluster Autoscaler模块及对应华为云插件Deep Dive
- 3. 鸿蒙学习笔记2（永不断更）
- 4. static关键字 和构造代码块
- 5. JVM笔记
- 6. 无法启动 C/C++ 语言服务器。IntelliSense 功能将被禁用。错误: Missing binary at c:\Users\MSI-NB\.vscode\extensions\ms-vsc
- 7. 【Hive】Hive返回码状态含义
- 8. Java树形结构递归（以时间换空间）和非递归（以空间换时间）
- 9. 数据预处理---缺失值
- 10. 都要2021年了，现代C++有什么值得我们学习的？
- 1. 【拒绝一问就懵】之有必要单独讲讲线程
- 2. 【拒绝一问就懵】之Activity的启动流程
- 3. 【拒绝一问就懵】之没据说过内存抖动吧
- 4. 【拒绝一问就懵】之不可忽视的内存泄露
- 5. 【拒绝一问就懵】之你多少要懂点内存回收机制
- 6. jmap Exception in thread "main" java.io.IOException: 拒绝访问。
- 7. Python 之 pip拒绝访问
- 8. java.io.FileNotFoundException: ……(拒绝访问。)
- 9. java.io.FileNotFoundException (拒绝访问。)
- 10. 运行rsop.msc 访问遭到拒绝