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

前言

由于许多小伙伴在前前后后发现了一个问题，在许多大厂面试的时分基本上都会问到Framework这方面，刚好之前收拾的 《十大模块手册》 刚好有这方面的内容，拿出来同享一下，首要借鉴，过错的当地一同改正。

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

字数约束分为上下两篇

重视大众号：Android苦做舟
解锁 《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 boolean isAsynchronous() {
    return (flags & FLAG_ASYNCHRONOUS) != 0;
}

setAsynchronous(boo;eam asumc)：这个影响flags的值

• 由于flags是int类型，没有赋初值，故其初始值为0
• setAsynchronous传入true的话，或等于操作，会将flags数值改成2

msg.setAsynchronous(true);
public void setAsynchronous(boolean async) {
    if (async) {
        flags |= FLAG_ASYNCHRONOUS;
    } else {
        flags &= ~FLAG_ASYNCHRONOUS;
    }
}

怎样生成异步音讯？so easy

Message msg = Message.obtain();
//设置异步音讯标记
msg.setAsynchronous(true);

一般来说：默许音讯不做设置，flags都为0，故默以为同步音讯，下面栏目将剖析下setAsynchronous在何处运用了

7.1.2.默许音讯类型

咱们正常状况下，很少会运用setAsynchronous办法的，那么在不运用该办法的时分，音讯的默许类型是什么呢？

• 在生成音讯，然后发送音讯的时分，都会经过下述办法
• enqueueMessage：正常发送音讯（post、推迟和非推迟之类），都会经过此办法
  • 由于发送的一切音讯都会经过enqueueMessage办法，然后参加音讯行列，能够看见一切的音讯都被处理过
  • msg.target = this
    • 这当地给Message类的target赋值了！
    • 阐明：只需运用post或sendMessage之类发送音讯，其音讯就绝不或许是同步屏障音讯！
  • 关于同步异步，能够看见和mAsynchronous休戚相关
    • 只需mAsynchronous为true的话，咱们的音讯都会异步音讯
    • 只需mAsynchronous为false的话，咱们的音讯都会同步音讯

private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,long uptimeMillis) {
    msg.target = this;
    msg.workSourceUid = ThreadLocalWorkSource.getUid();
    if (mAsynchronous) {
        msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis);
}

mAsynchronous在哪设置的呢？ 这是在结构办法里边给mAsynchronous赋值了

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;
}
public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
    mLooper = looper;
    mQueue = looper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

看看一些通用的结构办法

public Handler() {
    this(null, false);
}
public Handler(@NonNull Looper looper) {
    this(looper, null, false);
}
public Handler(@NonNull Looper looper, @Nullable Callback callback) {
    this(looper, callback, false);
}

总结下

• 这下清楚了！假设不做特别设置的话：默许音讯都是同步音讯
• 默许音讯都会给其target变量赋值：默许音讯都不是同步屏障音讯

7.1.3.生成同步屏障音讯

在next办法中发现，target为null的音讯被称为同步屏障音讯，那他为啥叫同步屏障音讯呢？

• postSyncBarrier(long when)
  • sync：同步 barrier：屏障，障碍物 —> 同步屏障
  • 同步屏障实践挺能代表其含义的，它能屏蔽音讯行列中后续一切的同步办法分发

MessageQueue.java
...
@UnsupportedAppUsage
@TestApi
public int postSyncBarrier() {
    return postSyncBarrier(SystemClock.uptimeMillis());
}
private int postSyncBarrier(long when) {
    // Enqueue a new sync barrier token.
    // We don't need to wake the queue because the purpose of a barrier is to stall it.
    synchronized (this) {
        final int token = mNextBarrierToken++;
        final Message msg = Message.obtain();
        msg.markInUse();
        msg.when = when;
        msg.arg1 = token;
        Message prev = null;
        Message p = mMessages;
        if (when != 0) {
            while (p != null && p.when <= when) {
                prev = p;
                p = p.next;
            }
        }
        if (prev != null) { // invariant: p == prev.next
            msg.next = p;
            prev.next = msg;
        } else {
            msg.next = p;
            mMessages = msg;
        }
        return token;
    }
}

mMessage这个变量，标明是即将被处理的音讯，即将被回来的音讯，也能够以为，他是未处理音讯行列的头结点音讯

关于同步屏障音讯

