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
传输数据的过程:一次拷贝
内存映射: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
之类的考点答案肯定很难忘。。。虽然考官很多时候不屑问,但是要是问到了,你忘了且不知道怎么回答,那就很尴尬了。
鄙人也来炒个剩饭,力求通俗易懂的来描述下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秒内没有执行完毕;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
- 默认最大容量为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
是在消息分发的空闲时刻,专门用来处理相关事物的