AIDL的in out inout

使用AIDL的第一步是在Service工程中创建一个.aidl文件，并在其中定义Service、Activity两端统一的AIDL接口：

图1

完成定义后，Service工程的gen目录下会立即自动生成IAidl.java文件，此时尚未开始接口函数的具体实现，代码如下：

图2

图3

最外层是一个名为IAidl(与.aidl文件定义的一致)的Interface的定义，它继承了android.os.IInterface。

IAidl包含以下两部分：

1、一个名为Stub的抽象子类的定义

2、AIDL接口中函数的声明

Stub抽象子类继承了android.os.Binder,并且是IAidl接口的一个实现。Stub中比较重要的三处：

1、asInterfac()方法：如31行所示，它的任务是返回一个Proxy子类的对象

2、onTransact()方法：IBinder的主要API是transact()，与它对应另一方法是Binder.onTransact()。第一个方法使你可以向远端的IBinder对象发送发出调用，第二个方法使你自己的远程对象能够响应接收到的调用。IBinder的API都是同步执行的，比如transact()直到对方的Binder.onTransact()方法调用完成后才返回。调用发生在进程内时无疑是这样的，而在进程间时，在IPC的帮助下，也是同样的效果。

3、Proxy子类的实现(整个包

含在Stub中，68-107行)：在Activity连接Service后由Service返回一个IBinder对象，然后由这个对象生成一个Proxy类型的对象（正是调用asInterfac()完成的），赋值给IAidl类型的本地变量，之后可以操作这个IAidl对象调用AIDL接口函数。

图4

Proxy子类：

它是Stub类的子类，是本文定义的AIDL接口的一个实现。如图4：Service端传入的IBinder对象作为asInterface的输入参数，结合图2第31行、图3第71、72行可知，此参数最终赋值到了Proxy的本地变量。

Activity端，或者称client端，直接调用的是onServiceConnected的返回值（图4，30行），然后依此调用AIDL接口函数：

图5

实际上client端调用的是这个对象是Proxy类型的，调用的函数是Proxy自动生成的，如图3，第85-104行所示，也即图5第55行的具体实现。看图1，接口函数的参数定义，source为in，输入型；destination为out，输出型。再看Proxy中copyArray的实现，图三中，88、89行，新建了两个Parcel对象，_data、_reply，_data作为传入的参数，_reply为应答。92行：将in型参数source写入_data，完成序列化；96行：写入destination的长度；98行，调用transact()方法，等待Service端onTransact()响应；onTransact转入第48行执行，50、51行创建String[]变量，并从data中反序列化，得到client端传来的String[]变量；53行反序列化，得到int（输出的String[]的长度）；59行调用本地的copyArray方法，这时执行的是下面的代码：

图6

之后62行将输出的String[]型_arg1写入Parcel型reply变量，完成序列化；此时onTransact执行完毕，返回98行；101行，Proxy将onTransact返回的_reply反序列化，写入destination中，destination即获得了返回值。整个流程结束。

如果将AIDL接口函数中，source改为out，destination改为in，代码如下：

对比source---in，destination---out时可知，序列化与反序列化过程正好相反。读者可以将两个参数均设为inout，自行查看结果。

总结可知，in、out、inout参数使用规则如下：

in：client端将参数设定好，传给server，server端拷贝、使用。

out：client将接口、地址等“空壳”传给server，server将运算结果填充进去，然后client从中取出运算结果。

inout：client端既从此处传入数据，又从此处取出server填充的结果。

将完成in功能的设成out、或out功能的设成in，都会报错。若将连个均设成inout，则通过，但增加了序列化的步骤，白白浪费运算资源。