Binder机制优点
进程架构:
Android的进程架构:每一个Android进程都是独立的,且都由两部分组成,一部分是用户空间,另一部分是内核空间,如下图:
如此设计的优点:
- 稳定性、安全性高:每一个Android进程都拥有自己独立的虚拟地址空间,一方面可以限制其他进程访问自己的虚拟地址空间;另一方面,当一个进程崩溃时不至于“火烧连营”。
- 便于复用与管理:内核共享有助于系统维护和并发操作、节省空间。
优点有:
- 传输效率高: 传输效率主要影响因素是内存拷贝的次数,拷贝次数越少,传输速率越高;Binder拷贝次数为1
- 可操作性强
- 安全性高:传统Linux IPC的接收方无法获得对方进程可靠的UID/PID,从而无法鉴别对方身份;而Binder机制为每个进程分配了UID/PID且在Binder通信时会根据UID/PID进行有效性检测。
几种数据传输方式比较:
方式 | 拷贝次数 | 操作难度 |
---|---|---|
Binder | 1 | 简单 |
消息队列 | 2 | 简单 |
Socket | 2 | 简单 |
管道 | 2 | 简单 |
共享内存 | 0 | 复杂 |
从Android进程架构角度分析:对于消息队列、Socket和管道来说,数据先从发送方的缓存区拷贝到内核开辟的缓存区中,再从内核缓存区拷贝到接收方的缓存区,一共两次拷贝,如图:
而对于Binder来说,数据从发送方的缓存区拷贝到内核的缓存区,而接收方的缓存区与内核的缓存区是映射到同一块物理地址的,节省了一次数据拷贝的过程,如图:
由于共享内存操作复杂,综合来看,Binder的传输效率是最好的。
Binder框架及原理
Binder框架定义了四个角色:Server,Client,ServiceManager和Binder驱动。
其中Server、Client、ServiceManager运行于用户空间,Binder驱动运行于内核空间。关系如图:
客户端和服务端如何完成连接
- ServiceManager:服务的管理者,将Binder名字转换为Client中对该Binder的引用,使得Client可以通过Binder名字获得Server中Binder实体的引用。流程如图:
- Server服务器端:在服务端创建好了一个Binder对象后,内部就会开启一个线程用于接收Binder驱动发送的消息,收到消息后会执行onTranscat(),并按照参数执行不同的服务端代码。
- Binder驱动:
与硬件设备没有关系,其工作方式与设备驱动程序是一样的,工作于内核态。
提供open()、mmap()、poll()、ioctl()等标准文件操作。在服务端成功Binder对象后,Binder驱动也会创建一个mRemote对象(也是Binder类),客户端可借助它调用transcat()即可向服务端发送消息。 - Client客户端:客户端要想访问Binder的远程服务,就必须获取远程服务的Binder对象在Binder驱动层对应的mRemote引用。当获取到mRemote对象的引用后,就可以调用相应Binder对象的暴露给客户端的方法。
客户端和服务端如何交互(Binder 工作原理)
- 服务器端:在服务端创建好了一个Binder对象后,内部就会开启一个线程用于接收Binder驱动发送的消息,收到消息后会执行onTranscat(),并按照参数执行不同的服务端代码。
- Binder驱动:在服务端成功Binder对象后,Binder驱动也会创建一个mRemote对象(也是Binder类),客户端可借助它调用transcat()即可向服务端发送消息。
- 客户端:客户端要想访问Binder的远程服务,就必须获取远程服务的Binder对象在Binder驱动层对应的mRemote引用。当获取到mRemote对象的引用后,就可以调用相应Binder对象的暴露给客户端的方法。