• 从音讯池取一个可用音讯
• 这当地有个很有意思的循环操作，这while操作的，会将mMessages头结点赋值给p变量，将p节点移到当时时间音讯的下一节点
• 头结点（mMessage）是否为空
  • 不为空：由于上面的循环操作，会让p节点的音讯，必定是刚好大于当时时间刻，p节点的上一节点音讯为当时时间曩昔时间的音讯，此刻！咱们的同步屏障音讯msg，就插在这俩者之间！
  • 为空：成为头结点

同步屏障音讯是直接插到音讯行列，他没有设置target特点且不经过enqueueMessage办法，故其target特点为null

总结下：

同步屏障音讯刺进音讯行列的规律，和上面正常发送音讯刺进基本是一致的；假设音讯行列有延时音讯，延时音讯的时间大于现在的时间，同步音讯会在这些延时音讯之前。

OK，同步屏障音讯刺进，基本能够了解为：正常的非延时音讯刺进音讯行列！

同步屏障音讯刺进音讯行列流程图

7.2.同步屏障流程

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;
            }
            ...
        }
        ...
    }
}

去掉很多咱们无需重视的代码，发现这也没啥嘛，便是一堆if eles for之类的，来剖析剖析

1.Message msg = mMessages：这步赋值是非常重要的，标明即使咱们对msg一顿操作，mMessage仍是保存音讯行列头结点音讯的方位 2.msg.target == null：遇到同步屏障音讯

• 首要是一个while循环，内部逻辑，不断将msg节点的方位后移
• 完毕while的俩个条件
  • msg移到尾结点，也便是移到了音讯行列尾结点，将本身赋值为null（尾结点的next）
  • 遇上标记为异步的音讯，放行该音讯进行后续分发

3.剖析下，俩个放行条件产生的不同影响

• 音讯行列不含异步音讯

  • 当咱们在同步屏障逻辑里边，将msg本身移到尾结点，并赋值为null（尾结点的next）
  • msg为null，是无法进行后续分发操作，会从头进行循环流程
  • mMessage头结点从头将本身方位赋值给msg，持续上述的重复进程
  • 能够发现，上述逻辑确实起到了同步屏障的效果，屏蔽了其一切后续同步音讯的分发；只需移除音讯行列中的该条同步屏障音讯，才干持续进行同步音讯的分发

• 音讯行列含有异步音讯

  • 音讯行列中假设有异步音讯，同步屏障的逻辑会放行异步音讯
  • 同步屏障里边堆prevMsg赋值了！请记住在整个办法里边，只需同步屏障逻辑里边堆prevMsg赋值了！这个参数为null与否，对音讯行列节点影响很大
  • prevMsg为空：会直接将msg的next赋值给mMessage；阐明分发完音讯后，会直接移除头结点，将头结点的下一节点赋值为头结点
  • prevMsg不为空：不会对mMessage投节点操作；会将分发音讯的上一节点的下一节点方位，换成分发节点的下一节点，有点绕
  • 经过上面剖析，可知；异步音讯分发完后，会将其直接从音讯行列中移除，头结点方位不变

文字写了一大堆，我也是尽或许具体描绘，同步屏障逻辑代码块会产生的影响，整个图，加深下形象！

8.同步屏障效果

那么这个同步屏障有什么效果呢？

有个急需的问题，便是什么当地用到了postSyncBarrier(long when)办法，这个办法对外是不露出的，只需内部包能够调用

查找了整个源码包，发现只需几个当地运用了它，剔除测试类，MessageQueue类，有效果的便是：ViewRootImpl类和Device类

8.1.Device类

• pauseEvents()：Device内部触及的是翻开设备的时分，会增加一个同步屏障音讯，屏蔽后续一切的同步音讯处理

  • pauseEvents()是Device类中私有内部类DeviceHandler的办法
    • 这阐明，咱们无法调用这个办法；事实上，咱们连Device类都无法调用，Device归于被隐藏的类，和他同一目录的还有Event和Hid，这些类体系都不想对外露出
    • 这就很鸡贼了，阐明刺进同步屏障的音讯的办法，体系确实不想对外露出；当然不包括非常规办法：反射

• 同步屏障增加：开机时，增加同步屏障

Device.java
...
private class DeviceHandler extends Handler {
    ...
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case MSG_OPEN_DEVICE:
                ...
                pauseEvents();
                break;
            ...
        }
    }
    public void pauseEvents() {
        mBarrierToken = getLooper().myQueue().postSyncBarrier();
    }
    public void resumeEvents() {
        getLooper().myQueue().removeSyncBarrier(mBarrierToken);
        mBarrierToken = 0;
    }
}

