架构

image.png

最简单的一幅图即可阐述其机制：
子线程可以给队列增加元素
主线程无限循环，从队列中取元素
一旦主线程没有取到，会通过epoll多路复用机制阻塞
而子线程在给队列增加元素的时候，会通过epoll callback唤醒阻塞中的主线程

为什么要有Handler？

// 点击的时候，在子线程更新UI，会报错
@Override
public void onClick() {
    new Thread(new Runnable() {
        @Override
        public void run() {
            mText.setText("New Text!");
        }
    }).start();
}

// onCreate的时候，在子线程更新UI，不会报错
@Override
public void onCreate(Bundle state) {
    super.onCreate(state);
    findViewById(R.id.text).setOnClickListener(new OnClickListener() {
        @Override
        public void onClick() {
             new Thread(new Runnable() {
                 @Override
                 public void run() {
                     mText.setText("New Text!");
                 }
             }).start();
        }
    });
}

这是为啥，因为setText会触发invalidate()
然后一直递归上传绘制内容到Render
再让ViewRootImpl发起绘制（onCreate时不会由错误因为onResume执行后才创建ViewRootImpl）
它会检测是否在主线程
为什么要检测是否主线程呢？
因为假如新开启一个线程，它从start到执行还有一段时间，这显然刷新屏幕太慢，会引起卡顿
而且假如线程优先级过低，卡顿会变本加厉
所以专门指定了一个线程作为主线程，提升其优先级，专门用来绘制UI
除了UI绘制，另外的组件的生命周期也被视为重要的功能，所以也同样放到高优先级的主线程来执行
那么子线程想发起绘制，势必要进行线程切换
通过常规的wait/notify机制，显然会有大量的并发性能损耗，很难达到16ms绘制一次（60帧率）的高要求
所以另辟蹊径，视每次的行为为一个任务，添加到主线程的队列中去，排队执行
由此诞生了Handler机制，实现了线程间的通信
这样一来，每个线程都需要维护一个队列
好消息是，ThreadLocal作为每个线程独有的内存空间，可以方便地解决问题
每个线程可以放心地把自己的队列，存放在ThreadLocal中

无限循环去取消息，主线程为什么不会卡死？

主线程在执行消息，那确实就是主线程的工作
万一消息取光了呢？是不是就卡死了？
这个时候代表主线程没有工作，也很理所应当。
但是有新的任务到来怎么办？线程还是内核态。
这其实就是简单的wait/notify机制，阻塞、唤醒。
新的任务到来，会把处于内核态的线程唤醒，继续开始扫描消息队列。
但是有一点比较特殊，这里不是用的Java的wait/notify关键字（在早期版本的实现确实是这个）
而是用的epoll机制，他会监视一个文件描述符，当描述符就绪时，会通过callback唤醒处于内核态的Linux内核
复杂度为O(1)，比select、poll的O(N)级别的复杂度要好的多
典型的空间换时间
至于为什么要从一开始的Java的wait/notify替换成现在的epoll来实现阻塞唤醒
我猜测这个版本的Android新增了C层的消息机制，为Framework的线程通信服务
所以自然而然要用epoll来实现
因此Java层的消息机制也通过JNI借助epoll实现自己的阻塞

epoll如何实现阻塞？

Loope在无限取消息的时候，最终会阻塞在MessageQueue的nativePollOnce
在这个方法上进行了JNI通信
native层也具有一个nativeMessageQueue，在Java层通过一个long值来保存其内存地址
JNI通过这个long值可以找到nativeMessageQueue，从而调用其方法，最终调用了epoll_wait
而在MessageQueue插入信息的时候，会调用nativeWake，最终会走到JNI，往管道写入1，文件描述符被激活，调用了ep_poll_callback，使得内核被唤醒

优先执行某任务

可以通过设置SyncBarrier，并且post一个消息，设置为异步优先，可以优先让这个消息先执行
具体用法可以看https://blog.csdn.net/asdgbc/article/details/79148180
这一点在系统的ViewRootImpl.scheduleTraversals也有应用

为什么说Android系统是消息驱动的模型？

原因就在于Handler。所有主线程的工作，都是一个消息
四大组件的生命周期都是Handler中的一个消息
这些消息由ActivityThread中的Binder代理类发起，由ActivityThread.H进行处理
心中有这个概念，会对分析Android系统的一些应用层的问题有所帮助，比如ANR

后记

学习自
http://gityuan.com/2016/01/01/handler-message-usage/
https://www.jianshu.com/p/b95fd90d4930
https://blog.csdn.net/asdgbc/article/details/79148180

有什么写得错误、让人费解或遗漏的地方，希望可以不吝赐教，我会马上更改