代理检测线程异常 Handler+Binder；看完这一篇就理解了

前言

在说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

Framework大全私信：Framework

一丶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()等待实现阻塞时队列；

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

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

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

为什么有Looper？

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

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

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

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

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

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

ThreadLocalMap:类似于HashMap;

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

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

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

handler.obtainMessage()；

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

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

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

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

image.png

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

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

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

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

详细：

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

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

Framework大全私信：Framework

二丶Binder

进程隔离：

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

为什么要用Binder？

Binder的一次拷贝发生在用户空间拷贝到内核空间；

用户空间： App进程运行的内存空间；

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

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

MMU:内存管理单元；

给CPU提供虚拟地址；

当对变量操作赋值时：

物理地址： 物理内存的实际地址,并不是磁盘；

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

页命中：CPU读取变量时，MMU在物理内存的页表中找到了这个地址；

页未命中：CPU读取变量时，MMU在物理内存的页表中没有找到了这个地址，此时会触发MMU去磁盘读取变量并存到物理内存中；

普通的二次拷贝：

应用A拷贝到服务端：coay_from_user

从服务端拷贝到应用B：coay_to_user

mmap():

共享内存进程通信：

Binder通信原理：

角色：Server端A、Client端B、Binder驱动、内核空间、物理内存

Activity跳转时，最多携带1M-8k（1兆减去8K）的数据量；

真实数据大小为：1M内存-两页的请求头数据=1M-8K；

应用A直接将数据拷贝到应用B的物理内存空间中，数据量不能超过1M-8K；拷贝次数少了一次，少了从服务端拷贝到用户；

IPC通信机制：

以下为简单的主进程和子进程通信：

1、服务注册： 缓存中心中有三张表(暂时理解为三个HashMap，Binder用的是native的红黑树)：

类的方法集合：key-value;

key：方法签名：“方法名” 有参数时用 “方法名-参数类型-参数类型-参数类型......”;

value: 方法本身;

注册后，服务若没被调用则一直处于沉默状态，不会占用内存，这种情况只是指用户进程里自己创建的服务，不适用于AMS这种；

2、服务发现： 当被查询到时，要被初始化；

3、服务调用：

AIDL： BpBinder：数据发送角色 BbBinder：数据接收角色

编译器生成的AIDL的java接口.Stub.proxy.transact()为数据发送处；

发送的数据包含：数据+方法code+方法参数等等；

请求头：包含了目的进程、大小等等参数代理检测线程异常，这些参数占了8K

编译器生成的AIDL的java接口.Stub.onTransact()为数据接收处；

Binder中的IPC机制：

ServiceManager维持了Binder这套通信框架；

Framework大全私信：Framework