Android多线程编程之Handler篇（消息机制）

Posted 2023-02-20 痕迹天涯119

android多线程编程之Handler篇（消息机制）

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发送消息的起点谈起，，

MessageQueue

在第一种方式中，我们通过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

我以前一直困惑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源码解析开始…

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<? 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();
        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

ThreadLocal是一个线程内部的数据存储类，通过该类可以在指定的线程中存储数据，当然也只能获取当前线程的存储数据

在Handler异步消息处理中我们每个线程都要指定自己的Looper对象，那么如果没有该类，我们可能需要较为麻烦的方式去管理这些Looper对象，如hash表存储等

一个简单的使用示例

    private ThreadLocal<Integer> mIntegerThreadLocal = 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的源码，这样才能真正深刻的理解并记忆。