【Android】 浅谈Handler机制

Handler机制产生的原因

在谈论一个机制之前，需要了解这个机制设计出来是为了解决什么问题。
Handler设计出来就是因为UI线程不能进行耗时操作，子线程不能更新UI，所以需要一种跨线程通信的机制来解决子线程跑完耗时操作之后更新UI的操作。

Handler机制对应的组成部分

需要理解整个Handler机制，至少需要理解以下几个部分：

Handler Looper Message MessageQueue ThreadLocal

ThreadLocal相关内容已经写了一片博客分析过了：传送门
那么这篇文章就主要聚焦在Handler以及Looper的具体实现上。

Handler

讲真的，遇事不决看注释，写得很清楚了。只翻译一下第一段就能了解Handler是干嘛的了。
Handler使你可以发送和处理与线程MessageQueue相关联的Message和Runnable。每个Handler实例都与一个该线程的MessageQueue相关联，创建新的Handler时，它将绑定到创建它的线程的消息队列中。从那一刻起，它可以将Message以及Runnable传递到该消息队列中，并在读取到对应消息时执行。
这个发送靠的是Looper对象。
Looper存储了每个线程对应的消息队列，也就是说其实在初始化的时候传入Looper对象就可以达到获得消息队列的目的，那我们看一下构造函数：

    
    public Handler() {
        this(null, false);
    }
    public Handler(@Nullable 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 " + Thread.currentThread()
                        + " that has not called Looper.prepare()");
        }
        MQueue = mLooper.mQueue;
        mCallback = callback;
        mAsynchronous = async;
    }

如果是无参构造函数，那么从ThreadLocalMap中去取当前线程的Looper。通过这个Looper就可以拿到对应的MessageQueue。

Looper

其实很多类的功能，点进去源码之后，看一下注释就能大致理解了。我们还是从Looper的注释开始，有一个大概的认知。

翻译一下第一段也就差不多知道Looper产生的意义是什么了：Looper是为了为线程提供消息循环。默认情况下，线程没有与之关联的消息循环；可以通过Looper.prepare()来创建，然后通过Looper.loop()来使其分发（dispatch）消息，直到循环停止。

Looper.prepare

    
    public static void prepare() {
        prepare(true);
    }
    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并且存到ThreadLocalMap中，如果已经存在就报错。

Looper.loop()

这个方法是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;
        ......
        for (;;) {
            Message msg = queue.next(); // might block
            ......
            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);
                }
            }
            ......
        }
    }

这是一篇浅谈，所以择出来了关键代码分析分析。有几点需要注意：

final MessageQueue queue = me.mQueue; for( ; ; ){…} Message msg = queue.next();//might block dispatchMessage(msg); final MessageQueue queue = me.mQueue;

这个queue，就是对应线程的消息队列MessageQueue

    @UnsupportedAppUsage
    final MessageQueue mQueue;

mQueue是在构造函数中进行初始化的。

    private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
    }

for( ; ; ){…}

显而易见，这是一个死循环，死循环的目的就是源源不断地从消息队列中取出消息来进行分发。
那么这个时候就会有问题了，如果没有消息呢？如果没有消息还死循环，那不会很占用CPU资源吗？
首先，ActivityThread不是Thread，只是APP的入口类。也就是说它也是运行在某一线程上的部分代码而已。
如果消息队列没有消息，那么ActivityThread会阻塞在==queue.next()中的nativePollOnce()==方法中。这块我想看来着，但是估计是被@hide了，所以点不进去源码。
这时候也不会特别耗CPU资源，因为主线程会放弃CPU资源进入休眠状态。

Message msg = queue.next();//might block

这行代码已经写得很清楚了，如果消息队列为空，那么会导致block，也就是阻塞在这里。也就是上文说的nativePollOnce()方法中。

dispatchMessage(msg);

点进去看看呗。

    
    public void dispatchMessage(@NonNull Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

很清晰哈，如果msg.callback不为空就调用handleCallback，如果为空就调用handleMessage。继续看看这两个方法源码。

    private static void handleCallback(Message message) {
        message.callback.run();
    }

handleCallback掉了callback的run方法，那么这个callback是个啥玩意呢？
其实就是一个Runnable对象，在哪里设置的呢，那么可以追溯到Handler.post(Runnable r)方法中

    
    public final boolean post(@NonNull Runnable r) {
       return  sendMessageDelayed(getPostMessage(r), 0);
    }
    private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }

