ok，接android IPC机制讲解(二)继续
可以看到IBookManager.aidl系统为我们生成了IBookManager.java这个类，他继承了IInterface这个接口。具体看代码，首先，他申明了两个方法getBookList和addBook，显然这就是我们再IBookManager.aidl中所申明的方法。同时他还申明了两个整型的id分别用于标识这两个方法。这两个id用于标识在transact过程中客户端请求的到底是哪个方法。接着，他申明了一个内部类Stub，这个Stub就是一个Binder类，当客户端和服务器都位于同一个进程时，方法调用不会走跨进程的transact过程，而当两者位于不用进程的时候，方法调用需要走transacthi赔偿金额美好，这个逻辑由Stub的内部代理类Proxy来完成，这么看来，IBookManager这个接口的确很简单，但是我们 应该认识到这个接口的核心实现就是他的内部类Stub和Stub的内部代理Proxy
DESCRIPTOR
Binder的唯一标识，一般用当前Binder的类名标识，例如”包名”+“.IBookManager”
asInterface(android.os.IBinder obj)
用于服务端的Binder对象转换成客户端所需要的AIDL接口类型的对象，这种转换是区分进程的，如果客户端和服务端位于同一进程，那么此方法返回的就是服务端的Stub对象本身，否则返回的是系统封装后的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,输出型Parcel对象_reply和返回值对象List，然后把该方法的参数信息写入_data中，接着调用tracsact方法来发起RPC（远程调用）请求，同时当前线程挂起，然后服务端的onTransact方法会被调用，知道RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果，最后返回_reply中的数据
Proxy#addBook
这个方法也是在客户端，其执行的方式和getBookList是类似的。
上述的分析中还需要注意的地方，首先，当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以如果一个远程方法是很耗时的，那么不能再UI线程中发起此远程请求，其次，由于服务端Binder方法运行在Binder的线程池中。为了更好的说明Binder。下面给出一个Binder的工作机制图:
楼主第一次画图，比较挫哈，不过也能凑合看吧。
从上述分析过程来看，我们完全可以不提供AIDL文件即可实现Binder，之所以提供AIDL文件，是为了方便系统为我们生成代码，系统根据AIDL文件生成Java文件的格式是固定的，我们可以抛开AIDL文件直接写一个Binder出来，接下来我们就介绍如何手动写一个Binder。
首先，他本身是一个Binder的接口(继承了IInterface),其次他的内部有个Stub类，这个类就是Binder。还记得我们是怎么写一个Binder的服务端吗？代码如下
private Binder mBinder = new IBookManager.Stub() {
@Override
public List<Book> getBookList() throws RemoteException {
// TODO Auto-generated method stub
return mBookList;
}
@Override
public void addBook(Book book) throws RemoteException {
// TODO Auto-generated method stub
mBookList.add(book);
}
}
首先我们会实现 一个创建了一个Stub对象并在内部实现IBookManager的接口方法，然后在Service的onBind中返回这个Stub对象，因此，从这一点来看，我们完全可以把Stub类提取出来，直接作为一个独立的Binder类来实现。这样IBookManager中就只剩接口本身了，通过这种分离方式可以让他的结构变得清晰点。
根据上面的思想，手动实现一个Binder可以通过如下步奏来完成:
1.申明一个ADIL性质的接口，只需要继承IInterface接口即可，IInterface接口中只有一个azBinder方法，这个接口的实现如下”
public interface IBookManager extends IInterface {
static final String DESCRIPTOR = "com.zxx.binderframework.customAidl.IBookManager";
static final int TRANSACTION_getBookList = IBinder.FIRST_CALL_TRANSACTION + 0;
static final int TRANSACTION_addBook = IBinder.FIRST_CALL_TRANSACTION + 1;
public List<Book> getBookList() throws RemoteException;
public List<Book> addBook(Book book) throws RemoteException;
}
可以看到，在接口中声明了一个Binder描述符和另外两个id，这两个id分别表示的是getBookList和addBook方法，这段代码原本也是系统生成的，我们仿照系统生成的规则去手动书写这部分代码，如果我们有三个方法。应该怎么做呢？很显然，我们要再声明一个id。然后按照固定模式声明这个新方法即可，这个比较好理解，不再多说。
2.实现Stub类和Stub类中的Proxy代理类，这段代码我们可以自己写，但是写入来后会发现和系统自动生成的代码是一样的，因此这个Stub类我们只需要参考系统生成的代码即，只是结构上需要做一下调整，调整后代码如下：
package com.zxx.binderframework.customAidl;
import java.util.List;
import com.zxx.binderframework.aidl.Book;
import android.os.Binder;
import android.os.IBinder;
import android.os.Parcel;
import android.os.RemoteException;
public class BookManagerImpl extends Binder implements IBookManager {
public BookManagerImpl() {
his.attachInterface(this, DESCRIPTOR);
}
public static IBookManager asInterface(IBinder obj) {
if (obj == null) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof IBookManager))) {
return ((IBookManager) iin);
}
return new BookManagerImpl.Proxy(obj);
}
@Override
public IBinder asBinder() {
// TODO Auto-generated method stub
return this;
}
@Override
protected boolean onTransact(int code, Parcel data, Parcel reply, int flags)
throws RemoteException {
// TODO Auto-generated method stub
switch (code) {
case INTERFACE_TRANSACTION: {
reply.writeString(DESCRIPTOR);
return true;
}
case TRANSACTION_getBookList: {
data.enforceInterface(DESCRIPTOR);
List<Book> result = this.getBookList();
reply.writeNoException();
reply.writeTypedList(result);
return true;
}
case TRANSACTION_addBook: {
data.enforceInterface(DESCRIPTOR);
Book arg0;
if ((0 != data.readInt())) {
arg0 = Book.CREATOR.createFromParcel(data);
} else {
arg0 = null;
}
this.addBook(arg0);
reply.writeNoException();
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
@Override
public List<Book> getBookList() throws RemoteException {
// TODO 待实现
return null;
}
@Override
public void addBook(Book book) throws RemoteException {
// TODO 待实现
}
private static class Proxy implements IBookManager {
private IBinder mRemote;
public Proxy(IBinder remote) {
// TODO Auto-generated constructor stub
mRemote = remote;
}
@Override
public IBinder asBinder() {
// TODO Auto-generated method stub
return mRemote;
}
public java.lang.String getInterfaceDescriptor() {
return DESCRIPTOR;
}
@Override
public List<Book> getBookList() throws RemoteException {
// TODO Auto-generated method stub
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
List<Book> result;
try {
data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(TRANSACTION_getBookList, data, reply, 0);
reply.readException();
result = reply.createTypedArrayList(Book.CREATOR);
} finally {
reply.recycle();
data.recycle();
}
return result;
}
@Override
public void addBook(Book book) throws RemoteException {
// TODO Auto-generated method stub
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
try {
data.writeInterfaceToken(DESCRIPTOR);
if (book != null) {
data.writeInt(1);
book.writeToParcel(data, 0);
} else {
data.writeInt(0);
}
mRemote.transact(TRANSACTION_addBook, data, reply, 0);
reply.readException();
} finally {
eply.recycle();
data.recycle();
}
}
}
}
通过上诉代码和系统生成的代码对比，可以发现简直一模一样。也许有人会问，既然和系统生成的一模一样，那么我们为什么要手动去写呢？我们再实际开发中完全可以通过AIDL文件让系统去自动生成，手动去写的意义在于可以让我们更加理解Binder的工作原理，同时也提供了一种不通过AIDL文件来实现Binder的新方式，也就是说，AIDL文件并不是实现Binder的必需品。如果是我们手写的Binder，那么在服务端只需要创建一个BookManagerImpl的对象并在Service的onBind方法中返回即可，最后，是或否手动实现Binder没有本质区别，二者的工作原理是完全一样的。
接下来，我们介绍Binder的两个和重要的方法linkToDeath和unlinkToDeath。我们知道，Binder运行在服务端进程，如果服务端进程由于某种原因异常终止，这个时候我么到服务端的Binder连接断裂(称之为Binder死亡)，会导致我们的远程调用失败。更为关键的是，如果我们不知道Binder已经断裂了，那么客户端的功能会收到影响。为了解决这个问题，Binder中提供了两个配对的方法linkToDeath和unlinkToDeath,通过linkToDeath我们可以给Binder设置一个死亡代理，当Binder死亡时，我们就会收到通知，这个时候我们就可以重新发起连接请求从而恢复连接。那么如何给Binder设置死亡代理呢？
首先申明一个DeathRecipent对象，其内部只有一个方法binderDied ,我们需要实现这个方法，当Binder死亡的时候，系统就会回调binderDied方法，然后我们就可以移除之前绑定的binder并重新绑定远程服务：
···
private IBinder.DeathRecipient mDeathRecipient=new IBinder.DeathRecipient() {
@Override
public void binderDied() {
// TODO Auto-generated method stub
if(mBookManager==null)
return ;
mBookManager.asBinder().unlinkToDeath(mDeathRecipient,0);
mBookManager=null;
}
};
···
其次，在客户端绑定远程服务成功后，给binder设置死亡代理
···
mService=IMessagBoxManager.Stub.asInterface(binder);
binder.linkToDeath(mDeathRecipient,0);
···
其中linkToDeath的第二个参数是个标记为，我们直接设为0即可，经过上面两个步奏，我们就给我们的BInder设置了死亡代理，当Binder死亡的额时候我们就可以收到通知了，另外，通过Binder的方法isBinderAlive也可以判断Binder是否死亡。
到这里IPC的基础知识就介绍完了，下面开始进入正题，直面形形色色的进程间通信方式。