同步屏障移除：完结开机后，移除同步屏障

Device.java
...
private class DeviceHandler extends Handler {
    ...
    public void pauseEvents() {
        mBarrierToken = getLooper().myQueue().postSyncBarrier();
    }
    public void resumeEvents() {
        getLooper().myQueue().removeSyncBarrier(mBarrierToken);
        mBarrierToken = 0;
    }
}
private class DeviceCallback {
    public void onDeviceOpen() {
        mHandler.resumeEvents();
    }
    ....
}

Device中运用同步屏障全体进程比较简略，这儿简略描绘下

• 翻开设备时，会发送一个同步屏障音讯，屏蔽后续一切同步音讯
• 完结开机后，移除同步屏障音讯
• 总结：很明显，这是尽量的提升翻开设备速度，不被其它次等重要的作业搅扰

8.2.ViewRootImpl类

scheduleTraversals()：非常重要的办法

ViewRootImpl.java
...
void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
        mChoreographer.postCallback(
            Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
        notifyRendererOfFramePending();
        pokeDrawLockIfNeeded();
    }
}

关于上面的办法的剖析，全体流程比较费事，触及到整个改写进程的剖析,给出了一个非常重要的定论.

咱们调用View的requestLayout或许invalidate时，终究都会触发ViewRootImp履行scheduleTraversals()办法。这个办法中ViewRootImp会经过Choreographer来注册个接纳Vsync的监听，当接纳到体系体层发送来的Vsync后咱们就履行doTraversal()来从头制作界面。经过上面的剖析咱们调用invalidate等改写操作时，体系并不会当即改写界面，而是等到Vsync音讯后才会改写页面。

咱们知道了界面改写（requestLayout或许invalidate）的进程一定会触发scheduleTraversals()办法，这阐明会增加同步屏障音讯，那必定有移除同步屏障音讯的进程，这个进程很有或许存在doTraversal()办法中，来看下这个办法

• doTraversal()：removeSyncBarrier！我giao！果然在这当地！
  • 这当地做了俩件事：移除同步屏障（removeSyncBarrier）、制作界面（performTraversals）

void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
        if (mProfile) {
            Debug.startMethodTracing("ViewAncestor");
        }
        performTraversals();
        if (mProfile) {
            Debug.stopMethodTracing();
            mProfile = false;
        }
    }
}

doTraversal()是怎样被调用呢？ 调用：mTraversalRunnable在scheduleTraversals()中运用了

