从android aidl理解Proxy/stub模式

在小7写的上一篇文章《android IPC通信机制梳理》里，我讲到了如果activity要想和一个跨进程的Service进行通信就需要通过Binder框架，获取到IBinder对象，并调用transact()方法来达到通信的目的。该方法里的第一个参数是整数型的code，表示的是请求的服务类型，比如说我想请求使用某播放器服务，我就需要制定一个规则：当code为1时表示开始播放，当code为2时表示停止播放，当code为3时表示下一首歌曲。。。这中方法有几个问题：

1. 这个规则需要Activity和Service这对交互的双方共同知晓，也就是说，Service必须很清楚code的每个值代表对方要求哪个操作，这种形式非常不直观，也容易出错。
2. 这种方法在需要请求的操作数量较少的时候还可以忍受。可是如果数量非常多的时候，维护起来可就有点蛋疼了，而且在Service端实现自己的Binder对象方法里面不可避免需要写大量的if else块说着是switch case块，非常的不简洁又很难维护。

除了维护code不方便外，假如通信的时候需要一些额外的参数的话，Activity需要用一个Parcel对象把需要的参数依次写进去，再把该Parcel对象作为transact()方法的另一个参数传给Service。当Service这边的Binder对象得到该参数后，也必须按照之前写进去的次序依次读出来。看到了这么多不人性的交互方式，还能忍吗？所以找到一个更加人性化更加优雅的方法进行通信势在必行。

这个时候我们可以想一个办法，在Activity和IBinder对象之间找到这么一个中介，它要做的就是明白我们人类都懂的人性化接口比如：

interface IDoor{
public void open();
public void close();
public void alarm();
}

然后在它的内部把这些人性化的接口请求翻译成Binder明白的请求，也叫编码，这样Activity本身就不需要去了解什么IPC通信方式了，只需要调用这些基本的业务接口就好了。这个中介拿我们的术语来说就是Proxy了。所以我们可以这样来实现一个DoorProxy类：

public class DoorProxy implements IDoor{
private IBinder binder;
public DoorProxy(IBinder binder){
this.binder = binder;
}
public void open(){
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
binder.transact(1,data,reply,0);
}
}

这个类DoorProxy就起到了这么一个中介的作用。同样的，在Service端和Binder对象之间也需要这么一个中介，把Activity那边传过来的IPC通信编码解码成我们人类抖动的人性化接口，比如：

public abstract class DoorStub extends Binder implements {
protected boolean onTransact(int code, Parcel data, Parcel reply, int flags)
throws RemoteException {
if(code == 1){
open();
}
}
public abstract void open();
public abstract void close();
public abstract void alarm();
}

这样的话Service端自己定义的Binder对象只需要继承这个DoorStub类就可以了。

。