AIDL思路梳理 AIDL思路梳理

写在前面本文主要是我个人的理解思路方式。趁着还清晰，所记录的。如果哪位朋友读了两句不合胃口（因为主要是梳理思路，可能我写这个的时候默认一些东西了，就没写出来）。建议读下我下面参考文章里的文章。最后一篇文章是介绍Web模块独立进程实现的。本文里的代码。也是基于此的。感谢建良。
AIDL。Android Interface Definition Language，也就是Android接口定义语言。
那么实际上就跟接口回调一样。客户端拿到服务端的接口。然后操作。
本文结合项目中H5进程与主进程的通信进行梳理。主要有js调用接口后到主进程。还有h5监听到某种页面后，做一些通知处理
比如，如果发现url中有callback字样。则通知主进程发送一个eventbus。然后对应的地方接收进行操作，
第一步。写.aidl 文件。

文章图片
image.png 并在里面声明我们需要的方法。编译器会自动生成一个对应的.java文件。如下

文章图片
image.png 。
可以看到里面有一个抽象类Stub继承了Binder，并且实现了我们一开始.aidl的接口。那我们再写一个类来继承这个Stub。就可以作为实现类，类进行响应一些方法的调用。如下

文章图片
image.png
第二步。写主进程的服务端，用于客户端来连接

文章图片
image.png
Service有了然后就是binderService。连接服务，有个参数是ServiceConnection，然后回调方法onServiceConnected，方法连接后会返回一个IBinder对象。

文章图片
image.png 通过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 = https://www.it610.com/article/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启动的一个图

文章图片
image.png 总结
在重复几句。
通过asInterface，将服务端的binder传过来（service绑定后返回的，实际上是服务端binder的代理BinderPoxy），返回一个new Proxy（上面代码中proxy）。这个proxy就是服务端在客户端的代理了。因为这个代理里面把我们传过来的binder赋给了一个mRemote对象。所以我们在调用我们子进程的方法，比如

文章图片
image.png
比如调用mBInderManger的方法的时候。因为这个mBIndermanaer在asInterface时返回的就是上面这个proxy的对象。所以，就调用了proxy里面的queryBinder方法。

文章图片
image.png
然后如注释中说的。然后结合上面的图。会一层层最后调用了

文章图片
image.png
。应该是比较清楚了。客户端连接service。然后返回一个binder。客户端通过这个binder，拿到一个服务端的代理。然后客户端要进行操作了。直接调用对应的方法，该方法里直接调用了服务端（mRemote）的 transact方法。这就到了Binder里。binder又层层的深入到共享内存。然后回到了onTransact方法。该方法里调用了我们的具体实现类的对应方法。这里指的BinderManager（不要被名字迷惑，因为这个aidl恰好是管理本地不同aidl生成不同binder的。所以这么叫的一个类）。另外，这里Stub跟他的代理。因为他们都实现了同一个接口，此处是IBinderManager。所以代理。
【AIDL思路梳理】另外，刚才说的是子进程到主进程的通信。那么主进程如何通知子进程呢，也是通过AIDL。因为在子进程中我们已经拿到了主进程的Binder。所以，在这个binder的方法里，可以声明一个方法，把我们的aidl生成的类作为一个参数传过去，那这样主进程就拿到了子进程的binder。就可以随时回调了。
参考
彻底理解Android Binder通信架构
Android：学习AIDL，这一篇文章就够了(上)
android web模块独立进程的实现