Android中的IPC-(Binder) Android中的IPC-(Binder)

最近在重新看准备将阅读的记录下来,加深理解

Binder

从来类的角度来说，Binder就是Android的一个类，它继承了IBinder接口
从IPC的角度来说，Binder是Android中的一个中的一种跨进程通信方式，Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder，该通信方式在Linux中没有(由于耦合性太强，而Linux没有接纳)
从Android Framework角度来说，Binder是ServiceManager连接各种Manager(ActivityManager、WindowManager等)和相应的ManagerService的桥梁
【Android中的IPC-(Binder)】从Android应用层的角度来说，Binder是客户端和服务端进行通信的媒介，当你bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务

Android开发中,Binder主要是用于Service中,包括了Aidl和Messenger,Messenger的底层实现其实就是AIDL.
我们新建一个aidl文件,build之后系统会自动根据创建的aidl文件生成一个同名的java文件,他本质是一个继承了android.os.IInterface的接口,所有可以在Binder中传输的接口都需要继承IInterface这个接口.
系统生成的代码中,会有之前在aidl中声明的方法同时有一个抽象的Stub类,这个Stub其实就是一个Binder类，同时在Stub中还有一个内部Proxy类。
这里我绕了很久才明白为什么在Proxy内的方法是运行在客户端的，onTransact的方法是运行于服务端的,我们这里可以先看一下概念,后续会通过代码进行分析
首先可以查看一下Stub内部的元素：

DESCRIPTOR:唯一标识符
Stub():构造函数
asInterface(android.os.IBinder obj) :用于将远程的Binder对象转换为客户端所需要的AIDL对象.在此函数中,如果服务端和客户端是处于同一进程,返回的就是服务端的Stub对象,如果不是则会返回封装的Stub.Proxy对象
asBinder:返回当前的Binder对象
onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags):该方法运行与服务端的Binder线程池中,当客户端发起了跨进程的请求时,远程请求会通过系统底层封装后交给该函数进行处理,服务端可以通过code知道远程调用的是哪一个方法,将传入的data中取出方法需要的参数(如果方法需要的话),然后执行目标方法.执行完毕后将返回值放入到reply中,返回false的话客户端的调用会失败
Proxy类:代理类
内部有一个android.os.IBinder的内部变量mRemote,代表了远程的Ibinder对象,构造函数为

Proxy(android.os.IBinder remote) {mRemote = remote; }

Proxy#声明的方法:
这个方法会运行在客户端,当客户端进行调用时,首先会获取到两个Parcel对象,一个为传入的数据,一个为返回的数据. 通过函数_data.writeInterfaceToken(DESCRIPTOR); 将当前远程的唯一描述符写入,接着通过函数transact调用相应的函数方法, 接着函数挂起,等待执行完毕后会读取返回到的数据然后返回.接着我们通过代码来查看一下这个过程.

@Overridepublic java.util.List getBookList() throws android.os.RemoteException {android.os.Parcel _data = https://www.it610.com/article/android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); java.util.List _result; try {_data.writeInterfaceToken(DESCRIPTOR); mRemote.transact(Stub.TRANSACTION_getBookList, _data, _reply, 0); _reply.readException(); _result = _reply.createTypedArrayList(com.hy.bindertest.Book.CREATOR); }finally {_reply.recycle(); _data.recycle(); }return _result; }

接着我们进入mRemote.transact()这个函数中.

/*** Default implementation rewinds the parcels and calls onTransact.On* the remote side, transact calls into the binder to do the IPC.*/public final boolean transact(int code, @NonNull Parcel data, @Nullable Parcel reply, int flags)throws RemoteException {if (false) Log.v("Binder", "Transact: " + code +" to " +this); if (data !=null) {data.setDataPosition(0); }boolean r = onTransact(code, data, reply, flags); //这里代用了onTransact方法if (reply !=null) {reply.setDataPosition(0); } return r; }

会发现他最后调用的就是mRemote中的onTransact函数,而mRemote这个远程Binder对象,是运行于服务端的BInder线程中,所以这里也就是所说的onTransact方法运行于服务端的Binder线程池中的原因,这时候当前线程会被挂起,等待RPC过程结束后,当前线程继续进行,然后从_replay中获取到RPC过程返回的结果,最后返回_replay中的数据.
所以,我们就知道,当客户端发起一次远程的调用时,当前的线程会被挂起知道服务端返回数据,所以一个远程函数是很耗时的,我们不能在UI线程中进行调用,而服务器端的Binder方法是运行于Binder的线程池中的,所以Binder中的方法我们不需要再开线程进行执行.
所以整个过程就比较清晰了: