Android跨进程通信中Binder解析

android跨进程通信中binder解析。

两个接口

跨进程通讯中说到binder和aidl，就要说到最重要的两个接口：ibinder和iinterface。

binder具有被跨进程传输的能力是因为它实现了ibinder接口。会为每个实现了该接口的对象提供跨进程传输。那跨进程通信时，传输数据的媒介就是实现了ibinder的实例。

有了ibinder，iinterface又有啥用呢？我个人理解：这个接口只是为了方面操作（只有一个asbinder()方法嘛）。

那aidl文件和自动生成的同名的java文件是啥？aidl就是个接口咯，重点就在那个自动生成的java文件身上。这个java文件乍一看很大很乱，其实它的作用很简单：还是方便操作（咳咳，有点官方了）。下面一段细说。

通信方式

将通信看成是进程a和进程b的通信。进程a看作客户端，进程b看作服务器，我们想的通信过程：
1. 进程a将数据传递给进程b
2. 数据在进程b中进行处理
3. 进程a获取处理后的数据
4. 完美

然而实际是这样滴：
1. 进程b中定义实现了方法的binder
2. 进程a获取进程b的binder
3. 进程a使用进程b的binder来处理数据

假设a为一个activity，b为一个service。
a：有一个实现了iinterface的成员变量。一个serviceconnection成员变量。serviceconnection是用来接受从b中传过来的binder的。
b：一个binder成员变量（比较特别的是，这个binder类是实现了iinterface接口的子类）。

下面来分析aidl文件同名的java的类里有啥呢：一个子类stub（extends binder, inplements自定义的接口），basictypes()方法，未实现的自定义方法。

dang dang dang，这个stub类就是上面说的传递的binder。是不是说到这里该结束了，其实并没有。它的流程有点复杂，至于为什么这么复杂，其实我也不知道。（笑哭，以后分析）进程a获取到的binder并不是是这个stub，而是stub的一个代理/替身——proxy。

跨进程用替身（代理）

stub里面有啥呢：asinterface()方法、asbinder()方法、ontransact()方法、proxy类。proxy是它的替身。asinterface是个static方法：如果两个进程不同，那么它返回proxy；如果是同一进程，则返回自身。

替身套路与本身也不同，proxy同样也实现了aidl接口中的方法，而实现方法中其实还是调b的stub的方法（通过ontransact进行调用）。