本文为个人学习笔记分享，没有任何商业化行为，对其他文章的引用都会标记。如有侵权行为，请及时提醒更正！如需转载请表明出处
本文主要来源是 任玉刚大神的《Android开发艺术探索》
Binder是android中的一个类，它实现了IBinder接口。从IPC角度来说，Binder是Android的一种跨进程通信方式，Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder，该通信方式在Linux上没有；从Android Framework角度来说，Binder是ServiceManager连接各种Message(ActivityMessage、WindowManager,等等)和相应ManagerService的桥梁；从Android应用层的角度来说，Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通的服务和基于AIDL的服务。
Android开发中，Binder主要用在Service中，包括AIDL和Messenger，其中普通的Service中的Binder不涉及进车间通信，所以比较简单，无法触及Binder核心，而Messenger的底层其实是AIDL，所以这里选择用AIDL来分析Binder的工作机制。为了分析Binder的工作机制，我们需要新建一个AIDL示例，SDK会自动为我们生产AIDL所对应的Binder类型，然后我们就分析Binder的工作过程。
//Book.java
public class Book implements Parcelable {
private int bookId;
private String bookName;
public Book(int bookId, String bookName) {
this.bookId = bookId;
this.bookName = bookName;
}
private Book(Parcel in) {
bookId = in.readInt();
bookName = in.readString();
}
@Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(bookId);
dest.writeString(bookName);
}
@Override
public int describeContents() {
return 0;
}
public static final Creator CREATOR = new Creator() {
@Override
public Book createFromParcel(Parcel in) {
return new Book(in);
}
@Override
public Book[] newArray(int size) {
return new Book[size];
}
};
}
//Book.aidl
package com.liupei.aidl;
parcelable Book;
// IBookManager.aidl
package com.liupei.aidl;
import com.liupei.aidl.Book;
interface IBookManager {
List getBookList();
void addBook(in Book book);
}
在上面三个文件中，Book.java是一个表示图书信息类，它实现了Parcelable接口。Book.aidl是Book类在AIDL中得声明。IBookManager是我们自定义得一个接口，里面有两个方法：getBookList和addBook，其中getBookList用于从远程服务端获取图书列表，而addBook用于往图书列表中添加一本书，当然这两个方法主要是示例，不一定要有实际意义。我们可以看导，尽管Book类已经和IBookManager位于相同得包中，但是IBookManager仍要导入Book类，这就是AIDL的特殊之处。编译过后。下面我们先看一下系统为IBookManager.aidl生成得Binder类，在Android Studio 得build
public interface IBookManager extends android.os.IInterface {
/**
* Local-side IPC implementation stub class.
*/
public static abstract class Stub extends android.os.Binder implements com.liupei.aidl.IBookManager {
private static final java.lang.String DESCRIPTOR = "com.liupei.aidl.IBookManager";
/**
* Construct the stub at attach it to the interface.
*/
public Stub() {
this.attachInterface(this, DESCRIPTOR);
}
/**
* Cast an IBinder object into an com.liupei.aidl.IBookManager interface,
* generating a proxy if needed.
*/
public static com.liupei.aidl.IBookManager asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof com.liupei.aidl.IBookManager))) {
return ((com.liupei.aidl.IBookManager) iin);
}
return new com.liupei.aidl.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_getBookList: {
data.enforceInterface(DESCRIPTOR);
java.util.List _result = this.getBookList();
reply.writeNoException();
reply.writeTypedList(_result);
return true;
}
case TRANSACTION_addBook: {
data.enforceInterface(DESCRIPTOR);
com.liupei.aidl.Book _arg0;
if ((0 != data.readInt())) {
_arg0 = com.liupei.aidl.Book.CREATOR.createFromParcel(data);
} else {
_arg0 = null;
}
this.addBook(_arg0);
reply.writeNoException();
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements com.liupei.aidl.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 java.util.List getBookList() throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.util.List _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(Stub.TRANSACTION_getBookList, _data, _reply, 0);
_reply.readException();
_result = _reply.createTypedArrayList(com.liupei.aidl.Book.CREATOR);
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
@Override
public void addBook(com.liupei.aidl.Book book) throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
try {
_data.writeInterfaceToken(DESCRIPTOR);
if ((book != null)) {
_data.writeInt(1);
book.writeToParcel(_data, 0);
} else {
_data.writeInt(0);
}
mRemote.transact(Stub.TRANSACTION_addBook, _data, _reply, 0);
_reply.readException();
} finally {
_reply.recycle();
_data.recycle();
}
}
}
static final int TRANSACTION_getBookList = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
static final int TRANSACTION_addBook = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);
}
public java.util.List getBookList() throws android.os.RemoteException;
public void addBook(com.liupei.aidl.Book book) throws android.os.RemoteException;
}
上面一大堆的代码都是由系统生成的，它继承了IInterface接口，同时自己也是一个接口，所以可以在Binder中传输的接口都需要集成IInterface接口，这个类刚开始看起来逻辑十分复杂，但实际上很清晰，通过它我们可以清楚的了解Binder得工作机制。这个类得结构其实很简单，首先，它声明了两个方法getBookList和addBook,显然就是我们aidl文件中声明得方法。同时它还声明了两个整型得id分别用于标识这两个方法，这两个id用于标识在transcat过程中客户端到底要请求哪个方法。接着，它声明了一个内部类Stub，这个Stub就是一个Binder类，当客户端和服务端位于同一个进程时，方法调用不会走跨进程得transact过程，而当两者位于不同的进程时，方案调用需要走transact过程，这个逻辑有Stub得内部代理类Proxy来完成。这么看来，IBookManager这个接口的确很简单，但是我们也应该认识到，这个接口得核心实现就是它得内部类Stub和Stub的内部代理类Proxy。
DESCRIPTOR
Binder的唯一标识，一般用当前Binder的类名表示，比如本例中的
private static final java.lang.String DESCRIPTOR = "com.liupei.aidl.IBookManager";
asInterface(android.os.IBinder obj)
用于将服务器的Binder对象转化成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的，如果处于同一进程，就返回返回服务器的Stub对象本身，否则就返回系统封装过后的Proxy对象。
asBinder
此方法返回当前Binder对象
onTransact
这个方法运行在服务端中的Binder线程池中，当客户端发起跨进程通信请求时，远程请求会通过系统底层封装后交给此方法处理。该方法的原型为 public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) 。服务端通过code可以确定客户端所请求的目标方法是什么，接着从data中取出目标方法所需要的参数，然后执行目标方法，当目标方法执行完毕后，就向reply中写入返回值（如果目标方法有返回值的话），onTransact方法的执行过程就是这样的。需要注意的是，如果此方法返回false，那么客户端就会请求失败，因此我们可以利用这个特性来做权限验证，可以防止其他进程远程调用我们的服务。
Proxy#getBooklist
这个方法运行在客户端，当客户端远程调用此方法时，它的内部实现是这样的:首先创建该方法所需要的输入型Parcel对象_data、输出型对象_reply和返回值对象list；然后把该方法的参数信号写入_data中；接着调用transact方法来发起RPC请求，同时当前线程挂起；然后服务端的onTransact方法会被调用，知道RPC过程返回，当前线程继续执行，并从reply中取出RPC过程返回结果；最后返回_reply中的data。
Proxy#addBook
这个方法和getBooklist 一样，addBook没有返回值，所以它不需要从_reply中取出返回值。
通过上面的分析，我们差不多了解了Binder的工作机制，但是有两点还是需要额外说明一下：首先，当客户端发起请求时，由于当前线程会被挂起直到服务端进程返回数据，所以如果一个远程方法时耗时的，那么不能在UI线程中发起此远程请求；其次，由于服务器的Binder方法运行在Binder的线程池中，所以Binder方法不管是否耗时都应该采用同步的方法去实现，因为它已经运行在一个线程中了。
Binder的出生与死亡
我们上面讲了Binder的交互机制，那么接下来我们讲Binder的两个很重要的方法linkToDeath和unlinkToDeath。我们知道，Binder运行在服务端进程，如果服务进程由于某种原因终止了。这个时候我们到服务端的Binder链接断裂了(称之为Binder死亡)，会导致我们的远程调用失败。更为关键的是，如果我们不知道Binder已经断裂了，那么客户端的功能就会受到影响。为了解决这个问题，Binder提供了两个配对的方法linkToDeath和unlinkToDeath，通过linkToDeath可以给Binder设置一个死亡代理，当Binder死亡时，我们就会收到通知，这个时候我们就可以重新发起链接请求链接恢复了。那么如何给Binder添加死亡代理呢?
private IBinder.DeathRecipient mDeathRecipient=new IBinder.DeathRecipient(){
@Overrid
public void binderDied(){
if(mBookManager==null)
return;
mBookManager.asBinder().unlinkToDeath(mDeathRecipient,0);
mBookManager=null;
//TODO 重新绑定
}
}
整理写作不易，请小伙伴多多支持，麻烦请点赞关注支持一下，。