参考资料：
1、《Android开发艺术探索》第二章2.3.3 Binder
1、 什么是Binder
Binder从不同角度上的定义：
- 直观来说，Binder是Android中的一个类，它实现了IBinder接口；
- 从IPC角度来说，Binder是Android中的一种跨进程通信方式，该通信方式在Linux中没有；
- 从Android Framework角度来说，Binder是ServiceManager连接各种Manager和相应ManagerService的桥梁；
- 从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据了。
Binder机制具体有两层含义：
- Binder是一种跨进程通信（IPC，Inter-Process Communication）的手段；
- Binder是一种远程过程调用（RPC，Remote Procedure Call）的手段。
2、 为什么使用Binder
Android系统是基于Linux系统的，理论上应该使用Linux内置的IPC方式。Linux中的IPC方式有管道、信号量、共享内存、消息队列、Socket，Android使用的Binder机制不属于Linux。Android不继承Linux中原有的IPC方式，而选择使用Binder，说明Binder具有一定的优势。
Android系统为了向应用开发者提供丰富的功能，广泛的使用了Client-Server通信方式，如媒体播放、各种传感器等，Client-Server的通信方式是Android IPC的核心，应用程序只需要作为Client端，与这些Server建立连接，即可使用这些功能服务。
下面通过一些功能点，一一排除Linux系统中五种IPC方式，解释为什么Android选择使用Binder：
- 从通信方式上说，我们希望得到的是一种Client-Server的通信方式，但在Linux的五种IPC机制中，只有Socket支持这种通信方式。虽然我们可以通过在另外四种方式的基础上架设一些协议来实现Client-Server通信，但这样增加了系统的复杂性，在手机这种条件复杂、资源稀缺的环境下，也难以保证可靠性；
- 从传输性能上说，Socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信；消息队列和管道采用存储-转发方式，即数据先从发送方拷贝到内存开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程；共享内存虽然无需拷贝，但控制复杂，难以使用；而Binder只需要拷贝一次；
- 从安全性上说，Android作为一个开放式的平台，应用程序的来源广泛，因此确保只能终端的安全是非常重要的。Linux传统的IPC没有任何安全措施，完全依赖上层协议来确保，具体有以下两点表现：第一，传统IPC的接收方无法获得对方可靠的UID/PID（用户ID/进程ID），从而无法鉴别对方身份，使用传统IPC时只能由用户在数据包里填入UID/PID，但这样不可靠，容易被恶意程序利用；第二，传统IPC的访问接入点是开放的，无法建立私有通信，只要知道这些接入点的程序都可以和对端建立连接，这样无法阻止恶意程序通过猜测接收方的地址获得连接。
基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式、传输性能和安全性的要求，这就是Binder。
综上，Binder是一种基于Client-Server通信模式的通信方式，传输过程只需要一次拷贝，可以为发送方添加UID/PID身份，支持实名Binder和匿名Binder，安全性高。
3、 Binder的组成
Binder由四部分组成：Binder客户端、Binder服务端、Binder驱动、服务登记查询模块。
- Binder客户端：
Binder客户端是想要使用服务的进程。
- Binder服务端：
Binder服务端是实际提供服务的进程。
- Binder驱动：
我们在客户端先通过Binder拿到一个服务端进程中的一个对象的引用，通过这个引用，直接调用对象的方法获取结果。在这个引用对象执行方法时，它是先将方法调用的请求传给Binder驱动；然后Binder驱动再将请求传给服务端进程；服务端进程收到请求后，调用服务端“真正”的对象来执行所调用的方法；得出结果后，将结果发给Binder驱动；Binder驱动再将结果发给我们的客户端；最终，我们在客户端进程的调用就有了返回值。Binder驱动，相当于一个中转者的角色。通过这个中转者的帮忙，我们就可以调用其它进程中的对象。
- Service Manager（服务登记查询模块）：
我们调用其它进程里面的对象时，首先要获取这个对象。这个对象其实代表了另外一个进程能给我们提供什么样的服务（再直接一点，就是：对象中有哪些方法可以让客户端进程调用）。首先服务端进程要在某个地方注册登记一下，告诉系统我有个对象可以公开给其它进程来提供服务。当客户端进程需要这个服务时，就去这个登记的地方通过查询来找到这个对象。
4、 Binder机制简述
上面说到，Binder有两个含义，分别是进程间通信和远程过程调用。Android的整个跨进成机制都是基于Binder的，这种机制不但会在底层调用，也会在上层调用，所以必须提供C++和Java两个层次的支持。下面是两种情况下Binder的原理图。
进程间通信的Binder原理图
上图是进程间通信时的Binder原理图。图中进程A中的小圆圈代表“Binder代理方”BpBinder，用于向远方发送语义；进程B中的方块代表“Binder响应方”BBinder，主要用于响应语义。
远程过程调用的Binder原理图
上图是远程过程调用时的Binder原理图。此时，进程A不再直接和Binder代理BpBinder打交道，而是通过聚合了BpBinder的“接口代理”BpInterface的成员函数来完成远程调用；而进程B则通过Binder响应方BBinder的继承类“接口实现体”BnInterface来响应进程A发来的请求。如此依赖，在远程过程调用的操作中，客户端需要完成Binder代理和接口代理，而服务端需要完成接口实现体。
需要说明的是，上面两图中的BpBinder、BpInterface、BBinder和BnInterface都是C++中的层次概念，Java中没有这些。
这里只针对Java中的Binder层次进行解释，不涉及C++的代码。
5、 Binder工作流程
假设：客户端的程序Client运行在进程A中，服务端的程序Server运行在进程B中。
由于进程的隔离性，Client不能读写Server中的内容，但内核可以，而Binder驱动就是运行在内核态，因此Binder驱动帮我们进行请求的中转。
有了Binder驱动，Client和Server之间就可以打交道了，但是为了实现功能的单一性，我们为Client和Server分别设置一个代理：Client的代理Proxy和Server的代理Stub。这样，由进程A中的Proxy和进程B中的Stub通过Binder驱动进行数据交流，Server和Client直接调用Stub和Proxy的接口返回数据即可。
此时，Client直接调用Proxy这个聚合了Binder的类，我们可以使用一系列的Manager来屏蔽掉Binder的实现细节，Client直接调用Manager中的方法获取数据，这样做的好处是Client不需要知道Binder具体怎么工作。
最后还有一个问题，就是Client想要获得的服务多种多样，那么它是怎么获取Proxy或Manager的呢？答案是通过Service Manager进程来获取的。Service Manager总是第一个启动的服务，其他服务端进程启动后，可以在Service Manager中注册，这样Client就可以通过Service Manager来获取服务器的服务列表，进而选择具体调用的服务器进程方法。
上面的叙述总结为如下图所示的工作流程图：
6、 Binder示例代码
在Android开发中，Binder主要用在Service中，其中普通的Service中的Binder不涉及进程间通信，所以较为简单，而AIDL和基于AIDL的Messenger涉及到进程间通信，因此，这里选择使用AIDL来分析Binder的工作机制。
在这个例子中，我们将通过AIDL的方式将一个Book实体类的对象从服务端传递到客户端进行展示。
先创建一个Book实体类，为了能在进程间传递，需要序列化Book，代码如下：
public class Book implements Parcelable {
private int bookId;
private String bookName;
public Book(int bookId, String bookName) {
this.bookId = bookId;
this.bookName = bookName;
}
protected Book(Parcel in) {
bookId = in.readInt();
bookName = in.readString();
}
public static final Creator<Book> CREATOR = new Creator<Book>() {
@Override
public Book createFromParcel(Parcel in) {
return new Book(in);
}
@Override
public Book[] newArray(int size) {
return new Book[size];
}
};
@Override
public int describeContents() {
return 0;
}
@Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(bookId);
dest.writeString(bookName);
}
}创建一个Book.aidl文件，代码如下：
package my.itgungnir.ipc.binder; parcelable Book;
创建一个IBookManager.aidl文件，代码如下：
package my.itgungnir.ipc.binder;
import my.itgungnir.ipc.binder.Book; // 虽然这个文件和Book.aidl文件在同一个包下，但还是要导入类，这就是AIDL的特点
interface IBookManager {
Book getBook();
}创建了这三个文件之后，运行一遍项目，这时会在项目的build/generated/source/aidl/debug/包名目录下生成一个IBookManager.java的文件，这个类是系统根据我们编写的IBookManager.aidl文件自动生成的Binder类。这个类的代码如下：
package my.itgungnir.ipc.binder;
public interface IBookManager extends android.os.IInterface {
/**
* Local-side IPC implementation stub class.
*/
public static abstract class Stub extends android.os.Binder implements my.itgungnir.ipc.binder.IBookManager {
private static final java.lang.String DESCRIPTOR = "my.itgungnir.ipc.binder.IBookManager";
/**
* Construct the stub at attach it to the interface.
*/
public Stub() {
this.attachInterface(this, DESCRIPTOR);
}
/**
* Cast an IBinder object into an my.itgungnir.ipc.binder.IBookManager interface,
* generating a proxy if needed.
*/
public static my.itgungnir.ipc.binder.IBookManager asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof my.itgungnir.ipc.binder.IBookManager))) {
return ((my.itgungnir.ipc.binder.IBookManager) iin);
}
return new my.itgungnir.ipc.binder.IBookManager.Stub.Proxy(obj);
}
@Override
public android.os.IBinder asBinder() {
return this;
}
@Override
public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
switch (code) {
case INTERFACE_TRANSACTION: {
reply.writeString(DESCRIPTOR);
return true;
}
case TRANSACTION_getBook: {
data.enforceInterface(DESCRIPTOR);
my.itgungnir.ipc.binder.Book _result = this.getBook();
reply.writeNoException();
if ((_result != null)) {
reply.writeInt(1);
_result.writeToParcel(reply, android.os.Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
} else {
reply.writeInt(0);
}
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements my.itgungnir.ipc.binder.IBookManager {
private android.os.IBinder mRemote;
Proxy(android.os.IBinder remote) {
mRemote = remote;
}
@Override
public android.os.IBinder asBinder() {
return mRemote;
}
public java.lang.String getInterfaceDescriptor() {
return DESCRIPTOR;
}
@Override
public my.itgungnir.ipc.binder.Book getBook() throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
my.itgungnir.ipc.binder.Book _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(Stub.TRANSACTION_getBook, _data, _reply, 0);
_reply.readException();
if ((0 != _reply.readInt())) {
_result = my.itgungnir.ipc.binder.Book.CREATOR.createFromParcel(_reply);
} else {
_result = null;
}
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
}
static final int TRANSACTION_getBook = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
}
public my.itgungnir.ipc.binder.Book getBook() throws android.os.RemoteException;
}这个类中的结构如下图所示：
下面来逐一解释这个类中的每个元素代表的含义：
- 最外层的getBook()：一个抽象方法，就是我们在IBookManager.aidl文件中声明的方法；
- TRANSACTION_getBook：一个整形的ID，用于表示客户端请求的是哪个方法；
- DESCRIPTOR：Binder的唯一标识，一般用当前Binder的包路径表示；
- asInterface()：判断当前进程是服务端进程还是客户端进程，如果是服务端进程则返回Stub对象，否则返回Stub.Proxy对象；
- asBinder()：返回当前的Binder对象；
- onTransact(int code, Parcel data, Parcel reply, int flag)：这个方法运行在服务端的Binder线程池中，当客户端发起请求时，就由这个方法来处理请求。服务端通过code获取客户端想要访问的目标方法；通过data来获取目标方法所需的参数；执行完目标方法后，将返回值写入到reply中。另外，如果这个方法返回false，则客户端请求失败，我们可以通过这一点来判断客户端是否有权访问我们的服务；
- Proxy#getBook()：这个方法运行在客户端，其内部实现是这样的：首先创建三个对象，_data用来存储这个方法的参数信息；_reply用来存储从服务端返回的数据；_result用来作为返回值返回，然后调用transact()方法发起RPC（远程过程调用）请求，调用服务端的onTransact()方法，同时当前线程挂起；当RPC过程返回后，当前线程继续执行，经过一系列处理后返回_result结果。
使用Binder还需要注意：
当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以如果一个远程方法是耗时的，那么不能放到UI线程中。