final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
void scheduleTraversals() {
    if (!mTraversalScheduled) {
        ...
        mChoreographer.postCallback(
            Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
      ...
    }
}
final class TraversalRunnable implements Runnable {
    @Override
    public void run() {
        doTraversal();
    }
}

postCallback是Choreographer类中办法，该类触及巨多的音讯传递，并且都是运用了异步音讯setAsynchronous(true)，这些都是和界面改写相关，所以都是优先处理，完好的流程能够看上面贴的文章

postCallback的中心便是让DisplayEventReceiver注册了个Vsync的告诉，后期收到送来的Vsync后，咱们就履行doTraversal()来从头制作界面

8.3.总结

经过上面的对ViewRootImpl阐明，需求来总结下同步屏障对界面制作进程的影响

具体版总结

调用View的requestLayout或许invalidate时，终究都会履行scheduleTraversals()，此刻会在主线程音讯行列中刺进一个同步屏障音讯（停止一切同步音讯分发），会将mTraversalRunnable增加到mCallbackQueues中，并注册接纳Vsync的监听，当承受到Vsync告诉后，会发送一个异步音讯，触发遍历履行mCallbackQueues的办法，这会履行咱们增加的回调mTraversalRunnable，然后履行doTraversal()，此刻会移除主线程音讯行列中同步屏障音讯，最终履行制作操作

通俗版总结

调用requestLayout或许invalidate时，会在主线程音讯行列中刺进一个同步屏障音讯，一起注册接纳Vsync的监听；当承受到Vsync告诉，会发送一个异步音讯，履行真实的制作作业：此刻会移除音讯行列中的同步屏障音讯，然后才会履行制作操作

下面画了个流通图示

9.总结

9.1.音讯刺进比照

有个很重要的作业，咱们再来看下：正常发送音讯和同步屏障音讯刺进音讯行列直接的差异，见下图

• 取音讯：关于取音讯，都是取的mMessage，能够了解为，取音讯行列的头结点
• 非延时音讯在同步屏障音讯之前发送，都会排在同步屏障音讯之前
• 延时音讯，假设时间大于发送同步屏障音讯的时间，会排在同步屏障音讯之后

9.2.Vsync

关于Vsync

• Vsync 信号一般是由硬件产生的，现在手机一般为60hz~120hz，每秒改写60到120次，一个时间片算一帧
• 每个 Vsync 信号之间的时间便是一帧的时间段

来看下履行同步音讯时间片：这图真吉儿不好画，吐血

由上图可知：某种极点状况，你所发送的音讯，在分发的时分，或许存在一帧的延时

9.3.总结

相关总结

• 同步屏障能保证音讯行列中的异步音讯，会被优先履行
• 鉴于正常音讯和同步屏障音讯刺进音讯行列的差异：同步屏障能够及时的屏障行列中的同步音讯
• 某些极点场景：发送的音讯，在分发的时分，或许会存一帧延时
  • 极点场景：Vsync信号到来之后，立马履行了RequestLayout等操作
• 同步屏障能保证在UI改写中：Vsync信号到来后，能够立马履行真实的制作页面操作

同步音讯和异步音讯运用建议

在正常的状况，必定不建议运用异步音讯，此处假定一个场景：由于某种需求，你发送了很多的异步音讯，由于音讯进入音讯行列的特别性，体系发送的异步音讯，也只能乖乖的排在你的异步音讯后面，假定你的异步音讯占据了很多的时间片，乃至占用了几帧，导致体系UI改写的异步音讯无法被及时履行，此刻很有或许产生掉帧

当然，假设你能看明白这个同步屏障栏目所写的东西，相信什么时分设置音讯为异步，心中必定有数

• 正常状况，请持续运用同步音讯
• 特别状况，需求自己发送的音讯被优先处理：能够运用异步音讯

Handler、Message、MessageQueue、Looper;

以下为零星的记载，最终有总结； 内存走漏的实质：

长生命周期目标持有短生命周期目标，导致短生命周期目标毁掉不掉；

持有链：

线程>>Looper>>MessageQueue>>Message>>Handler>>Activity;

Message目标的变量target为发送音讯的Handler; MessageQueue 行列里放Message； Looper目标里实例化MessageQueue； 一个线程绑定一个Looper；

为什么要有handler？ 首要意图是要处理线程切换问题，handler里的Message机制处理了线程间通讯;

为什么有行列MessageQueue？ MessageQueue是一个单向链表，next()调用nativePollOnce->lunx的epoll_wait()等候完结堵塞时行列；

• 在单线程中一次只能履行一句代码
• 假设发送了一个大音讯A
• 处理这个大的音讯A
• 可是处理的太慢了
• 然后导致其他后续要发送的音讯发不出去
• 由于单线程堵塞到了第3步处理那个音讯A的当地

行列的呈现处理了”处理音讯”堵塞到”发送音讯”的问题；

行列是生产者顾客形式；

而要运用行列需求至少两个线程、和一个死循环；

• 一个线程担任生产音讯；

• 一个线程消费音讯；

• 死循环需求取出放入行列里的音讯；

为什么有Looper？

为了循环取出行列里的音讯；

一个线程有几个Looper,为什么不会有多个?

一个线程一个Looper,放在ThreadLocalMap中；

假设Looper目标由Handler创立，每创立一个Handler就有一个Looper,那么调用Looper.loop()时敞开死循环；在外边调用Looper的当地就会堵塞；

主线程中Looper的死循环为什么没有导致体系卡死？

• 咱们的UI线程主线程其实是ActivityThread线程，而一个线程只会有一个Looper;
• ActivityThread.java的main函数是一个APP进程的入口，假设不卡死，main函数履行完则整个运用进程就会退出；
• android是以作业为驱动的操作体系，当有作业来时，就去做对应的处理，没有时就显现静态界面；

获取当时线程：Thread.currentThread();

ThreadLocalMap:类似于HashMap;

每个Thread目标都有一个对应的ThreadLocalMap；

在Looper.prepare()时，存入Looper，存Looper时ThreadLocalMap的key为ThreadLocal，value为Looper；

内存颤动根本的处理办法是复用；

handler.obtainMessage()；

• 从Looper的收回池中取Message；

• Message是一个单向链表，Message不是一个单纯的目标，而是一个链表调集

• 最大长度固定50个

  Linux函数: epoll_create:App注册进红黑树中，拿到一个作业fd的值； epoll_ctl：注册作业类型，监听fd是否改动（Linux中作业都会被写入文件中，如接触屏幕作业会写入到：dev/input/event0文件中），fd有改动时唤醒epoll_wait； epoll_wait：有作业时就分发，没作业就堵塞

总结： handler怎样做的线程切换的？ 首要Handler的运用进程：

• 调用Looper.prepare();

• 创立Handler目标；

• 调用Looper.Loop()办法。

• 线程中发送音讯。

在第一步时，创立一个Looper，并放到当时线程的变量threadLocals中；threadLocals是一个map，key为ThreadLocal目标本身，value为Looper;在Looper.loop()时取出；

第二步,用户在当时线程（或许是子线程）创立Handler目标；

第三步，Looper.loop()一向在死循环，Looper.loop()这句代码下面的代码是不会被调用的，调用Looper.loop()函数时，先从当时线程的map变量中取出Looper,再从Looper中拿到行列MessageQueue，for循环中不断从行列中取出音讯；

第四步，在其他线程调用handelr发送音讯时，Message里有个target,便是发送音讯的handler;

在Looper.loop()时，行列中取到音讯时，调用msg.target.dispatchMessage(msg)；其实便是handler目标.dispatchMessage(msg);

所以不论在哪个线程调用发送音讯，都会调用到handler自己分发音讯；而handler所处的线程是创立时的“当时线程”，所以处理时也就回到了“当时线程”；完结了线程切换，和线程通讯；

Looper的死循环为什么不会让主线程卡死（或ANR）？ 简略版：

• 咱们的UI线程主线程其实是ActivityThread地点的线程，而一个线程只会有一个Looper;
• ActivityThread.java的main函数是一个APP进程的入口，假设不一向循环，则在main函数履行完最终一行代码后整个运用进程就会退出；
• android是以作业为驱动的操作体系，当有作业来时，就去做对应的处理，没有时就显现静态界面；
• ANR产生条件是： Activity：5 秒。运用在 5 秒内未响运用户的输入作业（如按键或许接触） BroadCastReceiver ：10 秒。BroadcastReceiver 未在 10 秒内完结相关的处理 Service：20 秒（均为前台）。Service 在20 秒内无法处理完结
• 假设Handler收到以上三个相应作业在规定时间内完结了，则移除音讯，不会ANR；若没完结则会超时处理，弹出ANR对话框；

具体：

1. App进程的入口为ActivityThread.java的main()函数，留意ActivityThread不是一个线程；
2. 运用的ui主线程实践是调用ActivityThread.java的main()函数履行时地点的线程,而这个线程对咱们不行见，可是这便是主线程；参阅：
3. 在ActivityThread.java的main()函数中，会调用Looper.prepareMainLooper();
4. Looper.prepareMainLooper()会创立一个Looper并放到当时线程（主线程）的变量threadLocals中进行绑定，threadLocals是一个ThreadLocal.ThreadLocalMap；
5. 在ActivityThread.java的main()函数结尾，敞开Looper.loop()进行死循环，不让main函数完毕，然后让App进程不会完毕；
6. Android体系是以作业作为驱动的操作体系，当有作业来时，就去做对应处理，没有作业时，就显现当时界面，不做其他多余操作（浪费资源）；
7. 在Looper.loop()的死循环中，不只要取用户发的作业，还要取体系内核发的作业（如屏幕亮度改动等等）；
8. 在调用Looper.loop()时，从MessageQueue.next()中获取作业，若没有则堵塞，有则分发；
9. MessageQueue其实不是一个行列，用epoll机制完结了堵塞；
10. 在Looper.prepareMainLooper()时，调用c++函数epoll_create()会将App注册进epoll机制的红黑树中得到fd的值，epoll_ctl()给每个App注册作业类型并监听fd值是否改动，fd有改动时唤醒epoll_wait；
11. epoll_wait()有作业时就分发，没作业就堵塞

子线程的Looper和子线程Looper有什么不同？

子线程Looper是能够退出的，主线程不行；

三丶LiveData作业机制

LiveDate作业作业一共有以下内容：

LiveDate粘性作业Framework源码剖析 Jetpack中的状况机是怎样办理生命周期 Hook完结LiveDate非粘性功用 LiveDate递归调用源码是怎样做容错的

1.3.1.liveData粘性作业 粘性作业：相比照一般作业，粘性作业支持先发送作业，再去注册订阅者。一旦完结订阅动作，这个订阅者就会接纳到该粘性作业。 所以粘性其实就能够了解为调查者形式的晋级，让调查者与被调查者目标之间愈加的粘合。

举个栗子，咱们运用liveData来做APP的大局状况办理

object GlobalState {
       val jcTestNumberLd: MutableLiveData<Int> = MutableLiveData<Int>()
   }

然后在 Fragment 以及 Activity 中调查该 jcTestNumberLd。

/** 调查 GlobalState 的 Activity */
  class JcTestActivity : BaseVmDbActivity<MainViewModel, ActivityJcTestBinding>() {
      override fun initView() {
          viewBinding.incButton.setOnClickListener {
              GlobalState.jcTestNumberLd.value =
                  if (GlobalState.jcTestNumberLd.value == null) {
                      1
                  } else {
                      GlobalState.jcTestNumberLd.value!!.toInt().inc()
                  }
          }
      }
      override fun initObserve() {
          GlobalState.jcTestNumberLd.observe(this, {
              Log.e(TAG, "initObserve: jctestNumber = $it")
          })
      }
      ........
  }
  /** 调查 GlobalState 的 Fragment */
  class EventFragment : BaseVmDbFragment<EventViewModel, FragmentEventBinding>() {
      override fun setObservers() {
          GlobalState.jcTestNumberLd.observe(viewLifecycleOwner, {
              Log.e(TAG, "setObservers: jctestNumber = $it", )
          })
      }
      ........
  }

留意：这儿比如中的 EventFragment 并不是相关到 JcTestActivity 的。用户会先进入到 JcTestActivity，然后由用户操控进入到另一个Activity中，加载 EventFragment。

咱们来履行一下以下五步操作，来看一下输出的日志。

• 当咱们第一次进入 JcTestActivity 时，注册了调查者，没有接纳到调查作业，所以也就不会履行调查动作。
• 然后咱们点击自增按钮为jcTestNumberLd 赋予新值，接纳到调查作业，履行调查动作，输出 1。
• 再次点击自增按钮，有调查作业，履行调查动作，输出 2。
• 再次点击自增按钮，有调查作业，履行调查动作，输出 3。
• 然后咱们到 EventFragment 中，注册新的调查者，发现直接接纳到调查作业，履行调查动作，输出 3。

输出成果：

E/JcTestActivity: initObserve: jctestNumber = 1
  E/JcTestActivity: initObserve: jctestNumber = 2
  E/JcTestActivity: initObserve: jctestNumber = 3
  E/EventFragment: setObservers: jctestNumber = 3

这便是粘性作业！所以说，LiveData是粘性的。

1.3.2.LiveData 是怎样完结粘性的呢？ 在知道LiveData是粘性后，我不经问自己：它是怎样完结粘性的呢？

这儿咱们先来回顾一下EventBus粘性作业的完结原理。

EventBus在发送粘性作业时，会将这粘性作业存到一个叫做 stickyEvents 的调集中，然后等注册订阅新的调查者目标时，会去遍历该调集中的粘性作业，假设有找到对应的粘性作业，就将该粘性作业发送给该调查者。（假设你对EventBus粘性作业不熟悉，能够点击EventBus 源码解析（很细 很长）进一步了解学习。）

LiveData是不是也是以同样的原理来完结粘性的呢？

public LiveData(T value) {
      mData = value;
      mVersion = START_VERSION + 1;
  }
  /**
   * Creates a LiveData with no value assigned to it.
   */
  public LiveData() {
      mData = NOT_SET;
      mVersion = START_VERSION;
  }

从 LiveData 的结构函数中能够发现有一个 mVersion 参数，它代表着 LiveData 的版本号，每当咱们进行 setValue 时，都会让 mVersion 进行自增。

别的，ObserverWrapper 这个调查者包装类中也有一个 int mLastVersion = START_VERSION 版本号。

这两个版本号分别是被调查者目标与调查者目标的版本号，那这二者之间又有什么联系呢？

在判别是否告诉调查者的 considerNotify(ObserverWrapper observer)办法中，会对这两个版本号进行比较。

private void considerNotify(ObserverWrapper observer) {
      ...省略代码...
     //假设调查者的版本号 >= LiveData的版本号，就阐明该调查者现已接纳过该调查作业，也就不再分发。
      if (observer.mLastVersion >= mVersion) {
          return;
      }
      //反之，分发调查作业给该调查者，让其履行对应的调查动作，并更新调查者的版本号
      observer.mLastVersion = mVersion;
      observer.mObserver.onChanged((T) mData);
  }

概括一下：根据比对调查者目标的版本号与LiveData的版本号来判别是否分发当时版本的数据给该调查者。假设调查者目标的版本号大于等于LiveData的版本号，也就阐明该调查者现已接纳过当时版本的数据了，也就不需求再次分发了（等候下一次数据更新）。反之，则分发当时版本的数据给该调查者，让其履行对应的调查动作，并更新调查者的版本号，也便是更新为LiveData的版本号。

1.3.3.Google为何要将LiveData设计成粘性的 LiveData 是可调查的数据存储器类，这样也就意味着存储在LiveData中的数据是会更新的，已然是会更新的，那必定就会存在状况，即最新数据状况。

所以，当数据状况产生改动时（数据产生了更新），LiveData需求告诉一切处于活泼状况的调查者， 让其同步更新数据。这应该很好了解了，由于这便是一般作业，先注册调查者，再去更新被调查者目标，触发调查作业。

那这时，你再去新注册一个调查者目标，你以为它需不需求知道此刻LiveData最新的数据呢？

答案是：需求。

由于一切的调查者，都只需求知道LiveData中存储的数据，并且是最新数据。不论我是新注册的调查者，只需你LiveData有了最新数据，就需求告诉我。而关于有无新数据，从代码上体现出来的便是，LiveData.mVersion > Observer.mLastVersion 。

这也便是粘性作业，先更新被调查者目标，触发调查作业，再去注册调查者，调查者会直接接纳到该调查作业，履行对应的调查动作。

它的功用特点导致其只能是粘性的。

1.3.4.LiveData订阅与数据分发 运用

public class LiveDataActivity extends AppCompatActivity {
      MutableLiveData liveData= new MutableLiveData<String>();
      void liveDataTest(){
          //  任何线程都能够发送数据
          liveData.postValue("postValue");
          // 只需主线程能够发送数据
          // liveData.setValue("setValue")
      }
      void observeTest(){
          //订阅
          liveData.observe(this, new Observer<String>() {
              @Override
              public void onChanged(String data) {
                  //收到数据data
              }
          });
          //能够有多个订阅
          liveData.observe(this, new Observer<String>() {
              @Override
              public void onChanged(String data) {
                  //收到数据data
              }
          });
      }
  }

阶段一： postValue:

protected void postValue(T value) {
        boolean postTask;
        synchronized (mDataLock) {
            postTask = mPendingData == NOT_SET;
            mPendingData = value;
        }
        if (!postTask) {
            return;
        }
        ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);
    }

