Android为什么选择binder

　　Android为什么选择binder

Binder (Android技术内幕)：

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

为什么会选择Binder来作为进程之间的通信机制呢？因为Binder更加简洁和快速，消耗的内存资源更小吗？

不错，这些也正是Binder的优点。

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

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

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

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

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

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

　　进程间同步调用。

 

Android Binder设计与实现 – 设计篇：

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

当然也可以在这些底层机制上架设一套协议来实现Client-Server通信，但这样增加了系统的复杂性，在手机这种条件复杂，资源稀缺的环境下可靠性也难以保证。

另一方面是传输性能:

　　socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。

消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，

至少有两次拷贝过程。共享内存虽然无需拷贝，但控制复杂，难以使用。

表 1 各种IPC方式数据拷贝次数

IPC	数据拷贝次数
共享内存	0
Binder	1
Socket/管道/消息队列	2

 

还有一点是出于安全性考虑:

　　Android作为一个开放式，拥有众多开发者的平台，应用程序的来源广泛，确保智能终端的安全是非常重要的。

终端用户不希望从网上下载的程序在不知情的情况下偷窥隐私数据，连接无线网络，长期操作底层设备导致电池很快耗尽等等。传统IPC没有任何

安全措施，完全依赖上层协议来确保。首先传统IPC的接收方无法获得对方进程可靠的UID/PID（用户ID/进程ID），从而无法鉴别对方身份。

　　Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID/PID，

但这样不可靠，容易被恶意程序利用。可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。

比如命名管道的名称、system V的键值、socket的ip地址或文件名都是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法

阻止恶意程序通过猜测接收方地址获得连接。

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

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

面向对象的 Binder IPC：

 　　面向对象思想的引入将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法，而其独特之处在于Binder对象是一个

可以跨进程引用的对象，它的实体位于一个进程中，而它的引用却遍布于系统的各个进程之中。最诱人的是，这个引用和java里引用

一样既可以是强类型，也可以是弱类型，而且可以从一个进程传给其它进程，让大家都能访问同一Server，就像将一个对象或引用赋

值给另一个引用一样。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。

　　面向对象只是针对应用程序而言，对于Binder驱动和内核其它模块一样使用C语言实现，没有类和对象的概念。

Binder驱动为面向对象的进程间通信提供底层支持。

来自：http://wenku.baidu.com/view/4186490690c69ec3d5bb753a.html