Framework大合集,从里到外分析的明明白白(上)

·  阅读 1283
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;
  • 对比:

image.png Binder的一次拷贝发生在用户空间拷贝到内核空间;

用户空间: App进程运行的内存空间;

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

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

MMU:内存管理单元;

给CPU提供虚拟地址;

当对变量操作赋值时:

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

物理地址: 物理内存的实际地址,并不是磁盘;

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

image.png

image.png

页命中: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发送的数据
  • 通过内存映射关系,只发生了一次拷贝

image.png

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:数据接收角色

image.png 编译器生成的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.多进程通信原理

image.png

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

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

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

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

image.png

1.性能:

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

image.png

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

image.png

内存映射:MMAPmemory map

虚拟内存和物理内存

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

2.易用性

3.安全性

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

  • Android C/S通信机制

image.png

  • Binder机制的关键概念

image.png

  • BinderAndroid CS通信机制中起到的作用

image.png

image.png

image.png

image.png

AIDLBinder的关系? AIDL封装了BinderAIDL调用Binder

二丶Android Handler

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

image.png

考点

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秒内没有执行完毕;ContentProviderpublish在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作用的总体印象,下面画了一个总体的流程图

image.png

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

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

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

image.png

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();
    ...
}
...
复制代码

为什么要使用prepareloop?我画了个图,先让大家有个整体印象

image.png

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

  • Looper.prepare():生成Looper对象,setThreadLocal
  • handler构造函数:通过Looper.myLooper()获取到ThreadLocalLooper对象
  • 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里,这是我们最直观的接触的点,下方的思维导图整体做了个概括。

image.png

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:就是我们发送的延时毫秒数值

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

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

4.2.发送消息

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

  • post(Runnable):发送和接受消息都在post中完成
  • sendMessage(msg):需要自己传入Message消息对象
  • 看下源码
    • 使用post会自动会通过getPostMessage方法创建Message对象
    • enqueueMessage中将生成的Message加入消息队列,注意
      • 此方法给msgtarget赋值当前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() + delayMilliswhen代表的是一个时间刻度,消息进入到消息队列,是按照时间刻度排列的,时间刻度按照从小到大排列,也就是说消息在消息队列中:按照从现在到未来的循序排队
  • 这地方有几种情况,记录下: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;
}
...
复制代码

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

image.png

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方法发送消息(必须)
        • 实现HandlerCallback回调
      • 分发的消息,会在Handler中实现的回调中 分发
  • handleMessage(msg)

    • 触发条件
      • 使用sendMessage方法发送消息(必须)
      • 未实现HandlerCallback回调
      • 实现了HandlerCallback回调,返回值为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++;
        }
    }
}
复制代码

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

image.png

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

  • 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();
}
复制代码

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

image.png

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的值

  • 因为flagsint类型,没有赋初值,故其初始值为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赋值了!
      • 说明:只要使用postsendMessage之类发送消息,其消息就绝不可能是同步屏障消息!
    • 关于同步异步,可以看见和mAsynchronous息息相关
      • 只要mAsynchronoustrue的话,我们的消息都会异步消息
      • 只要mAsynchronousfalse的话,我们的消息都会同步消息
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方法中发现,targetnull的消息被称为同步屏障消息,那他为啥叫同步屏障消息呢?

  • 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,同步屏障消息插入,基本可以理解为:正常的非延时消息插入消息队列!

同步屏障消息插入消息队列流程图

image.png

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)
    • msgnull,是无法进行后续分发操作,会重新进行循环流程
    • mMessage头结点重新将自身位置赋值给msg,继续上述的重复过程
    • 可以发现,上述逻辑确实起到了同步屏障的作用,屏蔽了其所有后续同步消息的分发;只有移除消息队列中的该条同步屏障消息,才能继续进行同步消息的分发
  • 消息队列含有异步消息

    • 消息队列中如果有异步消息,同步屏障的逻辑会放行异步消息
    • 同步屏障里面堆prevMsg赋值了!请记住在整个方法里面,只有同步屏障逻辑里面堆prevMsg赋值了!这个参数为null与否,对消息队列节点影响很大
    • prevMsg为空:会直接将msgnext赋值给mMessage;说明分发完消息后,会直接移除头结点,将头结点的下一节点赋值为头结点
    • prevMsg不为空:不会对mMessage投节点操作;会将分发消息的上一节点的下一节点位置,换成分发节点的下一节点,有点绕
    • 通过上面分析,可知;异步消息分发完后,会将其直接从消息队列中移除,头结点位置不变

文字写了一大堆,我也是尽可能详细描述,同步屏障逻辑代码块会产生的影响,整个图,加深下印象!

image.png

8.同步屏障作用

那么这个同步屏障有什么作用呢?

有个急需的问题,就是什么地方用到了postSyncBarrier(long when)方法,这个方法对外是不暴露的,只有内部包能够调用

搜索了整个源码包,发现只有几个地方使用了它,剔除测试类,MessageQueue类,有作用的就是:ViewRootImpl类和Device

8.1.Device类

  • pauseEvents()Device内部涉及的是打开设备的时候,会添加一个同步屏障消息,屏蔽后续所有的同步消息处理

    • pauseEvents()Device类中私有内部类DeviceHandler的方法
      • 这说明,我们无法调用这个方法;事实上,我们连Device类都无法调用,Device属于被隐藏的类,和他同一目录的还有EventHid,这些类系统都不想对外暴露
      • 这就很鸡贼了,说明插入同步屏障的消息的方法,系统确实不想对外暴露;当然不包括非常规方法:反射
  • 同步屏障添加:开机时,添加同步屏障

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()是怎么被调用呢? 调用:mTraversalRunnablescheduleTraversals()中使用了

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();
    }
}
复制代码