• 将用户发送的数据给到一个 mPendingData 的变量；
• 切换到主线程
• 履行了一个mPostValueRunnable；

mPostValueRunnable:

volatile Object mPendingData = NOT_SET;
    private int mVersion;
    private final Runnable mPostValueRunnable = new Runnable() {
        @SuppressWarnings("unchecked")
        @Override
        public void run() {
            Object newValue;
            synchronized (mDataLock) {
                newValue = mPendingData;
                mPendingData = NOT_SET;
            }
            setValue((T) newValue);
        }
    };

• 在mPostValueRunnable中将mPendingData给到了新的临时变量newValue；
• mPendingData的值置为空；
• 调用setValue(newValue);

setValue:

private volatile Object mData;
    private int mVersion;    
    @MainThread
    protected void setValue(T value) {
        assertMainThread("setValue");
        mVersion++;
        mData = value;
        dispatchingValue(null);
    }

• 将数据版本mVersion +1；
• 将发送的数据给到了mData;
• 调用分发数据dispatchingValue

看到这儿发现，数据其实最终存到了mData中；若想发送订阅音讯，必定得增加订阅者；

阶段二： 增加订阅者，observe():

/用户运用：
        //liveData.observe(this@LiveDataActivity,{
        //    
        //})
    private SafeIterableMap<Observer<? super T>, ObserverWrapper> mObservers =
            new SafeIterableMap<>();
    @MainThread
    public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {
        assertMainThread("observe");
        //假设被调查者的生命周期是DESTROYED，就不增加订阅者
        if (owner.getLifecycle().getCurrentState() == DESTROYED) {
            // ignore
            return;
        }
        LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
        ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
        ...
        owner.getLifecycle().addObserver(wrapper);
    }

