最近在重新看<Android开发艺术探索>准备将阅读的记录下来,加深理解
Binder
从来类的角度来说，Binder就是Android的一个类，它继承了IBinder接口
从IPC的角度来说，Binder是Android中的一个中的一种跨进程通信方式，Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder，该通信方式在Linux中没有(由于耦合性太强，而Linux没有接纳)
从Android Framework角度来说，Binder是ServiceManager连接各种Manager(ActivityManager、WindowManager等)和相应的ManagerService的桥梁
从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调用相应的函数方法, 接着函数挂起,等待执行完毕后会读取返回到的数据然后返回.接着我们通过代码来查看一下这个过程.
@Override
public java.util.List<Book> getBookList() throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.util.List<Book> _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中的方法我们不需要再开线程进行执行.
所以整个过程就比较清晰了:
首先客户端发起一个远程的请求->Binder收到之后,将参数写入到data中,调用transact方法执行,远程的Service中的OnTransact函数指定函数被调用,将结果写入到reply返回到Binder中,Binder获取到结果,返回给Client;