postCallbackChoreographer类中方法,该类涉及巨多的消息传递,而且都是使用了异步消息setAsynchronous(true),这些都是和界面刷新相关,所以都是优先处理,完整的流程可以看上面贴的文章

postCallback的核心就是让DisplayEventReceiver注册了个Vsync的通知,后期收到送来的Vsync后,我们就执行doTraversal()来重新绘制界面

8.3.总结

通过上面的对ViewRootImpl说明,需要来总结下同步屏障对界面绘制过程的影响

详细版总结

调用ViewrequestLayout或者invalidate时,最终都会执行scheduleTraversals(),此时会在主线程消息队列中插入一个同步屏障消息(停止所有同步消息分发),会将mTraversalRunnable添加到mCallbackQueues中,并注册接收Vsync的监听,当接受到Vsync通知后,会发送一个异步消息,触发遍历执行mCallbackQueues的方法,这会执行我们添加的回调mTraversalRunnable,从而执行doTraversal(),此时会移除主线程消息队列中同步屏障消息,最后执行绘制操作

通俗版总结

调用requestLayout或者invalidate时,会在主线程消息队列中插入一个同步屏障消息,同时注册接收Vsync的监听;当接受到Vsync通知,会发送一个异步消息,执行真正的绘制事件:此时会移除消息队列中的同步屏障消息,然后才会执行绘制操作

下面画了个流转图示

image.png

9.总结

9.1.消息插入对比

有个很重要的事情,我们再来看下:正常发送消息和同步屏障消息插入消息队列直接的区别,见下图

  • 取消息:关于取消息,都是取的mMessage,可以理解为,取消息队列的头结点
  • 非延时消息在同步屏障消息之前发送,都会排在同步屏障消息之前
  • 延时消息,如果时刻大于发送同步屏障消息的时刻,会排在同步屏障消息之后

image.png

9.2.Vsync

关于Vsync

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

来看下执行同步消息时间片:这图真吉儿不好画,吐血

image.png 由上图可知:某种极端情况,你所发送的消息,在分发的时候,可能存在一帧的延时

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的地方就会阻塞;

image.png

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

  • 我们的UI线程主线程其实是ActivityThread线程,而一个线程只会有一个Looper;
  • ActivityThread.java的main函数是一个APP进程的入口,如果不卡死,main函数执行完则整个应用进程就会退出;
  • android是以事件为驱动的操作系统,当有事件来时,就去做对应的处理,没有时就显示静态界面;

获取当前线程:Thread.currentThread();

ThreadLocalMap:类似于HashMap;

每个Thread对象都有一个对应的ThreadLocalMap;

image.png

Looper.prepare()时,存入Looper,存Looper时ThreadLocalMap的key为ThreadLocalvalueLooper

image.png

image.png

内存抖动根本的解决方式是复用;

handler.obtainMessage();

  • 从Looper的回收池中取Message;

  • Message是一个单向链表,Message不是一个单纯的对象,而是一个链表集合

  • 最大长度固定50个

    Linux函数: epoll_create:App注册进红黑树中,拿到一个事件fd的值; epoll_ctl:注册事件类型,监听fd是否改变(Linux中事件都会被写入文件中,如触摸屏幕事件会写入到:dev/input/event0文件中),fd有改变时唤醒epoll_wait; epoll_wait:有事件时就分发,没事件就阻塞

image.png

总结: handler如何做的线程切换的? 首先Handler的使用步骤:

  • 调用Looper.prepare();

  • 创建Handler对象;

  • 调用Looper.Loop()方法。

  • 线程中发送消息。

在第一步时,创建一个Looper,并放到当前线程的变量threadLocals中;threadLocals是一个map,key为ThreadLocal对象本身,value为Looper;在Looper.loop()时取出;

image.png

第二步,用户在当前线程(可能是子线程)创建Handler对象;

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

image.png

第四步,在其他线程调用handelr发送消息时,Message里有个target,就是发送消息的handler;

image.png

Looper.loop()时,队列中取到消息时,调用msg.target.dispatchMessage(msg);其实就是handler对象.dispatchMessage(msg);

image.png

所以不论在哪个线程调用发送消息,都会调用到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.javamain()函数中,会调用Looper.prepareMainLooper();
  4. Looper.prepareMainLooper()会创建一个Looper并放到当前线程(主线程)的变量threadLocals中进行绑定,threadLocals是一个ThreadLocal.ThreadLocalMap;
  5. ActivityThread.javamain()函数结尾,开启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的生命周期;
  • ActivityObserver封装为一个LifecycleBoundObserver对象;
  • LifecycleBoundObserver放到了mObservers这个Map集合中;
  • mapkey为观察者,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给到了LifecycleBoundObservermOwner
  • 将观察者给到了LifecycleBoundObserver的父类ObserverWrappermObserver
  • 其实LifecycleBoundObserver就可以获取到ActivitymObserver
  • 上一步,看到将封装后的LifecycleBoundObserver放到了mObservers这个map中;
  • mapkey为观察者,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中有mObservermObserver就是用户传的观察者;
  • 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基础篇大合集,根基稳固高楼平地起

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

分类:
Android
收藏成功!
已添加到「」, 点击更改