• 将有生命周期的Activity和订阅者Observer传了进来；
• 判别Activity的生命周期；
• 将Activity和Observer封装为一个LifecycleBoundObserver目标；
• 将LifecycleBoundObserver放到了mObservers这个Map调集中；
• map的key为调查者，value为封装了activity和调查者Observer的目标LifecycleBoundObserver；

LifecycleBoundObserver及它的父类ObserverWrapper：

class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {
        @NonNull
        final LifecycleOwner mOwner;
        LifecycleBoundObserver(@NonNull LifecycleOwner owner, Observer<? super T> observer) {
            super(observer);
            mOwner = owner;
        }
        ...
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source,
                @NonNull Lifecycle.Event event) {
            Lifecycle.State currentState = mOwner.getLifecycle().getCurrentState();
            if (currentState == DESTROYED) {
                removeObserver(mObserver);
                return;
            }
            Lifecycle.State prevState = null;
            while (prevState != currentState) {
                prevState = currentState;
                activeStateChanged(shouldBeActive());
                currentState = mOwner.getLifecycle().getCurrentState();
            }
        }
        ...
        @Override
        void detachObserver() {
            mOwner.getLifecycle().removeObserver(this);
        }
    }
    //ObserverWrapper
    private abstract class ObserverWrapper {
        //传进来的调查者放这儿了
        final Observer<? super T> mObserver;
        boolean mActive;
        int mLastVersion = START_VERSION;
        ObserverWrapper(Observer<? super T> observer) {
            mObserver = observer;
        }
        ...
        void activeStateChanged(boolean newActive) {
            if (newActive == mActive) {
                return;
            }
            mActive = newActive;
            changeActiveCounter(mActive ? 1 : -1);
            if (mActive) {
                dispatchingValue(this);
            }
        }
   }

