Android 深入浅出AIDL（二）

*本篇文章已授权微信公众号 guolin_blog （郭霖）独家发布

文章目录

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

前言

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

概要

Android 深入浅出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 的启动过程加深功力，深入了解。

Android 深入浅出AIDL（二）

从上图的类结构图中我们可以看出，这个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

接口。

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

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.（暂时还没有发现用处，先标记上英文注释）

Android 深入浅出AIDL（二）

也就是说，这个

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类主要是用来方法调用，也就是用来客户端的跨进程调用。

Android 深入浅出AIDL（二）

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 哒死内~

Android 深入浅出AIDL（二）

总结

通过对AIDL的分析，我们发现原来这一切围绕着Binder有序的展开

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

Android 深入浅出AIDL（二）

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

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 开发艺术探索》专业的分析。

Android 深入浅出AIDL（二）

文章目录

前言

概要

解剖

asInterface

asBinder

IInterface

DESCRIPTOR

onTransact(服务端接收)

transact(客户端调用)

总结

继续阅读

专访邓凡平：深入理解Android

与专家面对面：Android开发入门问与答

Android MVP架构MVCMVP

mvp初探

Android常用工具类简介目录

android常用工具类转载自：http://www.trinea.cn/android/android-common-utils/Android常用工具类

Android常用工具类ToastUtilsSizeUtilsLogUtilsRetrofitManagerAnimUtil

Android Studio 0.8.0解决 Failure [INSTALL_FAILED_OLDER_SDK] 问题

Android – ListView 中添加按钮，动态删除添加ItemView的操作

Kotlin的ListView与RecyclerView的简单应用

关于公司的那些坑：Android Studio篇

android SQLite事务和kotlin协程

无法正常编译错误Compilation failed to complete

关于Gradle配置的小结

AOP编程_Android优雅权限框架(1)概念基础，2021金三银四前言正文大纲正文

Android APK文件反编译Android APK文件反编译