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对话框；

具体：

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

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

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

前言

字数约束分为上下两篇

一丶Android Binder

1.为什么要用Binder？

2.APP多进程的长处

3.多进程通讯原理

4.多进程通讯有哪些办法？

5.Binder相对其他IPC办法长处/为什么运用Binder？

6.Binder在Android体系CS通讯机制中起到的效果

二丶Android Handler

1.总流程

2.运用

3.prepare和loop

4.收发音讯

5.分发音讯

6.IdIeHandler

7.同步屏障

8.同步屏障效果

9.总结

三丶LiveData作业机制

字数约束分为上下两篇

相关文章

DynamicImport实现原理

go sync.Map 设计与实现

AIDL 跨进程通信学习实验 API34

DevOps 到底是什么意思？

作者信息

5.`Binder`相对其他`IPC`办法长处/为什么运用`Binder`？