Android 跨进程通信深入浅出AIDL（二）

前言

继上一篇AIDL的简单介绍，相信应该对AIDL有一个大致的了解，那么这一篇我们来深入探讨一下AIDL为什么能够完成这个跨进程操作，这其中是否隐藏着一些不为人知的秘密，让我们跟着笔者的思路，慢慢拨开笼罩在AIDL上的谜团。

概要

这里写图片描述
先用上图整体描述这个AIDL从客户端(Client)发起请求至服务端(Server)相应的工作流程，我们可以看出整体的核心就是Binder

解剖

asInterface

用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的【如果客户端和服务端位于同一进程，那么此方法返回的就是服务端的Stub对象本身，否则返回的是系统封装后的Stub.proxy对象】

    private ServiceConnection connection = new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {

            IDemandManager demandManager = IDemandManager.Stub.asInterface(service);
        }
    };

在ServiceConnection绑定服务的方法里，我们通过IDemandManager.Stub.asInterface(service)方法获得IDemandManager对象，我们跟着asInterface步伐看看里面有什么名堂。
PS : onServiceConnected方法的(IBinder)service参数在ActivityThread创建，他们之间还会扯出ActivityManagerService，ManagerService等，有兴趣的可以通过Activity 的启动过程加深功力，深入了解。

这里写图片描述

从上图的类结构图中我们可以看出，这个IDemandManager.aidl文件通过编译成为一个接口类，而这个类最核心的成员是Stub类和Stub的内部代理类Proxy。
顺着asInterface方法，结合上面对该方法的描述，可以看出通过DESCRIPTOR标识判断
如果是同一进程，那么就返回Stub对象本身(obj.queryLocalInterface(DESCRIPTOR))，否则如果是跨进程则返回Stub的代理内部类Proxy。
也就是说这个asInterface方法返回的是一个远程接口具备的能力（有什么方法可以调用），在我们项目里，asInterface的能力就是get/setDemand和注册/解绑监听接口。

asBinder

紧接着asInterface，我们看到一个简洁的方法asBinder

顾名思义，asBinder用于返回当前Binder对象。

//Stub
        @Override
        public android.os.IBinder asBinder() {
            return this;
        }

//Proxy
        private android.os.IBinder mRemote;

        @Override
        public android.os.IBinder asBinder() {
            return mRemote;
        }

根据代码我们可以追溯到，proxy的这个mRemote就是绑定服务(bindService)时候
由IDemandManager.Stub.asInterface(binder);传入的IBinder对象。

这个Binder对象具有跨进程能力，在Stub类里面（也就是本进程）直接就是Binder本地对象，在Proxy类里面返回的是远程代理对象(Binder代理对象)。[所以跨进程的谜团，会随着对Binder的分析和研究，逐渐变得清晰起来。]

因为我们这个编译生成的IDemandManager接口继承了android.os.IInterface接口,所以我们先分析IInterface接口。

public interface IDemandManager extends android.os.IInterface

IInterface

而这个IInterface接口就只声明了一个方法，但是Stub和Proxy都分别间接的实现了该接口。

/**
 * Base class for Binder interfaces.  When defining a new interface,
 * you must derive it from IInterface.
 */
public interface IInterface
{
    /**
     * Retrieve the Binder object associated with this interface.
     * You must use this instead of a plain cast, so that proxy objects
     * can return the correct result.
     */
    public IBinder asBinder();
}

Binder接口的基类。定义新接口时，
你必须实现IInterface接口。

检索与此界面关联的Binder对象。
你必须使用它而不是一个简单的转换
这样代理对象才可以返回正确的结果。

从上面的系统注释中我们可以理解出：

要声明(或者是手动diy创建)AIDL性质的接口，就要继承IInterface
代表远程server对象具有的能力，具体是由Binder表达出这个能力。

DESCRIPTOR

private static final java.lang.String DESCRIPTOR = "qdx.aidlserver.IDemandManager";//系统生成的

Binder的唯一标识，一般用当前Binder的类名表示。

onTransact(服务端接收)

我们发现IDemandManager接口，实际上并没有太多复杂的方法，看完了asInterface和asBinder方法，我们再来分析onTransact方法。

onTransact方法运行在服务端中的Binder线程池中
客户端发起跨进程请求时，远程请求会通过系统底层封装后交给此方法来处理。
如果此方法返回false,那么客户端的请求就会失败。

code : 确定客户端请求的目标方法是什么。（项目中的getDemand或者是setDemandIn方法）
data : 如果目标方法有参数的话，就从data取出目标方法所需的参数。
reply : 当目标方法执行完毕后，如果目标方法有返回值，就向reply中写入返回值。
flag : Additional operation flags. Either 0 for a normal RPC, or FLAG_ONEWAY for a one-way RPC.（暂时还没有发现用处，先标记上英文注释）

