从源码角度分析Android的消息机制
前言
说到Android的消息机制,那么主要的就是指的Handler的运行机制。其中包括MessageQueue以及Looper的工作过程。
在开始正文之前,先抛出两个问题:
- 为什么更新UI的操作要在主线程中进行?
- Android中为什么主线程不会因为Looper.loop()里的死循环卡死?
UI线程的判断是在ViewRootImpl中的checkThread方法中完成的。
对于第一个问题,这里给一个简单的回答:
如果可以在子线程中修改UI,多线程的并发访问可能会导致UI控件的不可预期性,采用加锁的方式,就会降低UI的访问效率以及会阻塞其他线程的执行,所以最简单有效的方法就是采用单线程模型来处理UI操作。
Handler的运行离不来底层的MessageQueue和Looper的支撑。MessageQueue翻译过来是一个消息队列,里面存储了Handler需要的Message,MessageQueue并不是一个队列,其实上是用单链表的数据结构来存储Message。
那么Handler如何拿到Message呢?这时候就需要Looper了,Looper通过Looper.loop()来开启一个死循环,不断从MessageQueue中取消息然后传递给Handler。
这里还有另一个知识点就是Looper的获取,这里就要提高一个存储类:ThreadLocal
ThreadLocal的工作原理
ThreadLocal是线程内部的一个数据存储类,可以存储某个线程中的数据,对于其他线程无法获取该线程的数据。我们通过原理来看一下,这个观点是否正确。
public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); } public T get() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return setInitialValue(); }
可以看出它的set和get方法就是在当前线程中所做的操作,ThreadLocalMap内部是一个数组table。 这样就保证了在不同线程中的数据互不干扰。
ThreadLocal除了使用在Handler中获取Looper,还用于一些复杂的场景,比如:监听器的传递。
我们简单了解了ThreadLocal,那么我们从New Handler()来一步步梳理下消息机制。
Looper的工作原理
// Handler.java public Handler() { this(null, false); } // callback 消息回调;async 是否同步 public Handler(Callback callback, boolean async) { ... // 1. 首先获取looper mLooper = Looper.myLooper(); if (mLooper == null) { throw new RuntimeException( "Can't create handler inside thread " + Thread.currentThread() + " that has not called Looper.prepare()"); } // 2. 获取MessggeQueue mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async; }
我们平常用的是无参数的方法,它传入的是空的回调以及false。
public static @Nullable Looper myLooper() { return sThreadLocal.get(); }
这里就出现了我们之前说的ThreadLoacal类,那么looper值是什么时候设置进去的呢?
它的设置方法其实是在prepare方法以及prepareMainLooper方法中,我们来分别来看下:
public static void prepare() { prepare(true); } private static void prepare(boolean quitAllowed) { // 在创建looper之前,判断looper是否与threadloacal绑定过,这也是prepare只能设置一遍的原因。 if (sThreadLocal.get() != null) { throw new RuntimeException("Only one Looper may be created per thread"); } sThreadLocal.set(new Looper(quitAllowed)); } public static void prepareMainLooper() { // 这里其实还是调用的prepare方法 prepare(false); synchronized (Looper.class) { if (sMainLooper != null) { throw new IllegalStateException("The main Looper has already been prepared."); } sMainLooper = myLooper(); } }
通过上面可以prepare方法只能设置一遍,那么我们在主线程中为什么能直接使用呢? app程序的入口是在ActivityThread中的main方法中:
public static void main(String[] args) { ... //1. 初始化Looper对象 Looper.prepareMainLooper(); // 2. 开启无限循环 Looper.loop(); throw new RuntimeException("Main thread loop unexpectedly exited"); }
看到了吧,初始化在这里,那么我们再来看下looper的初始化方法:
private Looper(boolean quitAllowed) { mQueue = new MessageQueue(quitAllowed); mThread = Thread.currentThread(); }
Looper的初始化做了两件事:创建消息队列MessageQueue以及获取当前的线程。 到这里,我们可以得到一个结论:
- prepare方法在一个线程中只能调用一次。
- Looper的初始化在一个线程中只能调用一次。
- 最后可以得知:一个线程对应一个Looper,一个Looper对应一个MessageQueue。
Looper可以理解为一个工厂线,不断从MessageQueue中取Message,工厂线开启的方式就是Looper.loop()
public static void loop() { final Looper me = myLooper(); // 1. 判断looper是否存在 if (me == null) { throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread."); } final MessageQueue queue = me.mQueue; ... //2. 开启一个死循环 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); dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0; } finally { if (traceTag != 0) { Trace.traceEnd(traceTag); } } ... } }
looper方法通过开启一个死循环,不断从MessageQueue中取Message消息,当message为空时,退出该循环,否则调用msg.target.dispatchMessage(msg)方法,target就是msg绑定的Handler对象。
Handler的工作原理
好了到这里又回到了Handler类中。
public void dispatchMessage(Message msg) { if (msg.callback != null) { handleCallback(msg); } else { if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } } handleMessage(msg); } }
这个handleMessage就是我们需要实现的方法。 那么Handler是如何设置到Message中的呢?我们来看下我们熟知的sendMessage方法:
public final boolean sendMessage(Message msg) { return sendMessageDelayed(msg, 0); } public final boolean sendMessageDelayed(Message msg, long delayMillis) { if (delayMillis < 0) { delayMillis = 0; } return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis); } public boolean sendMessageAtTime(Message msg, long uptimeMillis) { MessageQueue queue = mQueue; ... return enqueueMessage(queue, msg, uptimeMillis); } private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { // 关键代码来了! msg.target = this; if (mAsynchronous) { msg.setAsynchronous(true); } return queue.enqueueMessage(msg, uptimeMillis); }
可以看到,通过一系列的方法,在enqueueMessage中将handler赋值到msg的target中。最后调用的是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 { 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; }
enqueueMessage方法主要做了两件事:
首先判断handler是否存在以及是否在使用中。然后根据时间顺序插入MessageQueue中。
到这里基本的流程已经梳理完了,回到起初我们的问题:Looper.loop()是一个死循环,为什么不会堵塞主线程呢?
我们来看下MessageQueue的next方法:
Message next() { final long ptr = mPtr; if (ptr == 0) { return null; } int pendingIdleHandlerCount = -1; // -1 only during first iteration int nextPollTimeoutMillis = 0; for (;;) { nativePollOnce(ptr, nextPollTimeoutMillis); ... } }
nativePollOnce方法是一个 native 方法,当调用此 native 方法时,主线程会释放 CPU 资源进入休眠状态,直到下条消息到达或者有事务发生,通过往 pipe 管道写端写入数据来唤醒主线程工作,这里采用的 epoll 机制。关于 nativePollOnce 的详细分析可以参考:nativePollOnce函数分析
总结
- app程序启动从ActivityThread中的main方法中开始,通过Looper.prepare()进行Looper以及MessageQueue的创建以及ThreadLocal与线程之间的绑定。
- 我们在创建Handler时,通过ThreadLocal来获取该线程中的Looper以及在Looper上绑定的MessageQueue。
- 通过Handler.sendMessage()方法来将msg与Handler之间进行绑定,然后将msg通过时间顺序插入MessageQueue中。
- 主线程创建后,Looper.loop()来启动一个(不占用资源)死循环,从Looper已经存在的MessageQueue中不断取出Message,然后调用不为空的Message绑定的Handler的dispatchMessage(msg)方法,最后会调用我们复写的handlerMessage方法中。
参考资料
Androi开发艺术探索
以上就是从源码角度分析Android的消息机制的详细内容,更多关于Android 消息机制的资料请关注我们其它相关文章!