简述AIDL架构

看到网上很多文章写AIDL，大多是写其用法而没有讲明白它究竟是什么？在IPC中究竟扮演了什么角色？而千篇一律上来就是AIDL全称是什么，一大堆名词解释，专业术

语。把一个本质上很简单的东西描述的很复杂，看的别人一头雾水，始终没明白它的实际意义。以此，我会尽量用简单的接地气的表达方式来阐述AIDL。

AIDL本质上只是google为了方便app开发人员开发的一个类生成工具而已，没有什么特别之处，仅仅是一个aidl.exe运行程序罢了。

那么谷歌为什么要开发出这么一个工具呢？

这就要来说一说IPC进程间通信机制了,在android当中一个进程无法直接与另一个进程数据传输，因为每一个进程都有一个独立vm,一个独立ui线程,ui线程有它的消息队列

(mq)以及loop,也就是进程间数据隔离，无法访问，要实现通信，那就需要用到ibind接口,我们在java以及虚拟机层看到的bind接口其实只是表象，实际上java层的ibind接口是与

最底层内核的ibind驱动通信再回调给java层。不知道为什么ibind驱动会称之为驱动，我觉得叫ibind共享区域更为贴切。

我们举个例子来说明IPC通信机制.下面有一个场景ACTIVITY要调用远程的支付SERVICE，假设activity与service都是写在同一个app内的，配置的时候service设为:remote进

程,activity为默认app进程.

1:activity startService后，activity向UI线程中的消息队列发了一封信说我要开启这个服务，之后ams接收到并开启service并运行在:remote进程中

2:当service启动,我们创建一个Bind对象，此对象会走Bind构造中的native方法 init()函数,init()函数实质上就是去初始化底层IBind接口,开辟地址空间。

3:activity bindService,并传递一个connection对象，此对象很重要，它是建立通信的桥梁。连接建立成功后Ams将远端的IBind接口传回connection接口

4,activity拿到ibind调用其transact方法,transact()实际调用底层的Ibind,Service透过底层收到消息通过exeTransact方法调用Service的onTransact();

由此完成了IPC通信.而作为APP开发者，在跨进程通信上最终要的是transact() --发送， onTransact()接收 这两个方法.而这两个方法的参数

transact(int code, Parcel data, Parcel reply, int flags) 

整整四个参数，而且想要传简单的String,Integer不能直接传输，必须要包进Parcel里，简而言之，从发送到接收需要编码与解码过程，增加了App开发人员的负担。

为了解决这种架构产生的问题，google就想了个主意。

1，我发送端与服务端各建一个类，并定义一个用户实际需求的接口Operate，发送端叫Proxy,服务端叫Stub,我服务端Stub继承Binder实现Operate接口 重写OnTransact(）把数

据解码过程自己写完，而开放更简单的Operate接口，

2，客户端Proxy同样继承Operate并持有Ibind对象在,activity直接调用Operate方法触发Ibind的transact并通过参数区分方法名让服务端解析.

这种设计就相当于Ibind变成了傀儡政权，需听命于Proxy与Stub，我接口规定了什么，你照做并按照我的指示行动即可。

其实AIDL就是生成Proxy与Stub两个类的工具，只不过实际上把这两个类放在了一个Stub里罢了。AIDL只是让app开发者更方便的使用了IBIND机制，仅此而已。