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

Posted 初一十五啊

tags:

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

前言

本文为Framework大合集,从里到外分析的透彻内容如下:

一丶Framework源码面试

  • Acitivity启动流程
  • Handler面试合集
  • 事件传递机制
  • onMeasure测量原理
  • android屏幕刷新机制

二丶Framework通信

  • Binder
  • Handler
  • livedata事件机制

三丶Framework底层服务

  • AMS
  • PMS
  • IMS
  • WMS

四丶Framework事件机制

  • Android事件处理的三种方式
  • onInterceptTouchEvent拦截流程解析

关注+评论(笔记),提前解锁 《整套50W字Android体系PDF》,让学习更贴近未来实战。

50W字Android体系PDF,腾讯T10级Android高级工程师成长;内容全在这里了

总共囊括

1.腾讯Android开发笔记(33W字)

2.2022最新Android十一位大厂面试专题(12W字)

3.音视频经典面试题(6W字)

一丶Framework源码面试

先来看几个关于Framework源码的面试内容:(之前讲过)
①Framework源码面试:activity启动流程
②Framework源码面试:2.Handler面试集合
③Framework源码面试:3.事件传递机制
④Framework源码面试:4.onMeasure测量原理
⑤Framework源码面试:5.Android屏幕刷新机制

二丶Framework通信

一丶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传输数据的过程:一次拷贝

内存映射:MMAPmemory map

虚拟内存和物理内存

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

2.易用性

3.安全性

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

  • Binder机制的关键概念

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



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

二丶Android Handler

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

鄙人也来炒个剩饭,力求通俗易懂的来描述下Handler机制的整个流程;相关知识点,画了一些流程图,时序图来展示其运行机制,力争让本文图文并茂!

考点

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作用的总体印象,下面画了一个总体的流程图

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

  • 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();
    ...

...

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

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

  • 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里,这是我们最直观的接触的点,下方的思维导图整体做了个概括。

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;

...

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

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

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

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

  • 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是在消息分发的空闲时刻,专门用来处理相关事物的

以上是关于Framework大合集:从里到外分析的明明白白的主要内容,如果未能解决你的问题,请参考以下文章

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

从里到外,手把手一起把JVM虚拟机整体结构与对象内存分配解析摸透透的,简单易懂!

史上最强 iPad Pro 发布,从内到外全面升级

PHP(css样式)

xml建模

测试工程师进阶面试题目大合集