AIDL的使用流程以及原理详情
该文章参考了凶残的程序员(https://blog.****.net/qian520ao/article/details/78072250)博主的文章，如有侵权请通知删除
AIDL：Android接口定义语言。
A [android]
I [Interface]
D [Definition]
L [Language]
其作用是方便系统为我们声称代码从而实现夸进程通讯。换句话说就只是一个快速跨进程通讯的工具。
使用步骤：
1.声明文件：在服务端创建AIDL文件，用来生命java Bean以及传输调用的接口。
2.创建服务：在服务端创建Service并且实现上面的接口。
3.绑定服务：客户端绑定Service。
4.跨进程调用：客户端调用服务端接口。
一、声明文件
创建服务端AIDL项目文件，
创建载体MessageBean（它实现了
Parcelable接口，因为通讯对象需要转化成字节序列，用于传输和储存），
创建AIDLMessageBean.AIDL文件（转换方式也很简单，就下方两行代码），
package qdx.aidlserver;//手动导包
parcelable MessageBean;//parcelable是小写
创建IDemandManager.AIDL文件用来实现传递方法（如果方法内有传输载体，就必须知名定向的tag：
in : 客户端数据对象流向服务端，并且服务端对该数据对象的修改不会影响到客户端。
out : 数据对象由服务端流向客户端，（客户端传递的数据对象此时服务端收到的对象内容为空，服务
端可以对该数据对象修改，并传给客户端）
inout : 以上两种数据流向的结合体。（但是不建议用此tag,会增加开销）
）
此处有三个需要注意的点：
-
xxx.aidl 中不能存在同方法名不同参数的方法。
-
xxx.aidl 中实体类必须要有指定的tag。
-
在Android Studio里写完aidl文件还需要在build.gradle文件中android{}方法内添加aidl路径。
sourceSets { main { java.srcDirs = ['src/main/java','src/main/aidl'] } }
二、创建服务
接下来我们要创建一个服务，用来处理客户端发来的请求，或者定时推消息给客户端。
三、绑定服务
创建客户端项目（将服务端的AIDL文件拷贝到客户端，并且在gradle.build中关联aidl路径）
开启服务
Intent intent = new Intent();
intent.setAction("com.tengxun.aidl");//service的action
intent.setPackage("qdx.aidlserver");//aidl文件夹里面aidl文件的包名
bindService(intent, connection, Context.BIND_AUTO_CREATE);
四、跨进程调用
服务绑定成功之后，我们将服务短的IDemandManager.Stub对象，通过asInterface转换成为我们客户端需要的AIDL接口类型对象，并且这种转化过程是区分进程的。
至此为止就知道了AIDL的作用、使用和大致流程，接下来就详细为何AIDL能跨进程通讯。先贴一张图来看看
!!!
从上图可以看出整体的核心就是Binder
接下来逐个剖析
asInterface(IBinder)
用于服务端的Binder对象转换成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的（如果客户端和服务端位于同一个进程，那么此方法返回的就是服务端的Stub对象本身，否则返回的是系统封装后的Stub.proxy对象）
从上图的类结构图中我们可以看出，这个IDemandManager.aidl文件通过编译成为一个接口类，而这个类最核心的成员是Stub类和Stub的内部代理类Proxy。
顺着asInterface方法，结合上面对该方法的描述，可以看出通过DESCRIPTOR标识判断
如果是同一进程，那么就返回Stub对象本身(obj.queryLocalInterface(DESCRIPTOR))，否则如果是跨进程则返回Stub的代理内部类Proxy。
asBinder()
顾名思义，asBinder用于返回当前Binder对象。
//Stub
@Override
public android.os.IBinder asBinder() {
return this;
}
//Proxy
private android.os.IBinder mRemote;
@Override
public android.os.IBinder asBinder() {
return mRemote;
}
根据代码我们可以追溯到，proxy的这个mRemote就是绑定服务(bindService)时候
由IDemandManager.Stub.asInterface(binder);传入的IBinder对象。
这个Binder对象具有跨进程能力，在Stub类里面（也就是本进程）直接就是Binder本地对象，在Proxy类里面返回的是远程代理对象(Binder代理对象)。[所以跨进程的谜团，会随着对Binder的分析和研究，逐渐变得清晰起来。]
因为我们这个编译生成的IDemandManager接口继承了android.os.IInterface接口,所以我们先分析IInterface接口。
IInterface接口
该接口只实现了一个方法asBinder()，并且Stub和Proxy都间接的实现了该接口。
Binder接口的基类。 定义新接口时，
你必须实现IInterface接口。
检索与此界面关联的Binder对象。
你必须使用它而不是一个简单的转换
这样代理对象才可以返回正确的结果。
从上面的系统注释中我们可以理解出：
1.要声明(或者是手动diy创建)AIDL性质的接口，就要继承IInterface
2.代表远程server对象具有的能力，具体是由Binder表达出这个能力。
DESCRIPTOR
private static final java.lang.String DESCRIPTOR =
"qdx.aidlserver.IDemandManager";//系统生成的
Binder的唯一标识，一般用当前Binder的类名表示。
onTransact(int,Parcel,Parcel,int)服务端接收
onTransact方法运行在服务端中的Binder线程池中
客户端发起跨进程请求时，远程请求会通过系统底层封装后交给此方法来处理。
如果此方法返回false,那么客户端的请求就会失败。
下面是四个参数介绍：
code : 确定客户端请求的目标方法是什么。（项目中的getDemand或者是setDemandIn方法）
data : 如果目标方法有参数的话，就从data取出目标方法所需的参数。
reply : 当目标方法执行完毕后，如果目标方法有返回值，就向reply中写入返回值。
flag : Additional operation flags. Either 0 for a normal RPC, or FLAG_ONEWAY for a one-way RPC.（暂时还没有发现用处，先标记上英文注释）
也就是说，这个onTransact方法就是服务端处理的核心，接收到客户端的请求，并且通过客户端携带的参数，执行完服务端的方法，返回结果。
transact(MessageBean)客户端调用
分析完了Stub，就剩下Stub的内部代理类Proxy
惊奇的发现Proxy类主要是用来方法调用，也就是用来客户端的跨进程调用。
transact方法运行在客户端，首先它创建该方法所需要的输入型Parcel对象_data、输出型Parcel对象_reply;
接着调用绑定服务传来的IBinder对象的transact方法来发起远程过程调用（RPC）请求，同时当前线程挂起;
然后服务端的onTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果，也就是返回_reply中的数据。
我们看到获得Parcel的方法为Parcel.obtain()，按照套路这个应该就是从Parcel池中获取该对象，减少创建对象的开支，跟进方法我们可以看得的确是创建了一个POOL_SIZE为6的池用来获取Parcel对象。
所以在跨进程通讯中Parcel是通讯的基本单元，传递载体。
而这个transact方法是一个本地方法，在native层中实现，功力不足，点到为止。
总结
通过对AIDL的分析，我们发现原来这一切围绕着Binder有序的展开
AIDL通过Stub类用来接收并处理数据，Proxy代理类用来发送数据，而这两个类也只是通过对Binder的处理和调用。
所以所谓的服务端和客户端，我们拆开看之后发现原来竟是不同类的处理
Stub充当服务端角色，持有Binder实体（本地对象）。
1.获取客户端传过来的数据，根据方法 ID 执行相应操作。
2.将传过来的数据取出来，调用本地写好的对应方法。
3.将需要回传的数据写入 reply 流，传回客户端。
Proxy代理类充当客户端角色，持有Binder引用（句柄）。
1.生成 _data 和 _reply 数据流，并向 _data 中存入客户端的数据。
2.通过 transact() 方法将它们传递给服务端，并请求服务端调用指定方法。
3.接收 _reply 数据流，并从中取出服务端传回来的数据。