首先为什么需要aidl？
下面是不需要aidl 的binder的IPC通讯过程，表面上结构很简单，但是有个困难就是，客户端和服务端进行通讯，你得先将你的通讯请求转换成序列化的数据，然后调用transact（）函数发送给服务端，而且还得制定一个小协议，参数谁先谁后，服务端和客户端都必须一致，否则就会出错。这样的过程有没有觉的很麻烦，如果有上百个接口，那可就要疯掉了。可不可以就像调用自家函数那样呢？而不需要麻烦的将参数值转化成序列化数据呢？由此AIDL诞生了。
好，我定义一下服务的函数，然后写成一个interface文件
前面的I字母加上去只是一种AIDL文件形式上的标识。
interface IxxxxService (
void ServiceFunctionA();
void ServiceFunctionB();
void ServiceFunctionC();
)
利用aidl工具生成一个IxxxxService.java文件，然后它的uml图如下。
其中的一些函数的理解:
IxxxxService.Stub.asInterface(IBinder obj) ：
这个函数是干啥用呢？首先当bindService之后，客户端会得到一个Binder引用，是Binder 哟，不是IxxxxService.Proxy实例，那这样的话，我们第一个想法是利用Binder引用作为参数实例化出一个IxxxxService.Proxy。Ok, 但如果服务端和客户端都是在同一个进程呢，还需要利用IPC吗？这样就不需要了，直接将IxxxxService当做普通的对象调用就成了。Google 的同志们他们利用IxxxxService.Stub.asInterface函数对这两种不同的情况进行了统一，也就是不管你是在同一进程还是不同进程，那么在拿到Binder引用后，调用IxxxxService.Stub.asInterface(IBinder obj) 即可得到一个IxxxxService 实例，然后你只管调用IxxxxService里的函数就成了。
*******asInterface英文字面意思我没能想到合理的解释...有英语好的讲讲********
asBinder
返回自身类里包含的Binder对象实例。
总结:
AIDL的最终效果就是让 IPC的通讯就像调用函数那样简单。自动的帮你完成了参数序列化发送以及解析返回数据的那一系列麻烦。而你所需要做的就是写上一个接口文件，然后利用aidl工具转化一下得到另一个java文件，这个文件在服务和客户端程序各放一份。服务程序继承IxxxxService.Stub 然后将函数接口里面的逻辑代码实现一下。