IPC（五）——浅谈AIDL的架构原理

在 IPC（一）利用纯Binder通信（非aidl）中实现了，如何通过纯粹的Binder实现进程间的通信。然后在IPC（四）_Aidl的基本使用过程实现了如何通过Aidl实现进程间的通信。翻看代码的编写过程，其实大体上都差不多，而且也提到Aidl实质上就是对纯Binder通信进行了一次封装，毕竟IBinder中的transact（）方法传递的参数不方便使用，大大增加了开发者的使用负担。于是Google就提供了Aidl来简化开发者的负担。简化对于开发者来说既好也不好，因为简化了使用方便了，但是却不容易看清楚内部的原理了。下面就来看一看，Aidl的架构设计。

为了了解清楚Aidl，首先需要理解的就是Binder跨进程通信机制。在IPC（二）初识进程和Binder和 IPC（三）浅析Binder进程通信和ServiceManager中讲解了Binder的跨进程通信机制。下面来一张图，更好的明确Binder过程

IPC(三)中说过，ServiceManager 首先把服务（实现IBinder接口）加载入BinderDriver，接着Bind服务的时候ServiceManager 会返回一个IBinder对象给客户端，其实就是BinderProxy。客户端调用IBinder接口中的Transact（）方法通信。

但是Transact（）方法毕竟是要传递Pracel对象来传递数据，这大大增加了开发者的负担，于是Aidl就出世了。Aidl为了减轻开发这的负担，在客户端和服务端采用proxy——stub分别对IBinder接口进行了封装，内部调用Transact（），给开发者调用自己定义接口里的方法。

上图就是Aidl的设计过程，在MyActivity和IBinder直接增加了Proxy模式，在MyBinder和Binder之间增加了Stub模式，这两个模式分别包装了IBinder接口，在客户端对数据打包，在服务端对数据进行解包。

说名了Aidl的工作过程。回到IPC（四）中回看AIDL的代码实现过程

public static abstract class Stub extends android.os.Binder implements com.example.server.aidl.I