1.简单介绍下binder
binder是一种进程间通讯的机制
进程间通讯需要了解用户空间和内核空间
每个进程拥有自己的独立虚拟机，系统为他们分配的地址空间都是互相隔离的。 如两个进程需要进行通讯，则需要使用到内核空间做载体，内核空间是所有进程共享的一块内存区域。 而用户空间切到内核空间需要使用到系统api ioctl进行通讯。内核获取用户的数据需要使用copy_from_user，内核将数据发送给其他进程需要使用copy_to_user，这两个方法是有性能开销的，对于socket就是使用的这种模式，为了减少这部分的开销，内核提供了binder，binder只需要一次拷贝就可以实现进程通讯.
主要是使用mmap的原理：
在内核空间和用户空间都开辟一块虚拟内存区域同时指向一块物理地址，这样内核需要传递数据给用户空间时，只需要将数据拷贝到对应的虚拟内存地址中，用户可以通过虚拟内存映射关系，获取到内核中的数据，实现了一次拷贝通讯。
binder架构上面使用的是c/s架构：
binder中有三要素：客户端，服务端和servicemanager
binder整体过程：
1.注册服务 2.获取服务 3.使用服务
2.binder的定向制导，如何找到目标binder，唤起进程或者线程?
数据结构流程：
1.server注册过程
1.server传入一个flat_binder_object给内核态。内核根据这个flat_binder_object创建binder_node节点，为每个进程服务，内部有个binder_proc.proc = server进程
2.servicemanager在内核态创建binder_ref引用这个binder_node，内部有一项desc = 1,2,3..，在用户态会创建一个服务链表{name ="server name",handle = "server handle"}
2.client获取服务过程
3.client向sm查询服务，传递name
4.sm返回handle给驱动程序
5.驱动程序在sm的binder_ref_desc红黑树中根据handle找到binder_ref，再根据binder_ref.node找到binder_node,最后给client创建新的binder_ref指向这个binder_node，他的desc从1开始binder_ref{desc=1,node = binder_node},驱动返回desc给client，即handle总结：sm中的handle顺序是根据服务注册顺序显示，返回给client中的handle是根据服务获取的顺序显示的
3.client使用handle过程
6.：驱动里面根据handle找到找到binder_ref，根据binder_ref找到binder_node，根据binder_node找到进程server
注：
flat_binder_object{
type:是binder实体还是引用，只有需要注册的服务可以传binder实体，其他只能传handle引用
flag(联合体)
binder(实体：处理函数)/handle(引用：服务的引用)：
cookie
}
数据传输过程(进程切换)：
数据如何复制：
3.binder中的红黑树，为什么会有两棵binder_ref红黑树
refs_by_desc主要是通过desc来查找对应的binder_refrefs_by_node主要是通过node来查找对应的binder_ref
查找方式不一样
4.binder一次拷贝原理
传统的数据拷贝方式如socket：
用户空间---->内核空间：`copy_from_user ` 内核空间---->用户空间：`copy_to_user`
而binder使用mmap机制
在内核空间和用户空间中间使用物理地址开辟了一个映射关系 内核空间调用copy_from_user会直接将数据拷贝到内核空间并反馈到映射后的物理地址上， 由于用户空间和物理地址也有个映射关系，用户空间可以直接通过映射的虚拟地址指针访问到写入物理地址的数据。 这就是binder一次拷贝的原理
5.binder传输数据的大小限制?
对于内核可以传输的是4m，但是应用层限制在1m-8k范围内，这就是在进程间传输过大的数据会导致崩溃的原因
6.系统服务与bindservice等启动的服务的区别
系统服务需要将服务注册到servicemanager，使用的时候需要通过服务名称去servicemanger中获取服务的引用，
而bindservice等启动的服务是将服务注册到ams中的servicemap中，所有的服务的生命周期都由ams控制。启动服务的进程如果需要使用ipc通讯，都是和获取ams的代理类进行通讯，ams也是在systemserver启动的时候一个注册到servicemanager的系统服务。
7.binder多线程
binder线程池默认提供了15个线程进行处理进程间并发事件，如果服务端线程不够用，则驱动会发出一个信号，应用层收到这个信号调用register_thread，这样驱动层就可以使用这个新建出来的子线程进行数据的处理
8.android app进程天生支持binder通信的原理是什么?
android app进程都是由zygote进程孵化出来的。
常见场景：
点击桌面icon启动app，或者startactivity启动一个新进程里面的activity，最终都会由ams去调用process.start()方法去向zygote进程发送请求，让zygote去fork一个新进程，zygote收到请求后会调用zygote.forkandspecialize()来fork出新进程,之后会通过runtimeinit.nativezygoteinit来初始化andriod app运行需要的一些环境，而binder线程就是在这个时候新建启动的
virtual void onzygoteinit()
{
sp proc = processstate::self();
//启动新binder线程loop
proc->startthreadpool();
}
9.同一个线程的请求必定是顺序执行，即使是异步请求(oneway)
一般而言，client同步阻塞请求service，直到service提供完服务后才返回，不过，也有特殊的，比如请求用one_way方式，这种场景一般主要是用来通知，至于通知被谁消费，是否被消费压根不会关心。 拿contentservice服务为例子，它是一个全局的通知中心，负责转发通知，而且，一般是群发，由于在转发的时候，contentservice被看做client，如果这个时候采用普通的同步阻塞势必会造成通知的延时发送送，所以这里的client采用了oneway，异步。
到此这篇关于android中关于binder常见面试问题小结的文章就介绍到这了,更多相关android binder面试内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！