Android 跨进程通讯 深刻浅出AIDL（二）

• • 前言
  • 概要
  • 解剖
    • asInterface
    • asBinder
    • IInterface
    • DESCRIPTOR
    • onTransact服务端接收
    • transact客户端调用
  • 总结

 

前言

继上一篇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;
        }

• 1
• 2
• 3
• 4
• 5

//Proxy
        private android.os.IBinder mRemote;

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

• 1
• 2
• 3
• 4
• 5
• 6
• 7

根据代码咱们能够追溯到，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

• 1

 

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();
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

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

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

从上面的系统注释中咱们能够理解出：

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

 

DESCRIPTOR

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

• 1

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;
                }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26

此段代码并无多少玄机，就是负责数据的读写，以及结果的返回。 
可是有一个知识点能够在此验证，就是定向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 开发艺术探索》专业的分析。