Handler+Binder；看完这一篇就理解了

Posted 2022-09-05 初一十五啊

前言

在说Handler和binder之前，我们先看看关于Framework都有什么内容

1.Framework通信（Binder，Handler，Livedata）
2.Framework底层服务（AMS，PMS，WMS）
3.Framework系统资源（ServiceManager,Contxt,Resource）
4.Framework事件机制
5.Framework UI机制（UI绘制原理，UI自定义）

今天先来分析一下Handler和Binder相关视频

一丶Handler

Handler、Message、MessageQueue、Looper;

以下为零散的记录，最后有总结； 内存泄露的本质：

长生命周期对象持有短生命周期对象，导致短生命周期对象销毁不掉；

持有链：

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

Message对象的变量target为发送消息的Handler; MessageQueue 队列里放Message； Looper对象里实例化MessageQueue； 一个线程绑定一个Looper；

为什么要有handler？ 主要目的是要解决线程切换问题，handler里的Message机制解决了线程间通信;

为什么有队列MessageQueue？ MessageQueue是一个单向链表，next()调用nativePollOnce->lunx的epoll_wait()等待实现阻塞时队列；

• 在单线程中一次只能执行一句代码

• 假如发送了一个大消息A

• 处理这个大的消息A

• 但是处理的太慢了

• 从而导致其他后续要发送的消息发不出去

• 因为单线程阻塞到了第3步处理那个消息A的地方

队列的出现解决了"处理消息"阻塞到"发送消息"的问题；

队列是生产者消费者模式；

而要使用队列需要至少两个线程、和一个死循环；

• 一个线程负责生产消息；

• 一个线程消费消息；

• 死循环需要取出放入队列里的消息；

为什么有Looper？

为了循环取出队列里的消息；

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

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

假如Looper对象由Handler创建，每创建一个Handler就有一个Looper,那么调用Looper.loop()时开启死循环；在外边调用Looper的地方就会阻塞；

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

• 我们的UI线程主线程其实是ActivityThread线程，而一个线程只会有一个Looper;

• ActivityThread.java的main函数是一个APP进程的入口，如果不卡死，main函数执行完则整个应用进程就会退出；

• android是以事件为驱动的操作系统，当有事件来时，就去做对应的处理，没有时就显示静态界面；

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

ThreadLocalMap:类似于HashMap;

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

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

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

handler.obtainMessage()；

• 从Looper的回收池中取Message；

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

• 最大长度固定50个

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

  

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

• 调用Looper.prepare();

• 创建Handler对象；

• 调用Looper.Loop()方法。

• 线程中发送消息。

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

第二步,用户在当前线程（可能是子线程）创建Handler对象；

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

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

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

所以不论在哪个线程调用发送消息，都会调用到handler自己分发消息；而handler所处的线程是创建时的“当前线程”，所以处理时也就回到了“当前线程”；实现了线程切换，和线程通信；

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

• 我们的UI线程主线程其实是ActivityThread所在的线程，而一个线程只会有一个Looper;

• ActivityThread.java的main函数是一个APP进程的入口，如果不一直循环，则在main函数执行完最后一行代码后整个应用进程就会退出；

• android是以事件为驱动的操作系统，当有事件来时，就去做对应的处理，没有时就显示静态界面；

• ANR发生条件是：
  Activity：5 秒。应用在 5 秒内未响应用户的输入事件（如按键或者触摸）
  BroadCastReceiver ：10 秒。BroadcastReceiver 未在 10 秒内完成相关的处理
  Service：20 秒（均为前台）。Service 在20 秒内无法处理完成

• 如果Handler收到以上三个相应事件在规定时间内完成了，则移除消息，不会ANR；若没完成则会超时处理，弹出ANR对话框；

详细：

• App进程的入口为ActivityThread.java的main()函数，注意ActivityThread不是一个线程；

• 应用的ui主线程实际是调用ActivityThread.java的main()函数执行时所在的线程,而这个线程对我们不可见，但是这就是主线程；参考：

• 在ActivityThread.java的main()函数中，会调用Looper.prepareMainLooper();

• Looper.prepareMainLooper()会创建一个Looper并放到当前线程（主线程）的变量threadLocals中进行绑定，threadLocals是一个ThreadLocal.ThreadLocalMap；

• 在ActivityThread.java的main()函数结尾，开启Looper.loop()进行死循环，不让main函数结束，从而让App进程不会结束；

• Android系统是以事件作为驱动的操作系统，当有事件来时，就去做对应处理，没有事件时，就显示当前界面，不做其他多余操作（浪费资源）；

• 在Looper.loop()的死循环中，不仅要取用户发的事件，还要取系统内核发的事件（如屏幕亮度改变等等）；

• 在调用Looper.loop()时，从MessageQueue.next()中获取事件，若没有则阻塞，有则分发；

• MessageQueue其实不是一个队列，用epoll机制实现了阻塞；

• 在Looper.prepareMainLooper()时，调用c++函数epoll_create()会将App注册进epoll机制的红黑树中得到fd的值，epoll_ctl()给每个App注册事件类型并监听fd值是否改变，fd有改变时唤醒epoll_wait；

• epoll_wait()有事件时就分发，没事件就阻塞

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

子线程Looper是可以退出的，主线程不行；

二丶Binder

进程隔离：

内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据 为了保证系统的安全，用户空间和内核空间是天然隔离的 每个进程有自己的虚拟内存空间，为了安全，每个进程只能操作自己的虚拟内存空间，只有操作系统才有权限操作物理内存空间

为什么要用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这套通信框架；