Android-Binder基本原理

最新推荐文章于 2024-05-08 06:23:15 发布

A-sL1

最新推荐文章于 2024-05-08 06:23:15 发布

阅读量876

点赞数 18

分类专栏： # 知识体系文章标签： binder android

本文链接：https://blog.csdn.net/lzz214/article/details/135066534

版权

知识体系专栏收录该内容

9 篇文章 1 订阅

订阅专栏

一、进程角度看IPC机制

在Android系统中，每个进程只能运行在自己所拥有的虚拟地址空间。例如，一个4GB的虚拟地址空间，包含3GB的用户空间和1GB的内核空间，内核空间的大小可以通过参数配置进行调整。两个进程之间的用户空间是彼此独立的，但内核空间是可共享的。Server 进程与 Client 进程之间就是利用共享的内核空间进行通信的，Server 端与 Client 端主要使用 ioctl 等方法跟内核空间的驱动进行交互。

二、Binder原理

2.1 使用Binder的优点

在传统的Linux中存在多种IPC的方式，例如SystemV、管道、Socket等。但是Android系统没有大量采用原有的技术方式，而是开发了 Binder 并在系统中大量使用。主要原因有如下几点：

1.性能方面

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

2.安全方面

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

3.是否易用

Binder使用面向对象的设计，基于C/S架构，进行一次远程调用和直接调用本地调用一样，使用方便。并且Binder驱动通过引用计数法实现了管理跨进程传递的代理对象的生命周期。

基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式，传输性能和安全性的要求，这就是Binder。Binder基于Client-Server通信模式，传输过程只需一次拷贝，为发送方添加UID/PID身份，既支持实名Binder也支持匿名Binder，安全性高。

2.2 Binder架构

Binder采用 C/S 架构，其中的角色主要包括Client、Server、ServiceManager和Binder驱动。

Client进程：使用服务的进程。
Server进程：提供服务的进程。
ServiceManager进程：ServiceManager的作用是将字符形式的Binder名字转化成Client中对该Binder的引用，使得Client能够通过Binder名字获得对Server中Binder实体的引用。
Binder驱动：驱动负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间的传递和交互等一系列底层支持。

系统首次启动 ServiceManager 后，当 Client 和 Server 通信时都需要先获取 ServiceManager 接口。因此无论是注册服务还是获取服务，都需要 ServiceManager，需要主要的是此处的 ServiceManager 是指 Native 层的 ServiceManager（C++）。

1.注册服务：Server 进程要先注册 Service 到 ServiceManager。该过程，Server是客户端，ServiceManager 是服务端。

2.获取服务：Client 进程使用某个 Service 前，需要先向 ServiceManager 中获取相应的 Service。该过程，Client 是客户端，ServiceManager 是服务端。

3.使用服务：Client 根据获得的 Service 信息建立与 Service 所在的 Server 进程通信的通路，之后就可以与 Service 交互了。该过程：Client 是客户端，Server 是服务端。

2.3 Binder的工作流程

Server 进程向 ServiceManager 注册，告诉 ServiceManager 我是谁，我有什么，我能做什么。假如 Server 进程有一个 computer 对象，这个对象有个add方法。这时映射关系表就生成了。
Client 进程向 ServiceManager 查询，我要调用 Server 进程的 computer 对象的 add 方法，这时候 Binder 驱动就开始发挥他的作用了。当向 ServiceManager 查询完毕，Binder 驱动将 computer 对象转换成了 computerProxy 对象，并转发给了 Client 进程，因此，Client 进程拿到的并不是真实的 computer 对象，而是一个代理对象，即 computerProxy 对象。很容易理解这个 computerProxy 对象也是有 add 方法。
当 Client 进程调用 add 方法，这个消息发送给 Binder 驱动，这时驱动发现，原来是computerProxy，那么 Client 进程应该是需要调用 computer 对象的 add 方法的，这时驱动通知 Server 进程，调用你的 computer 对象的 add 方法，将结果给我。然后 Server 进程就将计算结果发送给驱动，驱动再转发给 Client 进程，最终 Client 进程拿到了计算结果。

2.4 Binder的线程管理

每个 Binder 的 Server 进程会创建很多线程来处理 Binder 请求，而真正管理这些线程并不是由这个 Server 端来管理的，而是由 Binder 驱动进行管理的。
一个进程的 Binder 线程数默认最大是 16，超过的请求会被阻塞等待空闲的 Binder 线程。理解这一点的话，你做进程间通信时处理并发问题就会有一个底，比如使用 ContentProvider 时（又一个使用 Binder 机制的组件），你就很清楚它的CRUD（创建、检索、更新和删除）方法只能同时有 16 个线程在跑。