基本使用方式
Service 和 Client 都需要声明一模一样的aidl 文件， 然后Service 端在 onBind 的时候 将aidl 接口实现并且返回， client 端在 service connection 中 获取并调用。
原理
解析AIDL 生成的文件发现，
每次接口函数调用都经历的步骤是：
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
android.os.Bundle _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
_data.writeInt(apiVersion);
_data.writeString(packageName);
_data.writeString(type);
if ((skusBundle != null)) {
_data.writeInt(1);
skusBundle.writeToParcel(_data, 0);
} else {
_data.writeInt(0);
}
mRemote.transact(Stub.TRANSACTION_getSkuDetails, _data, _reply, 0);
_reply.readException();
if ((0 != _reply.readInt())) {
_result = android.os.Bundle.CREATOR.createFromParcel(_reply);
} else {
_result = null;
}
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
- 可以发现，首先这是一个同步调用。
- 其次 参数和返回值的跨进程传输都是通过 Parcel 结构 obtain() 后的对象实现。
入参传递时，首先writeinterfacetoken 是一个字符串，自动生成的是唤起service的action 应该可以被替换
源码与解释：
/**
* Store or read an IBinder interface token in the parcel at the current
* {@link #dataPosition}. This is used to validate that the marshalled
* transaction is intended for the target interface.
*/
public final void writeInterfaceToken(String interfaceName) {
nativeWriteInterfaceToken(mNativePtr, interfaceName);
}
然后 调用mRemote transact ，看名字会转发到Service 端的 Binder （那个一模一样的aidl 接口） 的ontransact 方法中， 并且将回调通过reply 的parcel 返回过来。 进而result 从reply 中创建起来。 每次transact 的时候会附带对应接口方法的编号，如这里的Stub.TRANSACTION_getSKUDetails 的int 值用于区分接口
这就是调用的过程
类似的，接收端也是通过 ontransact 接口的实现，根据协议约好的code解析序列化的接口
@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_getSkuDetails: {
data.enforceInterface(DESCRIPTOR);
int _arg0;
_arg0 = data.readInt();
java.lang.String _arg1;
_arg1 = data.readString();
java.lang.String _arg2;
_arg2 = data.readString();
android.os.Bundle _arg3;
if ((0 != data.readInt())) {
_arg3 = android.os.Bundle.CREATOR.createFromParcel(data);
} else {
_arg3 = null;
}
android.os.Bundle _result = this.getSkuDetails(_arg0, _arg1, _arg2, _arg3);
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);
}
因此传输和解析事实上都是通过一个Parcel 对象来完成的。
看一下这个对象的生成方式：
/**
* Container for a message (data and object references) that can
* be sent through an IBinder. A Parcel can contain both flattened data
* that will be unflattened on the other side of the IPC (using the various
* methods here for writing specific types, or the general
* {@link Parcelable} interface), and references to live {@link IBinder}
* objects that will result in the other side receiving a proxy IBinder
* connected with the original IBinder in the Parcel.
*
/**
* Retrieve a new Parcel object from the pool.
*/
public static Parcel obtain() {
final Parcel[] pool = sOwnedPool;
synchronized (pool) {
Parcel p;
for (int i=0; i<POOL_SIZE; i++) {
p = pool[i];
if (p != null) {
pool[i] = null;
if (DEBUG_RECYCLE) {
p.mStack = new RuntimeException();
}
return p;
}
}
}
return new Parcel(0);
}
是从静态对象池中获取，如果没有则创建一个。
最后一个问题，远端的binder 对象我们怎么生成转化成这个实际的stub 对象的。 这是一个代理模式。 通过Stub中的Proxy 创建。
源头是这个静态方法
public static IAIDLInterface asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof IInAppBillingService))) {
return ((IInAppBillingService) iin);
}
return new IInAppBillingService.Stub.Proxy(obj);
}
而事实上，我们使用的也是这个Proxy 对象，它实现了我们AIDL中定义的接口函数，并且对每一个函数按照上面的方法序列化，然后调用mRemote 对象 ， 也就是onService Connection 之后返回给我们的 Ibinder 对象。
