AIDL 跨进程调用 -- 接口层解析

基本使用方式

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;
  1. 可以发现,首先这是一个同步调用。
  2. 其次 参数和返回值的跨进程传输都是通过 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

是从静态对象池中获取,如果没有则创建一个。

最后一个问题,远端的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 对象。

综上 IBinder 的核心 是利用Parcel 对象序列化同步调用传输的过程

而AIDL是在IBinder 的基础上代码自动生成Proxy 代理类,完成序列化代码而简化开发成本。

你可能感兴趣的:(AIDL 跨进程调用 -- 接口层解析)