Android Binder面试详解

一、Linux内核的基础知识

1、进程隔离/虚拟地址空间

2、系统调用

3、Linux跨进程通信机制

目前linux支持的IPC包括传统的管道、System V IPC、即消息队列/共享内存/信号量，以及socket中只有socket支持Client-Server的通信方式

1.管道（Pipe）及有名管道（named pipe）

2.信号（Signal）

3.报文（Message）队列（消息队列）

4.共享内存

5.信号量（semaphore）

6.套接字（Socket）

二、Binder通信机制

1、为什么使用binder

在上面这些可供选择的方式中，Android使用得最多也最被认可的还是Binder机制。

因为Binder更加简洁和快速，消耗的内存资源更小吗？不错，这些也正是Binder的优点。

当然，也还有很多其他原因，比如传统的进程间通信可能会增加进程的开销，而且有进程过载和安全漏洞等方面的风险，Binder正好能解决和避免这些问题。

Binder主要能提供以下一些功能：

用驱动程序来推进进程间的通信。

通过共享内存来提高性能。

为进程请求分配每个进程的线程池。

针对系统中的对象引入了引用计数和跨进程的对象引用映射。

进程间同步调用。

使用Binder跨进程通讯主要有一下两个方面

一、性能方面

跨进程通讯中，只有socket支持Client-Server的通信方式，但是socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程。共享内存虽然无需拷贝，但控制复杂，难以使用。

Android Binder机制原理（史上最强理解，没有之一）

二、安全性能方面

首先传统IPC的接收方无法获得对方进程可靠的UID和PID（用户ID进程ID），从而无法鉴别对方身份。Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID和PID，但这样不可靠，容易被恶意程序利用。可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。比如命名管道的名称，systemV的键值，socket的ip地址或文件名都是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法阻止恶意程序通过猜测接收方地址获得连接。

基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式，传输性能和安全性的要求，这就是Binder。

Binder基于Client-Server通信模式，传输过程只需一次拷贝，为发送发添加UID/PID身份，既支持实名Binder也支持匿名Binder，安全性高。

详情参考链接：为什么是binder

2、什么是binder

3、binder通信模型

Binder的通信模型有4个角色：Binder Client、Binder Server、Binder Driver（Binder驱动）、ServiceManager。

可以看到，ServiceManager、Binder Client、Binder Server处于不同的进程，他们三个都在用户空间，而Binder驱动在内核空间。（我是特意把Binder驱动画的比较大的，因为Binder驱动的作用最大）

那先来简述一下这个通信模型：

首先是有一个ServiceManager，刚开始这个通讯录是空白的，然后Server进程向ServiceManager注册一个映射关系表，之后Client进程想要和Server进程通信，首先向ServiceManager查询地址，ServiceManager收到查询的请求之后，返回查询结果给Client。

注意到这里不管是Server进程注册，还是Client查询，都是经过Binder驱动的，这也真是Binder驱动的作用所在，

4、bind通信机制原理

1． Server进程向ServiceManager注册，告诉ServiceManager我是谁，我有什么，我能做什么。就好比徐同学（Server进程）有一台笔记本（computer对象），这台笔记本有个add方法。这时映射关系表就生成了。

2． Client进程向ServiceManager查询，我要调用Server进程的computer对象的add方法，可以看到这个过程经过Binder驱动，这时候Binder驱动就开始发挥他的作用了。当向ServiceManager查询完毕，是返回一个computer对象给Client进程吗？其实不然，Binder驱动将computer对象转换成了computerProxy对象，并转发给了Client进程，因此，Client进程拿到的并不是真实的computer对象，而是一个代理对象，即computerProxy对象。很容易理解这个computerProxy对象也是有add方法，（如果连add方法都没有，岂不是欺骗了Client？），但是这个add方法只是对参数进行一些包装而已。

3． 当Client进程调用add方法，这个消息发送给Binder驱动，这时驱动发现，原来是computerProxy，那么Client进程应该是需要调用computer对象的add方法的，这时驱动通知Server进程，调用你的computer对象的add方法，将结果给我。然后Server进程就将计算结果发送给驱动，驱动再转发给Client进程，这时Client进程还蒙在了鼓里，他以为自己调用的是真实的computer对象的add方法，其实他只是调用了代理而已。不过Client最终还是拿到了计算结果。

好了，一个通信过程就完成了。我们发现，其实Binder驱动就是一个中转。