首页 站长快讯正文

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

admin 站长快讯 2022-11-18 18:08:00 1116 0

前言

在说Handler和binder之前代理检测线程异常,我们先看看关于Framework都有什么内容

seh 线程 异常_代理检测线程异常_子线程异常 进程退出

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

代理检测线程异常_seh 线程 异常_子线程异常 进程退出

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

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

ThreadLocalMap:类似于HashMap;

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

代理检测线程异常_seh 线程 异常_子线程异常 进程退出

在Looper.prepare()时,存入Looper,存Looper时ThreadLocalMap的key为ThreadLocal,value为Looper;

子线程异常 进程退出_seh 线程 异常_代理检测线程异常

seh 线程 异常_子线程异常 进程退出_代理检测线程异常

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

handler.obtainMessage();

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

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

子线程异常 进程退出_代理检测线程异常_seh 线程 异常

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

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

子线程异常 进程退出_seh 线程 异常_代理检测线程异常

image.png

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

子线程异常 进程退出_代理检测线程异常_seh 线程 异常

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

代理检测线程异常_seh 线程 异常_子线程异常 进程退出

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

Looper的死循环为什么不会让主线程卡死(或ANR)? 简单版:

详细:

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

子线程Looper是可以退出的,主线程不行;

Framework大全私信:Framework

二丶Binder

进程隔离:

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

为什么要用Binder?

代理检测线程异常_子线程异常 进程退出_seh 线程 异常

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

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

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

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

MMU:内存管理单元;

给CPU提供虚拟地址;

当对变量操作赋值时:

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

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

子线程异常 进程退出_seh 线程 异常_代理检测线程异常

seh 线程 异常_代理检测线程异常_子线程异常 进程退出

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

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

普通的二次拷贝:

应用A拷贝到服务端:coay_from_user

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

mmap():

共享内存进程通信:

Binder通信原理:

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

seh 线程 异常_子线程异常 进程退出_代理检测线程异常

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

代理检测线程异常_子线程异常 进程退出_seh 线程 异常

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

发送的数据包含:数据+方法code+方法参数等等;

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

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

Binder中的IPC机制:

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

Framework大全私信:Framework

打赏
handlerbinder线程
版权声明

本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。

发表评论

评论列表(0人评论 , 1116人围观)
☹还没有评论,来说两句吧...