Android——Binder

该文章的知识点基本上来自于这个连接，然后融入了自己的一些理解：http://gityuan.com/2015/10/31/binder-prepare/

1. 背景知识

Android的四层结构中，最底层是linux的kenel层，也就是说Android实际上还是基于linux来进行实现的，基本的实现代码是C语言，而C语言是一个面向结构的语言，而非是面向对象的语言

那么，linux中有很多的IPC通信机制，来进行进程间的通信，为何android还要创建自己的进程间通信机制Binder哪？ 接下来，先看下linux下不同的通信机制

linux下的进程通信手段基本上都是从Unix平台上继承而来的，最初的Unix IPC有

管道及有名管道：管道在创建的时候会分配一个page大小的内存，其缓存区大小比较有限，而且管道在数据拷贝时需要进行两次拷贝

消息队列：一个FIFO的消息队列，同样需要进行两次数据拷贝，而且由于需要维护这个消息队列，因此是需要额外的CPU消耗的，并不适合与信息量很大的通信

信号：信号本质上是通知某个进程某个事情发生了，从而某个进程知道自己下一步需要干些什么，进程也可以自己给自己发信号进行控制。所以信号更加适合与进程的中断控制等等，而不是用来进行信息的交换

信号量：更多地是作为一种锁的机制，保证了进程之间以及线程之间的数据同步问题。

套接口：更为一般的进程间通信机制，主要是用于不同的操作系统，不同的设备，不同的网络之间的进程间通信。最初由Unix系统的BSD分支开发，后来被广泛应用与其他系统之上。但是由于其更加通用，因此传输效率是比较低的，而且同样需要拷贝两次数据

共享内存：多个进程可以访问同一个内存空间，是所有IPC中效率最高的进程间通信，而且根本不需要任何的数据拷贝，是直接共享的。

 

2. Binder的出现

综上，信号和信号量基本上被排除了，不适合与用来进行Android四大组件之间的信息传递，接下来就剩其他三个了

（1） 语言上，linux的IPC都是使用C语言来实现的，而整个Android的framework层以及application层都是使用java来实现的。

（2） 从协议上来讲，Android的创造者并不像开源他的代码，这也是自身的商业性质决定的。而linux的主线是开源的。

上面这两个可能是Binder出现的最本质原因，而下面是从开发者角度来看

（3） 性能上，binder只需要一次数据拷贝，而管道 ，套接口，消息队列都需要两次数据拷贝。

（4） 共享内存虽然不需要进行数据拷贝。但从稳定性上来讲，采用C/S的bander比共享内存更加稳定。

（5） 安全上，linux的IPC无法获取对方进程可靠的UID/PID，而Android给应用分配了自己的UID，而且C/S模式保证了Android系统对外只暴露client，而保护了server端。

 

3. BBinder，BpBinder，IBinder

BBinder：对于serveice来说，都是继承了BBinder（BnInterface）。BBinder.onTransact()接收相应的事务请求

BpBinder：对与client来说，都是继承了BpBinder（BpInterface）。BpBinder.transact()分发事务请求

IBinder：相当于一个指针，就像socket的ID一样，IBinder是一个进程的唯一标识，是重构上述两个Binder时作为参数传入的。BBinder和BpBinder都是继承于IBinder的

 

4. Binder的架构

图片同样来自于：http://gityuan.com/2015/10/31/binder-prepare/

（1） Service Manager相当于一个管理者，指的是Native曾的ServiceManager（C++），是Binder的守护进程

（2） Client和Server的通信需要先获取Service Manager接口，然后才能开始进行通信

 

 

源码分析之后会慢慢补上。。。