这里写图片描述

也就是说，这个onTransact方法就是服务端处理的核心，接收到客户端的请求，并且通过客户端携带的参数，执行完服务端的方法，返回结果。下面通过系统生成的代码，我们简要的分析一下onTransact方法里我们项目写的setDemandIn和setDemandOut方法。

                case TRANSACTION_setDemandIn: {
                    data.enforceInterface(DESCRIPTOR);
                    qdx.aidlserver.MessageBean _arg0;
                    if ((0 != data.readInt())) {
                        _arg0 = qdx.aidlserver.MessageBean.CREATOR.createFromParcel(data);
                    } else {
                        _arg0 = null;
                    }
                    this.setDemandIn(_arg0);
                    reply.writeNoException();
                    return true;
                }
                case TRANSACTION_setDemandOut: {
                    data.enforceInterface(DESCRIPTOR);
                    qdx.aidlserver.MessageBean _arg0;
                    _arg0 = new qdx.aidlserver.MessageBean();
                    this.setDemandOut(_arg0);
                    reply.writeNoException();
                    if ((_arg0 != null)) {
                        reply.writeInt(1);
                        _arg0.writeToParcel(reply,android.os.Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
                    } else {
                        reply.writeInt(0);
                    }
                    return true;
                }

此段代码并没有多少玄机，就是负责数据的读写，以及结果的返回。
但是有一个知识点可以在此验证，就是定向tag的作用，上面的方法定向tag分别是in和out，上篇文章介绍定向tag的作用就是跨进程中数据的流向，setDemandIn方法中我们可以看到我们读取了客户端传递过来的数据参数data，即客户端->服务端。out方法可以同理自行分析。AIDL中的in,out,inout分析

transact(客户端调用)

分析完了Stub，就剩下Stub的内部代理类Proxy
惊奇的发现Proxy类主要是用来方法调用，也就是用来客户端的跨进程调用。

这里写图片描述

transact方法运行在客户端，首先它创建该方法所需要的输入型Parcel对象_data、输出型Parcel对象_reply;
接着调用绑定服务传来的IBinder对象的transact方法来发起远程过程调用（RPC）请求，同时当前线程挂起;
然后服务端的onTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果，也就是返回_reply中的数据。

我们看到获得Parcel的方法为Parcel.obtain()，按照套路这个应该就是从Parcel池中获取该对象，减少创建对象的开支，跟进方法我们可以看得的确是创建了一个POOL_SIZE为6的池用来获取Parcel对象。
所以在跨进程通讯中Parcel是通讯的基本单元，传递载体。

而这个transact方法是一个本地方法，在native层中实现，功力不足，点到为止。
分析到了这里，感觉顿悟了许多，再一次引用开头概述的图片来看大概，整体的思路便浮在脑海中。so 哒死内~

这里写图片描述

总结

通过对AIDL的分析，我们发现原来这一切围绕着Binder有序的展开
AIDL通过Stub类用来接收并处理数据，Proxy代理类用来发送数据，而这两个类也只是通过对Binder的处理和调用，下一篇我们将深入摸清这个Binder究竟为何物，能够轻松游走于跨进程之中。

这里写图片描述

所以所谓的服务端和客户端，我们拆开看之后发现原来竟是不同类的处理

Stub充当服务端角色，持有Binder实体（本地对象）。

获取客户端传过来的数据，根据方法 ID 执行相应操作。
将传过来的数据取出来，调用本地写好的对应方法。
将需要回传的数据写入 reply 流，传回客户端。

Proxy代理类充当客户端角色，持有Binder引用（句柄）。

生成 _data 和 _reply 数据流，并向 _data 中存入客户端的数据。
通过 transact() 方法将它们传递给服务端，并请求服务端调用指定方法。
接收 _reply 数据流，并从中取出服务端传回来的数据。

而且所谓的服务端和客户端都是相对而言的，服务端不仅可以接收和处理消息，而且可以定时往客户端发送数据，与此同时服务端使用Proxy类跨进程调用，相当于充当了”Client”。
并且有一点要理解是，跨进程通讯的时候，传递的数据对象并不是从进程A原原本本的发给进程B。库克说要送你苹果，而你收到的iphone X就真的是美国生产的吗？不，它也可能是made in China.

终上所述，AIDl这个工具就已经分析结束，如果文中有不足之处还望指出。如果有什么更好的见解也可以留言，最终的目标都是共同进步。有兴趣的可以继续看Android Binder之应用层总结与分析。

AIDL文章借鉴（上）
AIDL文章借鉴（下）
最后感谢《Android 开发艺术探索》专业的分析。

来源：oschina

链接：https://my.oschina.net/u/1771562/blog/1553706

标签

binder