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 = 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。因为在子进程中我们已经拿到了主进程的Binder。所以，在这个binder的方法里，可以声明一个方法，把我们的aidl生成的类作为一个参数传过去，那这样主进程就拿到了子进程的binder。就可以随时回调了。

参考

彻底理解Android Binder通信架构
Android：学习AIDL，这一篇文章就够了(上)
android web模块独立进程的实现