Android N 进程间通信--Binder

Binder简介

	Binder是Android特有的一种进程间通信（IPC）方式。Android系统的服务都是通过Binder构建的。Binder是整个系统运行的中枢，因此，Android在提高Binder的效率方法下足了功夫。Android在进程间传递数据使用的是共享内存的方式，这样数据只需要复制一次就能从一个进程到达另一个进程，这样数据传输的效率大大提高了。

	在安全性方面Android也做了考虑，Binder调用时会传递调用进程的euid到服务端，因此，服务端可以通过检查调用进程的权限来决定是否允许其使用所调用的服务。

Binder对象定义

	Binder涉及的对象比较多，这里对Binder对象做下定义。

 
 
 

  
Binder实体对象：Binder实体对象就是Binder服务的提供者。一个提供Binder服务的类必须继承BBinder类，因此，有时为了强调对象的类型，也用“BBinder对象”代替“Binder的实体对象”。例如，PackageManagerService.java。
  
Binder引用对象：Binder引用对象是Binder实体对象在客户进程的代表，每个引用对象的类型都是BpBinder类，同样可以用“BpBinder对象”来代替“Binder引用对象”。
  
Binder代理对象：代理对象也成为接口对象，它主要是为客户端的上层应用提供接口服务，从IInterface类派生。它实现了Binder服务的函数接口，当然只是一个转调的空壳。通过代理对象，应用能像使用本地对象引用使用远端的实体对象提供的服务。例如，PackageManager.java。
  
IBinder对象：BBinder和BpBinder类都是从IBinder类中继承而来的。在很多场合，不需要刻意地去区分实体对象和引用对象，这时，可以使用“IBinder对象”统一称呼他们。
 

	Binder代理对象主要和应用程序打交道，将Binder代理对象和引用对象分开的好处是代理对象可以有很多实例，但是，它们包含的是同一个引用对象，这样方便用户层的使用。应用完全可以抛开接口对象直接使用Binder引用对象，但是这样开发的程序兼容性不好。也正是在客户端将引用对象和代理对象分离，Android才能用一套架构来同时为java和native层提供Binder服务。隔离后，Binder底层不需要关心上层的实现细节，只需要和Binder实体对象和引用对象进行交互。

Binder的架构

	Binder通信的参与者由4部分构成。

 
 
 

  
Binder驱动：Binder的核心，实现各种Binder的底层操作。
  
ServiceManager：提供Binder的名称到引用对象的转换服务。
  
服务端：Binder服务的提供者。
  
客户端：Binder服务的使用者。
 

	Binder驱动位于Binder架构的核心，通过文件系统的标准接口，如open()、ioctl()、mmap()等，向用户层提供服务。应用层和Binder驱动之间的数据交换是通过ioctl()接口完成的，这样一次系统调用就能完成用户系统和驱动之间的双向数据交换，提高了传输效率。Binder驱动的主要功能是提供Binder通信的通道，维护Binder对象的引用计数，转换传输中的Binder实体对象和引用对象以及管理数据缓冲区。

	ServiceManager是一个守护进程，它的作用是提供Binder服务的查询功能，返回被查询服务的引用。对于一个Binder服务，通常会有一个惟一的字符串标识，只要它向ServiceManager注册了这个标识，应用就可以通过标识来获得服务的引用对象。ServiceManager是一个单独的进程，实际上也是通过Binder框架来提供服务。

	既然驱动是Binder的核心，为什么不直接把查找引用对象的功能放在驱动中完成呢