• 将有生命周期的Activity给到了LifecycleBoundObserver的mOwner；
• 将调查者给到了LifecycleBoundObserver的父类ObserverWrapper的mObserver；
• 其实LifecycleBoundObserver就能够获取到Activity和mObserver；
• 上一步，看到将封装后的LifecycleBoundObserver放到了mObservers这个map中；
• map的key为调查者，value为封装了activity和调查者Observer的目标LifecycleBoundObserver；

阶段三: 分发： 在阶段一setValue()时，调用了dispatchingValue(null);

void dispatchingValue(@Nullable ObserverWrapper initiator) {
        if (mDispatchingValue) {
            mDispatchInvalidated = true;
            return;
        }
        mDispatchingValue = true;
        do {
            mDispatchInvalidated = false;
            if (initiator != null) {
                considerNotify(initiator);
                initiator = null;
            } else {
                for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =
                        mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
                    considerNotify(iterator.next().getValue());
                    if (mDispatchInvalidated) {
                        break;
                    }
                }
            }
        } while (mDispatchInvalidated);
        mDispatchingValue = false;
    }
    private void considerNotify(ObserverWrapper observer) {
        if (!observer.mActive) {
            return;
        }
        ...
        if (observer.mLastVersion >= mVersion) {
            return;
        }
        observer.mLastVersion = mVersion;
        observer.mObserver.onChanged((T) mData);
    }

• 当为null时，走到了for循环
• 循环取出map中的value,而value便是LifecycleBoundObserver；
• LifecycleBoundObserver中有mObserver，mObserver便是用户传的调查者；
• mObserver.onChanged((T) mData);
• 完结了“自动”分发；

字数约束分为上下两篇

重视大众号：Android苦做舟
解锁 《Android十大板块文档》，让学习更靠近未来实战。已形成PDF版

内容如下：

1.2022最新Android11位大厂面试专题，128道附答案
2.音视频大合集，从初中高到面试包罗万象
3.Android车载运用大合集，从零开端一同学
4.功用优化大合集，离别优化烦恼
5.Framework大合集，从里到外剖析的明明白白
6.Flutter大合集，进阶Flutter高级工程师
7.compose大合集，拥抱新技术
8.Jetpack大合集，全家桶一次吃个够
9.架构大合集，轻松应对作业需求
10.Android根底篇大合集，根基安定楼房平地起

收拾不易，重视一下吧。开端进入正题，ღ( ･ᴗ･` )