就是包了一下，包成了一个Message，包装器模式嘛。

    
    public void handleMessage(@NonNull Message msg) {
    }

这个方法相信基本都遇见过，因为需要重写。自定义处理规则即可，基本都需要有更新UI的操作。
对比一下上述两种方式，sendMessage以及post方法，可以发现说：
handleMessage最终是以回调的形式执行了，这个回调函数需要去在初始化Handler的时候实现。
post方法则是提供了一个更加灵活的方式，相当于直接在主线程执行了自定义的操作，而不需要在初始化handler的时候进行重写，而是将这个重写放在了post的对应线程。当然执行还是在UI线程执行的。
或者可以这么理解，Handler中的Runnable接口只是一个函数式接口，复用了Runnable这个接口而已，完全可以被自定义的函数式接口替代。所以不要一看到Runnable就觉得另外开了一个线程。
下面看一个例子：

public class SingleInstanceActivity extends AppCompatActivity {
    private static final String TAG = "SingleInstanceActivity";
    private ActivitySingleInstanceBinding binding;
    Handler handler = new Handler(){
        @Override
        public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
            binding.textView.setText("sendMessageChanged");
        }
    };
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        binding = DataBindingUtil.setContentView(this,R.layout.activity_single_instance);
        binding.button3.setOnClickListener(view->{
            new Thread(()->{
                Looper.prepare();
				//利用post(Runnable r)方法
                handler.post(()->{
                    binding.textView.setText("Post changed");
                });
                Looper.loop();
            }).start();
        });
        binding.button4.setOnClickListener(view->{
            new Thread(()->{
                Looper.prepare();
				//利用sendMessage方法
                handler.sendEmptyMessage(0);
                Looper.loop();
            }).start();
        });
    }
}

布局就是一个Activity里面两个Button一个TextView，不粘xml出来了。
无论点击哪个按钮，都会导致对应的TextView改变。

Message

Message意为消息，可以通过handler的handleMessage方法处理对应的Message，其中有几个比较重要的属性：

public final class Message implements Parcelable {
    
    public int what;
    
    public int arg1;
    
    public int arg2;
    
    public Object obj;
         Bundle data;
    @UnsupportedAppUsage
     Handler target;
    @UnsupportedAppUsage
     Runnable callback;
    // sometimes we store linked lists of these things
    @UnsupportedAppUsage
     Message next;
    ......

前面几个都是可以存储数据或者作为标识进行不同的操作。
target则是执行handleMessage的handler对象，这个属性保证了Looper知道要将Message交给哪个handler执行。
callback根据上面解释的，是在主线程执行的Runnable对象。

MessageQueue

MessageQueue就是消息队列了，复杂的也不分析了，主要是看一下上面不断提到的next()方法取出消息的操作：

    @UnsupportedAppUsage
    Message next() {
        ......
        for (;;) {
            ......
            nativePollOnce(ptr, nextPollTimeoutMillis);
            ......
        }
    }

不关注那么多，解释一下这也是一个死循环，只要有Message就会源源不断地从MessageQueue中取出。nativePollOnce()这个方法比较关键，简单来说，有消息就不阻塞，没有消息就阻塞，直到有消息入队会将其唤醒。

总结

通过上面的讲述希望大家可以知道为什么Thread:Looper:Handler == 1:1:n。
Handler机制是为了解决UI线程不能进行耗时操作而子线程不能修改UI的问题。
每个线程最多有一个Looper。
一个Looper可以对应很多handler。
Handler有两种发送消息的方式，post和sendMessage。
Looper可以通过Message的target属性找到执行handleMessage的handler对象。
MessageQueue阻塞在next()方法中也不会导致APP卡死或者很高的CPU消耗。

谈一下自己对于Handler两种消息发送机制的理解吧，如果是需要传递数据，那么利用Message中的属性可以进行数据的传递然后更新UI。
如果是为了简单的更新UI那么完全可以只写一个Runnable对象就能做到，也就不需要在初始化Handler对象的时候重写handleMessage方法，不过这样会导致线程间耦合度不如重写handleMessage那么松散。不过在读代码的时候也不用跳很远才能知道这次的消息发送导致的UI更新是什么样。

作者：一个发际线两个高