Android 深入浅出AIDL(二)

4,702 阅读7分钟

前言

上一篇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步伐看看里面有什么名堂。


这里写图片描述

从上图的类结构图中我们可以看出,这个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对象。
你必须使用它而不是一个简单的转换
这样代理对象才可以返回正确的结果。

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

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

DESCRIPTOR

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

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

onTransact(服务端接收)

我们发现IDemandManager接口,实际上并没有太多复杂的方法,看完了asInterfaceasBinder方法,我们再来分析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方法里我们项目写的setDemandInsetDemandOut方法。

                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是通讯的基本单元,传递载体。
而这个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 开发艺术探索》专业的分析。