写在前面
本文主要是我个人的理解思路方式。趁着还清晰，所记录的。如果哪位朋友读了两句不合胃口（因为主要是梳理思路，可能我写这个的时候默认一些东西了，就没写出来）。建议读下我下面参考文章里的文章。最后一篇文章是介绍Web模块独立进程实现的。本文里的代码。也是基于此的。感谢建良。
AIDL。Android Interface Definition Language，也就是Android接口定义语言。
那么实际上就跟接口回调一样。客户端拿到服务端的接口。然后操作。
本文结合项目中H5进程与主进程的通信进行梳理。主要有js调用接口后到主进程。还有h5监听到某种页面后，做一些通知处理
比如，如果发现url中有callback字样。则通知主进程发送一个eventbus。然后对应的地方接收进行操作，
第一步。写.aidl 文件。
并在里面声明我们需要的方法。编译器会自动生成一个对应的.java文件。如下
。
可以看到里面有一个抽象类Stub继承了Binder，并且实现了我们一开始.aidl的接口。那我们再写一个类来继承这个Stub。就可以作为实现类，类进行响应一些方法的调用。如下
第二步。写主进程的服务端，用于客户端来连接
Service有了然后就是binderService。连接服务，有个参数是ServiceConnection，然后回调方法onServiceConnected，方法连接后会返回一个IBinder对象。
通过IBinderManager.Stub.asInterface(service) . 客户端拿到了服务端（主进程）返回的binder。
注意点
mBinderManager = IBinderManager.Stub.asInterface(service)这里。
对于Binder IPC的过程中, 同一个进程的调用则会是asInterface()方法返回的便是本地的Binder对象;对于不同进程的调用则会是远程代理对象BinderProxy. 下面是系统自动生成的对应aidl的类。发现
跟学习Activity启动流程的跨进程很相似。具体看注释
//子进程请求主进程服务成功后，返回这个管理器Binder，在子进程可以根据binderCode拿到需要的Binder
//这种设计是为了解耦，方便不同业务下把Binder分离
public interface IBinderManager extends android.os.IInterface {
//本地
/** Local-side IPC implementation stub class. */
public static abstract class Stub extends android.os.Binder implements com.silvrr.common.IBinderManager {
private static final java.lang.String DESCRIPTOR = "com.silvrr.common.IBinderManager";
/** Construct the stub at attach it to the interface. */
public Stub() {
this.attachInterface(this, DESCRIPTOR);
}
/**
* Cast an IBinder object into an com.silvrr.common.IBinderManager interface,
* generating a proxy if needed.
*/
public static com.silvrr.common.IBinderManager asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof com.silvrr.common.IBinderManager))) {
return ((com.silvrr.common.IBinderManager) iin);
}
//这个方法在下面
return new com.silvrr.common.IBinderManager.Stub.Proxy(obj);
}
@Override
public android.os.IBinder asBinder() {
return this;
}
@Override
public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags)
throws android.os.RemoteException {
switch (code) {
case INTERFACE_TRANSACTION: {
reply.writeString(DESCRIPTOR);
return true;
}
case TRANSACTION_queryBinder: { //跟下面发送的一样。因为是抽象类。所以到这里后，具体实现就会调用实现类
//即BinderManager
data.enforceInterface(DESCRIPTOR);
int _arg0;
_arg0 = data.readInt();
android.os.IBinder _result = this.queryBinder(_arg0);
reply.writeNoException();
reply.writeStrongBinder(_result);
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
//服务端在客户端的代理
private static class Proxy implements com.silvrr.common.IBinderManager {
private android.os.IBinder mRemote;
Proxy(android.os.IBinder remote) {
//这个remote就跟Activity启动流程里。
// 可知mRemote便是指向服务端的binder/BinderProxy对象
mRemote = remote;
}
@Override
public android.os.IBinder asBinder() {
return mRemote;
}
public java.lang.String getInterfaceDescriptor() {
return DESCRIPTOR;
}
//aidl里声明的方法
@Override
public android.os.IBinder queryBinder(int binderCode) throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
android.os.IBinder _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
_data.writeInt(binderCode);
//这里层层下去最后到了binder驱动，然后再一层层回来。
// 底层到了共享内存。然后就再一层层调用了另一个进程（服务进程）的ontransact方法，
// 然后里面会调用我们的具体的方法。 proxy中transact就跟ActivityManagerProxy中一样。
// 最终到了AMN即AMS的onTransact中 ，本方法在上面。该内部类的外面stub中。
mRemote.transact(Stub.TRANSACTION_queryBinder, _data, _reply, 0);
_reply.readException();
_result = _reply.readStrongBinder();
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
}
static final int TRANSACTION_queryBinder = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
}
public android.os.IBinder queryBinder(int binderCode) throws android.os.RemoteException;
}
借用Service启动的一个图
总结
在重复几句。
通过asInterface，将服务端的binder传过来（service绑定后返回的，实际上是服务端binder的代理BinderPoxy），返回一个new Proxy（上面代码中proxy）。这个proxy就是服务端在客户端的代理了。因为这个代理里面把我们传过来的binder赋给了一个mRemote对象。所以我们在调用我们子进程的方法，比如
比如调用mBInderManger的方法的时候。因为这个mBIndermanaer在asInterface时返回的就是上面这个proxy的对象。所以，就调用了proxy里面的queryBinder方法。
然后如注释中说的。然后结合上面的图。会一层层最后调用了
。
应该是比较清楚了。客户端连接service。然后返回一个binder。客户端通过这个binder，拿到一个服务端的代理。 然后客户端要进行操作了。直接调用对应的方法，该方法里直接调用了服务端（mRemote）的
transact方法。这就到了Binder里。binder又层层的深入到共享内存。然后回到了onTransact方法。该方法里调用了我们的具体实现类的对应方法。这里指的BinderManager（不要被名字迷惑，因为这个aidl恰好是管理本地不同aidl生成不同binder的。所以这么叫的一个类）。
另外，这里Stub跟他的代理。因为他们都实现了同一个接口，此处是IBinderManager。所以代理。
另外，刚才说的是子进程到主进程的通信。那么主进程如何通知子进程呢，也是通过AIDL。因为在子进程中我们已经拿到了主进程的Binder。所以，在这个binder的方法里，可以声明一个方法，把我们的aidl生成的类作为一个参数传过去，那这样主进程就拿到了子进程的binder。就可以随时回调了。
参考
彻底理解Android Binder通信架构
Android：学习AIDL，这一篇文章就够了(上)
android web模块独立进程的实现
