Android的消息机制主要是指Handler的运行机制,Handler的运行需要底层的MessageQueue和Looper的支撑。
MessageQueue消息队列,以队列的形式(实为单链表结构)对外提供插入和删除的工作,
Looper
以无限循环的形式不断获取MessageQueue中的消息,有则处理,无则等待。
ThreadLocal
ThreadLocal可以在不同的线程互不干扰的存储并提供数据,通过ThreadLocal可以很方便的获取每个线程的Looper
为什么要异步访问UI?
Android规定UI操作只能在主线程中执行,子线程执行UI操作则会抛出异常,在ViewRootImpl有如下方法:
void checkThread() { if (mThread != Thread.currentThread()) { throw new CalledFromWrongThreadException( "Only the original thread that created a view hierarchy can touch its views."); } }
显然对于UI这类耗时操作我们不可能全部放在主线程中执行,那么就要采用异步的方式。
系统为何不允许在子线程去访问UI?
原因很简单,Android的UI线程是线程不安全的
为什么不采用加锁的方式处理UI线程?
- 会增加UI访问的逻辑复杂度
- 降低UI访问效率
至此,我们对异步消息的处理机制和必要性有了一个简单的了解
假设有如下需求:在子线程中更新TextView的文本显示
实现方式一:
mHandler = new Handler() { @Override public void handleMessage(Message msg) { if (msg.what == 1) { tv.setText(msg.obj.toString()); } } }; tv = (TextView) findViewById(R.id.tv); new Thread(new Runnable() { @Override public void run() { Message msg = new Message(); msg.what = 1; msg.obj = "神荼"; mHandler.sendMessage(msg); } }).start();
实现方式二:
mHandler = new Handler(); mHandler.post(new Runnable() { @Override public void run() { tv.setText("神荼"); } });
实现方式三:
runOnUiThread(new Runnable() { @Override public void run() { tv.setText("神荼"); } });
实现方式四:
tv.post(new Runnable() { @Override public void run() { tv.setText("神荼"); } });
实现方式五:
开启加速,Google异步处理方案之AsyncTask(详情请关注我的下一篇Android多线程编程之AsyncTask篇)
上述代码都实现了同样的处理效果,但实现上却略有不同,预知详细原理,请跟进代码分析。
首先来看一下Handler的工作流程(来自郭神):
这个图清晰明白的展示出了handler异步消息处理的整个流程,我想各位看懂这个应该都是没问题,为了搞清楚内部的实现原理,我们就从handle发送消息的起点谈起,,
在第一种方式中,我们通过handle.sendMessage()方法发送一个Message对象,这个msg对象的第一站即MessageQueue,MessageQueue主要包含两个操作:插入(enqueueMessage)和读取(next)
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; }
上面的代码明显暴漏了这货维护的就是一个链表结构啊有木有,当该方法被调用时会向消息链表中插入新的消息对象。
再来看看next
Message next() { 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; } if (mQuitting) { dispose(); return null; } 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); } 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); } } } pendingIdleHandlerCount = 0; nextPollTimeoutMillis = 0; } }
嗯,210-237行淋漓尽致的展现了msg是如何被取出并从链表中溢出的,没啥好说的,
我以前一直困惑Looper到底是个啥?是个类?还是个final类,不过这好像没啥意义啊…其实我们完全没必要知道它是啥,我们只要知道它对Handler形式的异步处理具有决定性的作用,实际上我们在创建Handler的时候必须伴随着两个方法的调用
Looper.prepare()这里假设你已经了解ThreadLocal这货是干啥的了,基于此来看一下该方法的源码
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,那么通过本地sThreadLocal获取即可,否则新建一个,重点来了
Looper对象所“绑定”的线程也就是我们消息接收的线程
所以,你现在知道了,Looper.prepare()获取与所在线程对应的Looper对象,决定消息接收处。
Looper.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; Binder.clearCallingIdentity(); final long ident = Binder.clearCallingIdentity(); for (;;) { Message msg = queue.next(); // might block if (msg == null) { // No message indicates that the message queue is quitting. return; } Printer logging = me.mLogging; if (logging != null) { logging.println(">>>>> Dispatching to " + msg.target + " " + msg.callback + ": " + msg.what); } msg.target.dispatchMessage(msg); if (logging != null) { logging.println("<<<<< Finished to " + msg.target + " " + msg.callback); } 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(); } }
这个玩的就更嗨了,先是获取MessageQueue对象,而后开启了自我轮回模式(无限循环),怎么轮回呢?看326行,从MessageQueue中不断地取出msg对象,然后将该msg对象分发传递出去(338),msg.target即为我们的handler对象,请注意,前方高能Handler源码解析开始…
接上面的msg.target.dispatchMessage(msg)该方法源码如下
public void dispatchMessage(Message msg) { if (msg.callback != null) { handleCallback(msg); } else { if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } } handleMessage(msg); } }
看到没,该方法首先会判断callback接口,若非空,直接处理即可,这也恰恰对应了我们的第二种异步实现方式(简单来说就是直接传递一个Runnable,该Runnable最后会在Looper线程运行),那么第三种方式呢,也很类似不是么?看代码
public final void runOnUiThread(Runnable action) { if (Thread.currentThread() != mUiThread) { mHandler.post(action); } else { action.run(); } }
看到某,就是第二种方式的封装版,而且省去了Handler的创建。
你可能要问了,mCallback是哪里冒出来野生奥特曼,干啥玩意的?
对应这个问题,我只能说,看代码
public Handler(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 that has not called Looper.prepare()"); } mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async; }
很明显这货来自于Handler的构造方法(不止一个),408行已然说明一切,最后我们看到在dispatchMessage终究要执行终极方法handleMessage(msg),于是乎消息对象来到了我们早已写好的handleMessage()方法中并在你Looper“绑定”的线程执行(一般都是主线程啦啦啦)…
ThreadLocal是一个线程内部的数据存储类,通过该类可以在指定的线程中存储数据,当然也只能获取当前线程的存储数据
在Handler异步消息处理中我们每个线程都要指定自己的Looper对象,那么如果没有该类,我们可能需要较为麻烦的方式去管理这些Looper对象,如hash表存储等
一个简单的使用示例
private ThreadLocalmIntegerThreadLocal = new ThreadLocal<>(); mIntegerThreadLocal.set(111); new Thread("Thread_1") { @Override public void run() { mIntegerThreadLocal.set(222); Log.d("TAG2", mIntegerThreadLocal.get().toString()); Log.d("TAG", Thread.currentThread().getName()); } }.start(); new Thread("Thread_2") { @Override public void run() { mIntegerThreadLocal.set(333); Log.d("TAG3", mIntegerThreadLocal.get().toString()); Log.d("TAG", Thread.currentThread().getName()); } }.start(); Log.d("TAG1", mIntegerThreadLocal.get().toString()); Log.d("TAG", Thread.currentThread().getName());
输出:
显然,结果表明了同一个对象在不同的线程有着不同的值,再来看一下它内部的源码实现(以搞懂源码为目标)
首先是set方法
public void set(T value) { Thread currentThread = Thread.currentThread(); Values values = values(currentThread); if (values == null) { values = initializeValues(currentThread); } values.put(this, value); }
看到某,ThreadLocal能根据不同线程维护不同Values对象(Thread内部产生),进而存储获取不同的数据,更具体的可以自行查阅源码。
再来看下get
public T get() { // Optimized for the fast path. Thread currentThread = Thread.currentThread(); Values values = values(currentThread); if (values != null) { Object[] table = values.table; int index = hash & values.mask; if (this.reference == table[index]) { return (T) table[index + 1]; } } else { values = initializeValues(currentThread); } return (T) values.getAfterMiss(this); }
和set类似,清楚明白不扯淡,就不多说了
聊了这么久,有人可能就问了,你说使用handler必须要调用Looper的prepare和loop方法,那么主线程(ActivityThread)并没有看到调用啊,你净扯犊子呢?
有此问的道友先息息火,关于这个问题其实很简单,Android已经为我们做好了封装,而且第一个方法调用的是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(); } }
OK,到此为止我相信你应该是彻底搞懂了了Handler的异步消息机制,如果还有什么疑问欢迎下方留言,当然我建议你能抽点时间自己去一点点的去阅读分析handler的源码,这样才能真正深刻的理解并记忆。