android binder机制

1.简述

    binder 是android 进程间通信的一种机制，驱动在kernel层 /dev/binder native层管理service_manager jni层 android_util_binder

framwork层 分为binderProxy 代理 和 binder 服务

binder 采用c/s 架构，从组件来说 包括 client server serviceManager 以及驱动

ioctl是设备驱动程序中对设备的I/O通道进行管理的函数。Client 进程和Server端进程往往采用ioctl 等方法和内核空间的驱动进行交互。

2.binder原理

android空间分为 平台层和应用层 也叫做内核空间和用户空间，内核空间就是binder 驱动设备，用户空间包client server servie manager ,client 从service manager 获取服务， service manager 向 server注册服务，三个同内核空间通过ioctl 方式通信

client进程：使用服务的进程；

Server进程：提供服务的进程；

serviceManager进程：将字符形式的binder名字转化成Client中对该binder的引用，使得Client能够通过Binder名字获得对Server中binder实体的引用

Binder驱动：驱动负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间的传递和交互等一系列的底层支持。

注册服务：Server进程要先注册Service到ServiceManager。

获取服务 client进程使用某个Service 前先向ServiceManager中获取相应的Service

三。具体过程

1.client 通过获得一个Server的代理接口 对server进行调用

2.代理接口中定义的方法与server 中定义的方法一一对应

3.client调用某个代理接口中的方法时。代理接口的方法会将client 传递的参数打包成parcel 对象

4.代理接口将parcel 发送给内核中的 binder driver.

5.server会读取binder driver 中的请求参数，如果是发送给自己的，就解包parcel 对象，处理并返回结果

6.整个的调用过程是一个同步过程，在server处理的时候，client 会被lock 住，因此 client 调用过程不应在主线程。

四。android 与linux 通信机制的比较

采用 c/s 的通信模式。在linux 通信机制中，目前只有socket 支持c/s 通信模式。但是socket 是一个通用接口，导致传输效率低，开销大，相对安全性地，只生命一个地址。

管道和消息队列：因为采用存储转发的方式，所以至少需要拷贝两次数据，效率低；

共享内存：虽然在传输时没有拷贝数据，但其控制机制复杂

linux 的ipc 机制在本身的实现中，并没有安全措施，得依赖上层协议来进行安全控制。而Binder机制 的uid pid 是由binder 机制本身在内核空间中添加身份标识，安全性高，并且binder 可以建立似有通道，

五/ 在service 中的作用

Server 作为众多service的拥有者，当他向client 提供服务的时候，先去service manager 注册自己的服务，

client 作为使用者，当他想使用的时候，向service manager 申请，他们之间通过binder通信

六过程

注册

server  (create) binder instance + binder name (through binder driver send) service manager (get out name and quote) query table

首先，XServer 在自己的进程中向binder 驱动申请创建一个 XService的binder 实体，binder驱动为这个XService 创建位于内核中的binder实体节点以及binder 的引用，是将名字和新建的引用打包传递给service manager ,通知 service manager 注册一个名叫X 的service

sm 收到数据包后，从中取X Service 的名字和引用 填入一张表中，

此时，如果client 向sm 发出申请x服务的请求，那么就可以查到表中该 service 的binder 引用，并把binder 引用返回给client

获取sm 的远程接口

process rigster sm cerate binder instance

sercer 向servicemanager 注册了binder 实体和名字后，client 也利用保留的 handle 直为0 的引用向servicemanager 请求访问这个service 的引用 。servicemanager 就会从请求的数据包中获取这个名字，再在表中查找到该名字对应的条目，取出binder的引用打包回复给 client

建立cs 通路后的流程

发送方会通过binder实体请求发送操作。binder驱动会处理这个请求 吧发送方的数据写入缓存 binder_write_read.write_buffer 并把read_size 置为数据大小

接收方之前一直在阻塞状态中，当写缓存中有数据，则会读取数据，执行命令操作；接收方执行完后，会把返回结果同样用 binder_transaction_data 结构体封装，写入写缓存区

转自 https://www.2cto.com/kf/201606/515548.html