Framework大合集，从里到外分析的明明白白

Posted 2022-11-21 初一十五啊

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Framework大合集，从里到外分析的明明白白相关的知识，希望对你有一定的参考价值。

前言

由于很多小伙伴在前前后后发现了一个问题，在很多大厂面试的时候基本上都会问到Framework这方面，刚好之前整理的 《十大模块手册》 刚好有这方面的内容，拿出来分享一下，主要借鉴，错误的地方一起改正。😂

国庆回来上班第二天，不摸鱼了😑

关注公众号：初一十五a
解锁 《Android十大板块文档》，让学习更贴近未来实战。已形成PDF版

内容如下：

1.2022最新Android11位大厂面试专题，128道附答案
2.音视频大合集，从初中高到面试应有尽有
3.Android车载应用大合集，从零开始一起学
4.性能优化大合集，告别优化烦恼
5.Framework大合集，从里到外分析的明明白白
6.Flutter大合集，进阶Flutter高级工程师
7.compose大合集，拥抱新技术
8.Jetpack大合集，全家桶一次吃个够
9.架构大合集，轻松应对工作需求
10.Android基础篇大合集，根基稳固高楼平地起

整理不易，关注一下吧。开始进入正题，ღ( ´･ᴗ･` ) 🤔

一丶android Binder

进程隔离：

内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据
为了保证系统的安全，用户空间和内核空间是天然隔离的
每个进程有自己的虚拟内存空间，为了安全，每个进程只能操作自己的虚拟内存空间，只有操作系统才有权限操作物理内存空间

1.为什么要用Binder？

Android系统内核是Linux内核
Linux内核进程通信有：管道、内存共享、Socket、File；
对比：

Binder的一次拷贝发生在用户空间拷贝到内核空间；

用户空间：
App进程运行的内存空间；

内核空间：
系统驱动、和硬件相关的代码运行的内存空间，也就是进程ID为0的进程运行的空间；

程序局部性原则：
只加载少量代码；应用没有运行的代码放在磁盘中，运行时高速缓冲区进行加载要运行的代码；默认一次加载一个页（4K），若不够4K就用0补齐；

MMU:内存管理单元；

给CPU提供虚拟地址；

当对变量操作赋值时：

CPU拿着虚拟地址和值给到MMU
MMU用虚拟地址匹配到物理地址，MMU去物理内存中进行赋值；

物理地址：
物理内存的实际地址,并不是磁盘；

虚拟地址：
MMU根据物理内存的实际地址翻译出的虚拟地址；提供给CPU使用；

页命中：CPU读取变量时，MMU在物理内存的页表中找到了这个地址；

页未命中：CPU读取变量时，MMU在物理内存的页表中没有找到了这个地址，此时会触发MMU去磁盘读取变量并存到物理内存中；

普通的二次拷贝：

应用A拷贝到服务端：coay_from_user

从服务端拷贝到应用B：coay_to_user

mmap():

在物理内存中开辟一段固定大小的内存空间
将磁盘文件与物理内存进行映射（理解为绑定）
MMU将物理内存地址转换为虚拟地址给到CPU（虚拟地址映射物理内存）

共享内存进程通信：

进程A调用mmap()函数会在内核空间中虚拟地址和一块同样大小的物理内存，将两者进行映射
得到一个虚拟地址
进程B调用mmap()函数，传参和步骤1一样的话，就会得到一个和步骤2相同的虚拟地址
进程A和进程B都可以用同一虚拟地址对同一块映射内存进行操作
进程A和进程B就实现了通信
没有发生拷贝，共享一块内存，不安全

Binder通信原理：

角色：Server端A、Client端B、Binder驱动、内核空间、物理内存

Binder驱动在物理内存中开辟一块固定大小（1M-8K）的物理内存w，与内核空间的虚拟地址x进行映射得到
A的用户空间的虚拟地址ax和物理内存w进行映射
此时内核空间虚拟地址x和物理内存w已经进行了映射，物理内存w和Server端A的用户空间虚拟地址ax进行了映射：也就是内核空间的虚拟地址x = 物理内存w = Server端A的用户空间虚拟地址ax
B发送请求：将数据按照binder协议进行打包给到Binder驱动，Binder驱动调用coay_from_user()将数据拷贝到内核空间的虚拟地址x
因步骤3中的三块区域进行了映射
Server端A就得到了Client端B发送的数据
通过内存映射关系，只发生了一次拷贝

Activity跳转时，最多携带1M-8k（1兆减去8K）的数据量；

真实数据大小为：1M内存-两页的请求头数据=1M-8K；

应用A直接将数据拷贝到应用B的物理内存空间中，数据量不能超过1M-8K；拷贝次数少了一次，少了从服务端拷贝到用户；

IPC通信机制：

服务注册
服务发现
服务调用

以下为简单的主进程和子进程通信：

1、服务注册：
缓存中心中有三张表(暂时理解为三个HashMap，Binder用的是native的红黑树)：

第一种：放key ：String - value：类的Class；
第二种：放key ：Class的类名 - value：类的方法集合；
第三种：放key ：Class的类名 - value：类的对象；

类的方法集合：key-value;

key：方法签名：“方法名” 有参数时用 “方法名-参数类型-参数类型-参数类型…”;

value: 方法本身;

注册后，服务若没被调用则一直处于沉默状态，不会占用内存，这种情况只是指用户进程里自己创建的服务，不适用于AMS这种；

2、服务发现：
当被查询到时，要被初始化；

客户端B通过发送信息到服务端A
服务端解析消息，反序列化
通过反射得到消息里的类名，方法，从注册时的第一种、第二种表里找到Class，若对象没初始化则初始化对象，并将对象添加到第三种的表里；

3、服务调用：

使用了动态代理
客户端在服务发现时，拿到对象（其实是代理）
客户端调用对象方法
代理发送序列化数据到服务端A
服务端A解析消息，反序列化，得到方法进行处理，得到序列化数据结果
将序列化结果写入到客户端进程的容器中；
回调给客户端

AIDL：
BpBinder：数据发送角色
BbBinder：数据接收角色

编译器生成的AIDL的java接口.Stub.proxy.transact()为数据发送处；

发送的数据包含：数据+方法code+方法参数等等；

发送时调用了Linux的驱动
调用copy_from_user()拷贝用户发送的数据到内核空间
拷贝成功后又进行了一次请求头的拷贝：copy_from_user()
也就是把一次的数据分为两次拷贝

请求头：包含了目的进程、大小等等参数，这些参数占了8K

编译器生成的AIDL的java接口.Stub.onTransact()为数据接收处；

Binder中的IPC机制：

每个App进程启动时会在内核空间中映射一块1M-8K的内存
服务端A的服务注册到ServiceManager中：服务注册
客户端B想要调用服务端A的服务，就去请求ServiceManager
ServiceManager去让服务端A实例化服务：服务发现
返回一个用来发送数据的对象BpBinder给到客户端B
客户端B通过BpBinder发送数据到服务端A的内核的映射区域（传参时客户端会传一个reply序列化对象，在底层会将这个地址一层一层往下传，直至传到回调客户端）：这里发生了一次通信copy_from_user：服务调用
服务端A通过BBBinder得到数据并处理数据
服务端唤醒客户端等待的线程；将返回结果写入到客户端发送请求时传的一个reply容器地址中,调用onTransact返回；
客户端在onTransac中得到数据；通信结束；

ServiceManager维持了Binder这套通信框架；

2.APP多进程的优点

扩大应用可使用的内存
手机内存6G，系统分配给虚拟机的内存一般32M、48M、64M，使用多进程时，可以使用一个进程专门加载图片，防止OOM。
子进程崩溃，不会导致主进程崩溃
互相保活，即如果子进程被系统kill掉时，主进程拉起子进程。主进程被系统kill掉时，子进程拉起主进程。

3.多进程通信原理

Android进程是运行在系统分配的虚拟地址空间，虚拟地址空间分为用户空间和内核空间。多进程间，用户空间不共享，内核空间共享，进程间通过共享的内核空间通信。

4.多进程通信有哪些方式？

1.传统的IPC方式：socket，内存共享。
2.Android特有的方式：Binder。

5.`Binder`相对其他`IPC`方式优点/为什么使用`Binder`？

1.性能：

A.Socket传输数据的过程：两次拷贝

B.Binder传输数据的过程：一次拷贝

内存映射：MMAP（memory map）

虚拟内存和物理内存

虚拟内存映射到物理内存，物理内存存储数据。

2.易用性

3.安全性

6.Binder在Android系统CS通信机制中起到的作用

Android C/S通信机制
Binder机制的关键概念
Binder在Android CS通信机制中起到的作用

AIDL和Binder的关系？
AIDL封装了Binder，AIDL调用Binder

二丶Android Handler

Handler属于非常经典的一个考题了，导致这个知识点很多时候，考官都懒得问了；这玩意很久之前就看过，但是过了一段时间，就很容易忘记，但是处理内存泄漏，IdleHandler之类的考点答案肯定很难忘。。。虽然考官很多时候不屑问，但是要是问到了，你忘了且不知道怎么回答，那就很尴尬了。

考点：

1.Handler怎么在主线程和子线程进行数据交互的原理？

2.Handler中主线程的消息队列是否有数量上限？为什么？
3.Handler中有Loop死循环，为什么没有卡死？为什么没有发生ANR？
4.为什么不建议在子线程中更新UI？
5.可以让自己发送的消息优先被执行吗？原理是什么？
6.子线程和子线程使用Handler进行通信，存在什么弊端？
7.Handler中的阻塞唤醒机制？
8.什么是IdleHandler？什么条件下触发IdleHandler？
9.消息处理完后，是直接销毁吗？还是被回收？如果被回收，有最大容量吗？
10.不当的使用Handler，为什么会出现内存泄漏？怎么解决？

1.Handler怎么在主线程和子线程进行数据交互的原理？

主线程和子线程通过handler交互，交互的载体是通过Message这个对象，实际上我们在子线程发送的所有消息，都会加入到主线程的消息队列中，然后主线程分发这些消息，这个就很容易做到俩个线程信息的交互。

看到这里，你可能有疑问了，我从子线程发送的消息，怎么就加到了主线程的消息队列里呢？？？

大家可以看看你自己的代码，你的handler对象是不是在主线程初始的？子线程发送消息，是不是通过这个handler发送的？

这就很简单了，handler只需要把发送的消息，加到自身持有的Looper对象的MessageQueue里面（mLooper变量）就ok了

所以，你在哪个线程里面初始化Handler对象，在不同的线程中，使用这个对象发送消息；都会在你初始化Handler对象的线程里分发消息。

2.Handler中主线程的消息队列是否有数量上限？为什么？

这问题整的有点鸡贼，可能会让你想到，是否有上限这方面？而不是直接想到到上限数量是多少？

解答：Handler主线程的消息队列肯定是有上限的，每个线程只能实例化一个Looper实例（上面讲了，Looper.prepare只能使用一次），不然会抛异常，消息队列是存在Looper()中的，且仅维护一个消息队列

重点：每个线程只能实例化一次Looper()实例、消息队列存在Looper中

拓展：MessageQueue类，其实都是在维护mMessage，只需要维护这个头结点，就能维护整个消息链表

3.Handler中有Loop死循环，为什么没有卡死？为什么没有发生ANR？

先说下ANR：5秒内无法响应屏幕触摸事件或键盘输入事件；广播的onReceive()函数时10秒没有处理完成；前台服务20秒内，后台服务在200秒内没有执行完毕；ContentProvider的publish在10s内没进行完。所以大致上Loop死循环和ANR联系不大，问了个正确的废话，所以触发事件后，耗时操作还是要放在子线程处理，handler将数据通讯到主线程，进行相关处理。

线程实质上是一段可运行的代码片，运行完之后，线程就会自动销毁。当然，我们肯定不希望主线程被over，所以整一个死循环让线程保活。

为什么没被卡死：在事件分发里面分析了，在获取消息的next()方法中，如果没有消息，会触发nativePollOnce方法进入线程休眠状态，释放CPU资源，MessageQueue中有个原生方法nativeWake方法，可以解除nativePollOnce的休眠状态，ok，咱们在这俩个方法的基础上来给出答案。

当消息队列中消息为空时，触发MessageQueue中的nativePollOnce方法，线程休眠，释放CPU资源
消息插入消息队列，会触发nativeWake唤醒方法，解除主线程的休眠状态
- 当插入消息到消息队列中，为消息队列头结点的时候，会触发唤醒方法
- 当插入消息到消息队列中，在头结点之后，链中位置的时候，不会触发唤醒方法

综上：消息队列为空，会阻塞主线程，释放资源；消息队列为空，插入消息时候，会触发唤醒机制

这套逻辑能保证主线程最大程度利用CPU资源，且能及时休眠自身，不会造成资源浪费

本质上，主线程的运行，整体上都是以事件（Message）为驱动的。

4.为什么不建议在子线程中更新UI？

多线程操作，在UI的绘制方法表示这不安全，不稳定。

假设一种场景：我会需要对一个圆进行改变，A线程将圆增大俩倍，B改变圆颜色。A线程增加了圆三分之一体积的时候，B线程此时，读取了圆此时的数据，进行改变颜色的操作；最后的结果，可能会导致，大小颜色都不对。。。

5.可以让自己发送的消息优先被执行吗？原理是什么？

这个问题，我感觉只能说：在有同步屏障的情况下是可以的。

同步屏障作用：在含有同步屏障的消息队列，会及时的屏蔽消息队列中所有同步消息的分发，放行异步消息的分发。

在含有同步屏障的情况，我可以将自己的消息设置为异步消息，可以起到优先被执行的效果。

6.子线程和子线程使用Handler进行通信，存在什么弊端？
子线程和子线程使用Handler通信，某个接受消息的子线程肯定使用实例化handler，肯定会有Looper操作，Looper.loop()内部含有一个死循环，会导致线程的代码块无法被执行完，该线程始终存在。

如果在完成通信操作，我们一般可以使用： mHandler.getLooper().quit() 来结束分发操作

说明下：quit()方法进行几项操作

清空消息队列（未分发的消息，不再分发了）
调用了原生的销毁方法 nativeDestroy（猜测下：可能是一些资源的释放和销毁）
拒绝新消息进入消息队列
它可以起到结束loop()死循环分发消息的操作

拓展：quitSafely() 可以确保所有未完成的事情完成后，再结束消息分发。

7.Handler中的阻塞唤醒机制？

这个阻塞唤醒机制是基于 Linux 的 I/O 多路复用机制 epoll 实现的，它可以同时监控多个文件描述符，当某个文件描述符就绪时，会通知对应程序进行读/写操作.

MessageQueue 创建时会调用到 nativeInit，创建新的 epoll 描述符，然后进行一些初始化并监听相应的文件描述符，调用了epoll_wait方法后，会进入阻塞状态；nativeWake触发对操作符的 write 方法，监听该操作符被回调，结束阻塞状态。

8.什么是IdleHandler？什么条件下触发IdleHandler？

IdleHandler的本质就是接口，为了在消息分发空闲的时候，能处理一些事情而设计出来的

具体条件：消息队列为空的时候、发送延时消息的时候

9.消息处理完后，是直接销毁吗？还是被回收？如果被回收，有最大容量吗？

Handler存在消息池的概念，处理完的消息会被重置数据，采用头插法进入消息池，取的话也直接取头结点，这样会节省时间

消息池最大容量为50，达到最大容量后，不再接受消息进入

10.不当的使用Handler，为什么会出现内存泄漏？怎么解决？

先说明下，Looper对象在主线程中，整个生命周期都是存在的，MessageQueue是在Looper对象中，也就是消息队列也是存在在整个主线程中；我们知道Message是需要持有Handler实例的，Handler又是和Activity存在强引用关系

存在某种场景：我们关闭当前Activity的时候，当前Activity发送的Message，在消息队列还未被处理，Looper间接持有当前activity引用，因为俩者直接是强引用，无法断开，会导致当前Activity无法被回收

思路：断开俩者之间的引用、处理完分发的消息，消息被处理后，之间的引用会被重置断开

解决：使用静态内部类弱引Activity、清空消息队列

1.总流程

开头需要建立个handler作用的总体印象，下面画了一个总体的流程图

从上面的流程图可以看出，总体上是分几个大块的

Looper.prepare()、Handler()、Looper.loop() 总流程
收发消息
分发消息

相关知识点大概涉及到这些，下面详细讲解下！

2.使用

先来看下使用，不然源码，原理图搞了一大堆，一时想不起怎么用的，就尴尬了

使用很简单，此处仅做个展示，大家可以熟悉下

演示代码尽量简单是为了演示，关于静态内部类持有弱引用或者销毁回调中清空消息队列之类，就不在此处展示了

来看下消息处理的分发方法：dispatchMessage(msg)

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

...

从上面源码可知，handler的使用总的来说，分俩大类，细分三小类

收发消息一体
- handleCallback(msg)
收发消息分开
- mCallback.handleMessage(msg)
- handleMessage(msg)

2.1.收发一体

handleCallback(msg)
使用post形式，收发都是一体，都在post()方法中完成，此处不需要创建Message实例等，post方法已经完成这些操作

public class MainActivity extends AppCompatActivity 
    private TextView msgTv;
    private Handler mHandler = new Handler();
 
    @Override
    protected void onCreate(Bundle savedInstanceState) 
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        msgTv = findViewById(R.id.tv_msg);
 
        //消息收发一体
        new Thread(new Runnable() 
            @Override public void run() 
                String info = "第一种方式";
                mHandler.post(new Runnable() 
                    @Override public void run() 
                        msgTv.setText(info);
                    
                );
            
        ).start();

2.2.收发分开

mCallback.handleMessage(msg)

实现Callback接口

public class MainActivity extends AppCompatActivity 
    private TextView msgTv;
    private Handler mHandler = new Handler(new Handler.Callback() 
        //接收消息,刷新UI
        @Override public boolean handleMessage(@NonNull Message msg) 
            if (msg.what == 1) 
                msgTv.setText(msg.obj.toString());
            
            //false 重写Handler类的handleMessage会被调用,  true 不会被调用
            return false;
        
    );
 
    @Override
    protected void onCreate(Bundle savedInstanceState) 
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        msgTv = findViewById(R.id.tv_msg);
 
        //发送消息
        new Thread(new Runnable() 
            @Override public void run() 
                Message message = Message.obtain();
                message.what = 1;
                message.obj = "第二种方式 --- 1";
                mHandler.sendMessage(message);
            
        ).start();

handleMessage(msg)

重写Handler类的handlerMessage(msg)方法

public class MainActivity extends AppCompatActivity 
    private TextView msgTv;
    private Handler mHandler = new Handler() 
        //接收消息,刷新UI
        @Override public void handleMessage(@NonNull Message msg) 
            super.handleMessage(msg);
            if (msg.what == 1) 
                msgTv.setText(msg.obj.toString());
            
        
    ;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) 
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        msgTv = findViewById(R.id.tv_msg);
 
        //发送消息
        new Thread(new Runnable() 
            @Override public void run() 
                Message message = Message.obtain();
                message.what = 1;
                message.obj = "第二种方式 --- 2";
                mHandler.sendMessage(message);
            
        ).start();

3.prepare和loop

大家肯定有印象，在子线程和子线程的通信中，就必须在子线程中初始化Handler，必须这样写

prepare在前，loop在后，固化印象了

new Thread(new Runnable() 
    @Override public void run() 
        Looper.prepare();
        Handler handler = new Handler();
        Looper.loop();
    
);

为啥主线程不需要这样写，聪明你肯定想到了，在入口出肯定做了这样的事

ActivityThread.java
...
public static void main(String[] args) 
    ...
    //主线程Looper
    Looper.prepareMainLooper();
    ActivityThread thread = new ActivityThread();
    thread.attach(false);
    if (sMainThreadHandler == null) 
        sMainThreadHandler = thread.getHandler();
    
    //主线程的loop开始循环
    Looper.loop();
    ...

...

为什么要使用prepare和loop？我画了个图，先让大家有个整体印象

上图的流程，鄙人感觉整体画的还是比较清楚的
总结下就是.

Looper.prepare()：生成Looper对象，set在ThreadLocal里
handler构造函数：通过Looper.myLooper()获取到ThreadLocal的Looper对象
Looper.loop()：内部有个死循环，开始事件分发了；这也是最复杂，干活最多的方法.

具体看下每个步骤的源码，这里也会标定好链接，方便大家随时过去查看

Looper.prepare()
可以看见，一个线程内，只能使用一次prepare()，不然会报异常的

Looper.java
...
 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));

...

Handler()
这里通过Looper.myLooper() ---> sThreadLocal.get()拿到了Looper实例

Handler.java
...
@Deprecated
public Handler() 
    this(null, false);

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

...

Looper.java
...
public static @Nullable Looper myLooper() 
    return sThreadLocal.get();

...

Looper.loop()：该方法分析，在分发消息里讲

精简了大量源码，详细的可以点击上面方法名
Message msg = queue.next()：遍历消息
msg.target.dispatchMessage(msg)：分发消息
msg.recycleUnchecked()：消息回收，进入消息池

Looper.java
...
public static void loop() 
    final Looper me = myLooper();
     
    ...
     
    final MessageQueue queue = me.mQueue;
 
    ...
 
    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);
            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);
            
        
      
        ....
 
        msg.recycleUnchecked();
    

...

4.收发消息

收发消息的操作口都在Handler里，这是我们最直观的接触的点,下方的思维导图整体做了个概括。

4.1.前置知识

在说发送和接受消息之前，必须要先解释下，Message中一个很重要的属性：when

when这个变量是Message中的，发送消息的时候，我们一般是不会设置这个属性的，实际上也无法设置，只有内部包才能访问写的操作；将消息加入到消息队列的时候会给发送的消息设置该属性。消息加入消息队列方法：enqueueMessage()

在我们使用sendMessage发送消息的时候，实际上也会调用sendMessageDelayed延时发送消息发放，不过此时传入的延时时间会默认为0，来看下延时方法：sendMessageDelayed

public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) 
    if (delayMillis < 0) 
        delayMillis = 0;
    
    return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);

这地方调用了sendMessageAtTime方法，此处！做了一个时间相加的操作：SystemClock.uptimeMillis() + delayMillis

SystemClock.uptimeMillis()：这个方***返回一个毫秒数值，返回的是，打开设备到此刻所消耗的毫秒时间，这很明显是个相对时间刻！
delayMillis：就是我们发送的延时毫秒数值

后面会将这个时间刻赋值给when：when = SystemClock.uptimeMillis() + delayMillis

说明when代表的是开机到现在的一个时间刻，通俗的理解，when可以理解为：现实时间的某个现在或未来的时刻（实际上when是个相对时刻，相对点就是开机的时间点）

4.2.发送消息

发送消息涉及到俩个方法：post()和sendMessage()

post(Runnable)：发送和接受消息都在post中完成
sendMessage(msg)：需要自己传入Message消息对象
看下源码
- 使用post会自动会通过getPostMessage方法创建Message对象
- 在enqueueMessage中将生成的Message加入消息队列，注意
  - 此方法给msg的target赋值当前handler之后，才进行将消息添加的消息队列的操作
  - msg.setAsynchronous(true)：设置Message属性为异步，默认都为同步；设置为异步的条件，需要手动在Handler构造方法里面设置

Handler.java
...
//post
public final boolean post(@NonNull Runnable r) 
    return  sendMessageDelayed(getPostMessage(r), 0);

 
//生成Message对象
private static Message getPostMessage(Runnable r) 
    Message m = Message.obtain();
    m.callback = r;
    return m;

 
//sendMessage方法
public final boolean sendMessage(@NonNull Message msg) 
    return sendMessageDelayed(msg, 0);

 
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) 
    if (delayMillis < 0) 
        delayMillis = 0;
    
    return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);

 
public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis) 
    MessageQueue queue = mQueue;
    if (queue == null) 
        RuntimeException e = new RuntimeException(
            this + " sendMessageAtTime() called with no mQueue");
        Log.w("Looper", e.getMessage(), e);
        return false;
    
    return enqueueMessage(queue, msg, uptimeMillis);

 
///将Message加入详细队列
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
                               long uptimeMillis) 
    //设置target
    msg.target = this;
    msg.workSourceUid = ThreadLocalWorkSource.getUid();
 
    if (mAsynchronous) 
        //设置为异步方法
        msg.setAsynchronous(true);
    
    return queue.enqueueMessage(msg, uptimeMillis);

...

enqueueMessage()：精简了一些代码，完整代码，可点击左侧方法名

Message通过enqueueMessage加入消息队列
请明确：when = SystemClock.uptimeMillis() + delayMillis，when代表的是一个时间刻度，消息进入到消息队列，是按照时间刻度排列的，时间刻度按照从小到大排列，也就是说消息在消息队列中：按照从现在到未来的循序排队
这地方有几种情况，记录下：mMessage为当前消息分发到的消息位置
- mMessage为空，传入的msg则为消息链表头，next置空
- mMessage不为空、消息队列中没有延时消息的情况：从当前分发位置移到链表尾，将传入的msg插到链表尾部，next置空
mMessage不为空、含有延时消息的情况：举个例子
- A，B，C消息依次发送，三者分边延时：3秒，1秒，2秒 A(3000)、B(1000)、C(2000)
- 这是一种理想情况：三者依次进入，进入之间的时间差小到忽略，这是为了方便演示和说明
- 这种按照时间远近的循序排列，可以保证未延时或者延时时间较小的消息，能够被及时执行
- 在消息队列中的排列为：B —> C —> A

MessageQueue.java
...
boolean enqueueMessage(Message msg, long when) 
   ...
 
    synchronized (this) 
        ...
 
        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 
            // Inserted within the middle of the queue.  Usually we don't have to wake
            // up the event queue unless there is a barrier at the head of the queue
            // and the message is the earliest asynchronous message in the queue.
            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;

...

来看下发送的消息插入消息队列的图示

4.3.接收消息

接受消息相对而言就简单多

dispatchMessage(msg):关键方法呀

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

...

handleCallback(msg)
- 触发条件：Message消息中实现了handleCallback回调
- 现在基本上只能使用post()方法了，setCallback(Runnabler) 被表明为@UnsupportedAppUsage，被hide了，没法调用，如果使用反射倒是可以调用，但是没必要。。。
- mCallback.handleMessage(msg)
  - 触发条件
    - 使用sendMessage方法发送消息（必须）
    - 实现Handler的Callback回调
  - 分发的消息，会在Handler中实现的回调中
    分发
handleMessage(msg)
- 触发条件
  - 使用sendMessage方法发送消息（必须）
  - 未实现Handler的Callback回调
  - 实现了Handler的Callback回调，返回值为false（mCallback.handleMessage(msg)）
- 需要重写Handler类的handlerMessage方法

5.分发消息

消息分发是在loop()中完成的，来看看loop()这个重要的方法

Looper.loop()：精简了巨量源码，详细的可以点击左侧方法名
- Message msg = queue.next()：遍历消息
- msg.target.dispatchMessage(msg)：分发消息
- msg.recycleUnchecked()：消息回收，进入消息池

Looper.java
...
public static void loop() 
    final Looper me = myLooper();
    ...
    final MessageQueue queue = me.mQueue;
    ...
    for (;;) 
        //遍历消息池,获取下一可用消息
        Message msg = queue.next(); // might block
        ...
        try 
            //分发消息
            msg.target.dispatchMessage(msg);
            ...
         catch (Exception exception) 
            ...
         finally 
            ...
        
        ....
        //回收消息,进图消息池
        msg.recycleUnchecked();
    

...

5.1.遍历消息

遍历消息的关键方法肯定是下面这个

Message msg = queue.next()：Message类中的next()方法；当然这必须要配合外层for（无限循环）来使用，才能遍历消息队列

来看看这个Message中的next()方法吧

next()：精简了一些源码，完整的点击左侧方法名

MessageQueue.java
...
Message next() 
    final long ptr = mPtr;
    ...
 
    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;
    for (;;) 
        ...
        //阻塞，除非到了超时时间或者唤醒
        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;
            // 这是关于同步屏障（SyncBarrier）的知识，放在同步屏障栏目讲
            if (msg != null && msg.target == null) 
                do 
                    prevMsg = msg;
                    msg = msg.next;
                 while (msg != null && !msg.isAsynchronous());
            
             
            if (msg != null) 
                if (now < msg.when) 
                    //每个消息处理有耗时时间，之间存在一个时间间隔（when是将要执行的时间点）。
                    //如果当前时刻还没到执行时刻（when），计算时间差值，传入nativePollOnce定义唤醒阻塞的时间
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                 else 
                    mBlocked = false;
                    //该操作是把异步消息单独从消息队列里面提出来,然后返回,返回之后,该异步消息就从消息队列里面剔除了
                    //mMessage仍处于未分发的同步消息位置
                    if (prevMsg != null) 
                        prevMsg.next = msg.next;
                     else 
                        mMessages = msg.next;
                    
                    msg.next = null;
                    if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                    msg.markInUse();
                    //返回符合条件的Message
                    return msg;
                
             else 
                // No more messages.
                nextPollTimeoutMillis = -1;
            
 
            //这是处理调用IdleHandler的操作,有几个条件
            //1、当前消息队列为空(mMessages == null)
            //2、已经到了可以分发下一消息的时刻（now < mMessages.when）
            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);
                
            
        
 
        // Reset the idle handler count to 0 so we do not run them again.
        pendingIdleHandlerCount = 0;
 
        // While calling an idle handler, a new message could have been delivered
        // so go back and look again for a pending message without waiting.
        nextPollTimeoutMillis = 0;

总结下源码里面表达的意思

1.next()内部是个死循环，你可能会疑惑，只是拿下一节点的消息，为啥要死循环？

为了执行延时消息以及同步屏障等等，这个死循环是必要的

2.nativePollOnce阻塞方法：到了超时时间(nextPollTimeoutMillis)或者通过唤醒方式(nativeWake)，会解除阻塞状态

nextPollTimeoutMillis大于等于零，会规定在此段时间内休眠，然后唤醒
消息队列为空时，nextPollTimeoutMillis为-1，进入阻塞；重新有消息进入队列，插入头结点的时候会触发nativeWake唤醒方法

3.如果 msg.target == null为零，会进入同步屏障状态

会将msg消息死循环到末尾节点，除非碰到异步方法
如果碰到同步屏障消息，理论上会一直死循环上面操作，并不会返回消息，除非，同步屏障消息被移除消息队列

4.当前时刻和返回消息的when判定

消息when代表的时刻：一般都是发送消息的时刻，如果是延时消息，就是发送时刻+延时时间
当前时刻小于返回消息的when：进入阻塞，计算时间差，给nativePollOnce设置超时时间，超时时间一到，解除阻塞，重新循环取消息
当前时刻大于返回消息的when：获取可用消息返回

5.消息返回后，会将mMessage赋值为返回消息的下一节点（只针对不涉及同步屏障的同步消息）

5.2.分发消息

分发消息主要的代码是： msg.target.dispatchMessage(msg);

也就是说这是Handler类中的dispatchMessage(msg)方法

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

可以看到，这里的代码，在收发消息栏目的接受消息那块已经说明过了，这里就无须重复了

5.3.消息池

msg.recycleUnchecked()是处理完成分发的消息，完成分发的消息并不会被回收掉，而是会进入消息池，等待被复用

recycleUnchecked()：回收消息的代码还是蛮简单的，来分析下
- 首先会将当前已经分发处理的消息，相关属性全部重置，flags也标志可用
- 消息池的头结点会赋值为当前回收消息的下一节点，当前消息成为消息池头结点
- 简言之：回收消息插入消息池，当做头结点
- 需要注意的是：消息池有最大的容量，如果消息池大于等于默认设置的最大容量，将不再接受回收消息入池
  - 默认最大容量为50： MAX_POOL_SIZE = 50

Message.java
...
void recycleUnchecked() 
    // Mark the message as in use while it remains in the recycled object pool.
    // Clear out all other details.
    flags = FLAG_IN_USE;
    what = 0;
    arg1 = 0;
    arg2 = 0;
    obj = null;
    replyTo = null;
    sendingUid = UID_NONE;
    workSourceUid = UID_NONE;
    when = 0;
    target = null;
    callback = null;
    data = null;
 
    synchronized (sPoolSync) 
        if (sPoolSize < MAX_POOL_SIZE) 
            next = sPool;
            sPool = this;
            sPoolSize++;

来看下消息池回收消息图示

既然有将已使用的消息回收到消息池的操作，那肯定有获取消息池里面消息的方法了

obtain()：代码很少，来看看
- 如果消息池不为空：直接取消息池的头结点，被取走头结点的下一节点成为消息池的头结点
- 如果消息池为空：直接返回新的Message实例

Message.java
...
public static Message obtain() 
    synchronized (sPoolSync) 
        if (sPool != null) 
            Message m = sPool;
            sPool = m.next;
            m.next = null;
            m.flags = 0; // clear in-use flag
            sPoolSize--;
            return m;
        
    
    return new Message();

来看下从消息池取一个消息的图示

6.IdIeHandler

在MessageQueue类中的next方法里，可以发现有关于对IdleHandler的处理，大家可千万别以为它是什么Handler特殊形式之类，这玩意就是一个interface，里面抽象了一个方法，结构非常的简单

next()：精简了大量源码，只保留IdleHandler处理的相关逻辑；完整的点击左侧方法名

MessageQueue.java
...
Message next() 
    final long ptr = mPtr;
    ...
 
    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;
    for (;;) 
        ...
        //阻塞，除非到了超时时间或者唤醒
        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;
            ...
            //这是处理调用IdleHandler的操作,有几个条件
            //1、当前消息队列为空(mMessages == null)
            //2、未到到了可以分发下一消息的时刻（now < mMessages.when）
            //3、pendingIdleHandlerCount < 0表明：只会在此for循环里执行一次处理IdleHandler操作
            if (pendingIdleHandlerCount < 0
                && (mMessages == null || now < mMessages.when)) 
                pendingIdleHandlerCount = mIdleHandlers.size();
            
            if (pendingIdleHandlerCount <= 0) 
                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;

实际上从上面的代码里面，可以分析出很多信息

IdleHandler相关信息

调用条件

当前消息队列为空(mMessages == null) 或未到分发返回消息的时刻
在每次获取可用消息的死循环中，IdleHandler只会被处理一次：处理一次pendingIdleHandlerCount为0，其循环不可再被执行

实现了IdleHandler中的queueIdle方法

返回false，执行后，IdleHandler将会从IdleHandler列表中移除，只能执行一次：默认false
返回true，每次分发返回消息的时候，都有机会被执行：处于保活状态

IdleHandler代码

MessageQueue.java
...
/**
 * Callback interface for discovering when a thread is going to block
 * waiting for more messages.
 */
public static interface IdleHandler 
    /**
     * Called when the message queue has run out of messages and will now
     * wait for more.  Return true to keep your idle handler active, false
     * to have it removed.  This may be called if there are still messages
     * pending in the queue, but they are all scheduled to be dispatched
     * after the current time.
     */
    boolean queueIdle();

 
public void addIdleHandler(@NonNull IdleHandler handler) 
    if (handler == null) 
        throw new NullPointerException("Can't add a null IdleHandler");
    
    synchronized (this) 
        mIdleHandlers.add(handler);
    

 
public void removeIdleHandler(@NonNull IdleHandler handler) 
    synchronized (this) 
        mIdleHandlers.remove(handler);

怎么使用IdleHandler呢？

这里简单写下用法，可以看看，留个印象

public class MainActivity extends AppCompatActivity 
    private TextView msgTv;
    private Handler mHandler = new Handler();
 
    @Override
    protected void onCreate(Bundle savedInstanceState) 
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        msgTv = findViewById(R.id.tv_msg);
        //添加IdleHandler实现类
        mHandler.getLooper().getQueue().addIdleHandler(new InfoIdleHandler("我是IdleHandler"));
        mHandler.getLooper().getQueue().addIdleHandler(new InfoIdleHandler("我是大帅比"));
 
        //消息收发一体
        new Thread(new Runnable() 
            @Override public void run() 
                String info = "第一种方式";
                mHandler.post(new Runnable() 
                    @Override public void run() 
                        msgTv.setText(info);
                    
                );
            
        ).start();
    
 
    //实现IdleHandler类
    class InfoIdleHandler implements MessageQueue.IdleHandler 
        private String msg;
 
        InfoIdleHandler(String msg) 
            this.msg = msg;
        
 
        @Override
        public boolean queueIdle() 
            msgTv.setText(msg);
            return false;

总结

通俗的讲：当所有消息处理完了或者你发送了延迟消息，在这俩种空闲时间里，都满足执行IdleHandler的条件

这地方需要说明下，如果延迟消息时间设置过短的；IdleHandler可能会在发送消息后执行，毕竟运行到next这步也需要一点时间，延迟时间设置长点，你就可以很明显得发现，IdleHandler在延迟的空隙间执行了！

从其源码上，可以看出来，IdlerHandler是在消息分发的空闲时刻，专门用来处理相关事物的

7.同步屏障

来到最复杂的模块了

在理解同步屏障的概念前，我们需要先搞懂几个前置知识

7.1.前置知识

7.1.1.同步和异步消息

什么是同步消息？什么是异步消息？

讲真的，异步消息和同步消息界定，完成是通过一个方法去界定的
isAsynchronous()：来分析下
- FLAG_ASYNCHRONOUS = 1 << 1：所以FLAG_ASYNCHRONOUS为2
- 同步消息：flags为0或者1的时候，isAsynchronous返回false，此时该消息标定为同步消息
  - flags为0，1：同步消息
- 异步消息：理论上只要按照位操作，右往左，第二位为1的数，isAsynchronous返回true；但是，Message里面基本只使用了：0，1，2，可得出结论
  - flags为2：异步消息

public b以上是关于Framework大合集，从里到外分析的明明白白的主要内容，如果未能解决你的问题，请参考以下文章 
 Framework大合集，从里到外分析的明明白白
 从里到外，手把手一起把JVM虚拟机整体结构与对象内存分配解析摸透透的，简单易懂！
 史上最强 iPad Pro 发布，从内到外全面升级
 PHP（css样式）
 xml建模
 测试工程师进阶面试题目大合集