Android AIDL流程学习

前言

本文主要讲述AIDL作用以及如何快速上手AIDL项目

简介

A [android] 
I [Interface] 
D [Definition] 
L [Language] 
Android接口定义语言。 
作用：方便系统为我们生成代码从而实现跨进程通讯，仅此而已。(玉刚老师如是说也)，也就是说这个AIDL就只是一个快速跨进程通讯的工具。

快速上手

本篇文章意在快速实现AIDL项目，更多详细内容下篇继续阐述。

• 在服务端创建AIDL文件，用来声明java Bean以及传输调用的接口。【声明文件】
• 在服务端创建Service并且实现上面的接口。【创建服务】
• 客户端绑定Service。【绑定服务】
• 客户端调用服务端接口。【跨进程调用】

服务端

创建服务端项目 
首先我们在app/src/main 目录下创建AIDL文件夹。

创建载体MessageBean

首先我们在这个AIDL文件夹里创建用来传输的java Bean对象（包名并不重要），并且实现Parcelable接口（建议使用Parcelable插件），因为进程间通讯需要将该对象转化为字节序列，用于传输或者存储。（传递的载体）

public class MessageBean implements Parcelable {
    private String content;//需求内容
    private int level;//重要等级

    ``````
    get set方法
    ``````

    @Override
    public int describeContents() {
        return 0;
    }

    @Override
    public void writeToParcel(Parcel dest, int flags) {
        dest.writeString(this.content);
        dest.writeInt(this.level);
    }

    //如果需要支持定向tag为out,inout，就要重写该方法
    public void readFromParcel(Parcel dest) {
        //注意，此处的读值顺序应当是和writeToParcel()方法中一致的
        this.content = dest.readString();
        this.level = dest.readInt();
    }
    protected MessageBean(Parcel in) {
        this.content = in.readString();
        this.level = in.readInt();
    }
    public MessageBean() {

    public static final Creator<MessageBean> CREATOR = new Creator<MessageBean>() {
        @Override
        public MessageBean createFromParcel(Parcel source) {
            return new MessageBean(source);
        }

        @Override
        public MessageBean[] newArray(int size) {
            return new MessageBean[size];
        }
    };
}
 
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

创建AIDL文件MessageBean.AIDL

因为AIDL这个语言的规范就是aidl文件，所以我们必须将MessageBean转为aidl文件，供其它aidl的调用与交互。就这么简单，一个文件里面两行代码。(这个文件要与java Bean放置同一包下)

package qdx.aidlserver;//手动导包
parcelable MessageBean;//parcelable是小写
 
1
2

AIDL文件与java文件的区别

• 文件类型：用AIDL书写的文件的后缀是 .aidl，而不是 .java。

• 数据类型：AIDL默认支持一些数据类型，在使用这些数据类型的时候是不需要导包的，但是除了这些类型之外的数据类型，在使用之前必须导包，就算目标文件与当前正在编写的 .aidl 文件在同一个包下——在 Java 中，这种情况是不需要导包的。比如，现在我们编写了两个文件，一个叫做 IDemandManager.java ，另一个叫做 IDemandManager.aidl，它们都在 qdx.aidlserver 包下 ，现在我们需要在 .aidl 文件里使用 MessageBean 对象，那么我们就必须在 .aidl 文件里面写上 import qdx.aidlserver.MessageBean; 哪怕 .java 文件和 .aidl 文件就在一个包下。

• 默认支持的数据类型 
  Java中的八种基本数据类型( byte，short(不支持short，编译不通过)，int，long，float，double，boolean，char) 
  String 和 CharSequence类型 
  List ： List中的所有元素必须是AIDL支持的类型之一，里面的每个元素都必须能够被AIDL支持 
  Map ： Map中的所有元素必须是AIDL支持的类型之一，包括key和value 
  Parcelabel : 所有实现了Parcelabel 接口的对象 
  AILD : 所有的AIDL接口本身也可以在AIDL文件中使用

创建AIDL文件IDemandManager.AIDL

我们创建IDemandManager接口用来实现传递方法。 
另外方法内如果有传输载体，就必须指明定向tag(in,out,inout)

• in : 客户端数据对象流向服务端，并且服务端对该数据对象的修改不会影响到客户端。
• out : 数据对象由服务端流向客户端，（客户端传递的数据对象此时服务端收到的对象内容为空，服务端可以对该数据对象修改，并传给客户端）
• inout : 以上两种数据流向的结合体。（但是不建议用此tag,会增加开销）

package qdx.aidlserver;

import qdx.aidlserver.MessageBean;
import qdx.aidlserver.IDemandListener;

interface IDemandManager {
     MessageBean getDemand();

     void setDemandIn(in MessageBean msg);//客户端->服务端

     //out和inout都需要重写MessageBean的readFromParcel方法
     void setDemandOut(out MessageBean msg);//服务端->客户端

     void setDemandInOut(inout MessageBean msg);//客户端<->服务端
}
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

埋坑与完善

该篇文章内容不多，但是处处皆是精华，尤其是以下3条建议，以防引起惨案。 
1. xxx.aidl 中不能存在同方法名不同参数的方法。 
2. xxx.aidl 中实体类必须要有指定的tag。 
3. 在Android Studio里写完aidl文件还需要在build.gradle文件中android{}方法内添加aidl路径。

sourceSets {
    main {
        java.srcDirs = ['src/main/java', 'src/main/aidl']
    }
}
 
1
2
3
4
5

创建Service

最后我们还需要创建一个服务，用来处理客户端发来的请求，或者是定时推信息到客户端。

public class AIDLService extends Service {

    @Override
    public IBinder onBind(Intent intent) {
        return demandManager;
    }

    //Stub内部继承Binder，具有跨进程传输能力
    IDemandManager.Stub demandManager = new IDemandManager.Stub() {
        @Override
        public MessageBean getDemand() throws RemoteException {
            MessageBean demand = new MessageBean("首先，看到我要敬礼", 1);
            return demand;
        }

        @Override
        public void setDemandIn(MessageBean msg) throws RemoteException {//客户端数据流向服务端
            Log.i(TAG, "程序员:" + msg.toString());
        }

        @Override
        public void setDemandOut(MessageBean msg) throws RemoteException {//服务端数据流向客户端
            Log.i(TAG, "程序员:" + msg.toString());//msg内容一定为空

            msg.setContent("我不想听解释，下班前把所有工作都搞好！");
            msg.setLevel(5);
        }

        @Override
        public void setDemandInOut(MessageBean msg) throws RemoteException {//数据互通
            Log.i(TAG, "程序员:" + msg.toString());

            msg.setContent("把用户交互颜色都改成粉色");
            msg.setLevel(3);
        }
    };
}
 
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
27
28
29
30
31
32
33
34
35
36
37

最后我们在清单文件中注册服务 
action 为服务名称，客户端可以通过此(com.tengxun.aidl)隐式启动该服务。 
在魅族的手机上，系统禁止了隐式方法启动服务的权限，所以务必在手机管家/权限管理/ 中，开启该项目的自启权限。

        <service
            android:name=".AIDLService"
            android:exported="true">
            <intent-filter>
                <action android:name="com.tengxun.aidl" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>

        </service>
 
1
2
3
4
5
6
7
8
9

客户端

创建客户端项目 

拷贝AIDL文件夹

将服务端创建的aidl文件夹拷贝至客户端app/src/main 目录下，并且在gradle.build中关联aidl路径。

    sourceSets {
        main {
            java.srcDirs = ['src/main/java', 'src/main/aidl']
        }
    }
 
1
2
3
4
5

开启服务

        Intent intent = new Intent();
        intent.setAction("com.tengxun.aidl");//service的action
        intent.setPackage("qdx.aidlserver");//aidl文件夹里面aidl文件的包名
        bindService(intent, connection, Context.BIND_AUTO_CREATE);
 
1
2
3
4

关联对象，调用方法

服务绑定成功之后，我们将服务端的IDemandManager.Stub对象，通过asInterface转化成为我们客户端需要的AIDL接口类型对象，并且这种转化过程是区分进程的（下篇详细叙述）。

    private IDemandManager demandManager;

    private ServiceConnection connection = new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            demandManager = IDemandManager.Stub.asInterface(service);//得到该对象之后，我们就可以用来进行进程间的方法调用和传输啦。
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {
        }
    };
 
1
2
3
4
5
6
7
8
9
10
11
12
13

至此我们就可以通过AIDL来进行跨进程通讯了。

附加技能（定时推送消息）

上面的步骤已经可以实现正常的跨进程通讯了，这时候如果我们想服务端项目想要定时推送消息到客户端项目，那么跨进程中如何完成呢? 
——————使用观察者模式(多个回调方法的集合)——————

服务端项目(推送消息)

与通常的回调方法差不多，首先我们在AIDL文件夹里创建回调接口IDemandListener.aidl 
但是这里的定向tag要稍加注意，可能有些童鞋觉得我们在服务端里给客户端发消息，照理不应该是设置out标记吗？ 
其实所谓的“服务端”和”客户端”在Binder通讯中是相对的，因为我们在客户端项目中拷贝了aidl文件，所以我们客户端项目其实不仅可以发送消息，充当”Client” 
，同时我们也可以收到服务端项目推送的消息，从而升级为”Server”，这个功能依赖于AIDL的Stub和Proxy……(更多见下篇) 
所以服务端onDemandReceiver推送消息的过程实际上相当于”Client”

package qdx.aidlserver;

import qdx.aidlserver.MessageBean;

interface IDemandListener {

     void onDemandReceiver(in MessageBean msg);//客户端->服务端

}
 
1
2
3
4
5
6
7
8
9

同时我们在IDemandManager.aidl文件中，加上绑定/解绑监听方法

     void registerListener(IDemandListener listener);

     void unregisterListener(IDemandListener listener);
 
1
2
3

最后Clean Project，在IDemandManager.Stub中多处绑定/解绑两个方法。

    IDemandManager.Stub demandManager = new IDemandManager.Stub() {
        ``````
        setDemandIn/out等方法
        ``````

        @Override
        public void registerListener(IDemandListener listener) throws RemoteException {
        }

        @Override
        public void unregisterListener(IDemandListener listener) throws RemoteException {

        }
    };

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

那么，关键的步骤来了，我们通常使用List<IDemandListener>来存放监听接口集合 
但是！ 
由于跨进程传输客户端的同一对象会在服务端生成不同的对象！ 
上面这句话说明跨进程通讯的过程中，这个传递的对象载体并不是像寄快递一样，从客户端传给服务端。而是经过中间人狸猫换太子的一些手段传递的。 
不过传递过程中间人(binder)对象都是同一个，所以Android通过这个特性提供RemoteCallbackList，让我们用来存储监听接口集合。 
这个RemoteCallbackList内部自动实现了线程同步的功能，而且它的本质是一个ArrayMap，所以我们用它来绑定/解绑时，不需要做额外的线程同步操作。

        private RemoteCallbackList<IDemandListener> demandList = new RemoteCallbackList<>();

        @Override
        public void registerListener(IDemandListener listener) throws RemoteException {
            demandList.register(listener);//
        }

        @Override
        public void unregisterListener(IDemandListener listener) throws RemoteException {
            demandList.unregister(listener);
        }
 
1
2
3
4
5
6
7
8
9
10
11

最后，我们通过Handler来进行定时发送消息。(handler并不能精准的做定时任务，因为handler在发送和接收的过程中会有时间损耗) 
另外我们需要通过beginBroadcast()来获取RemoteCallbackList中元素的个数，同时beginBroadcast()和finishBroadcast()必须要配对使用，哪怕仅仅只是获取一下这个集合的元素个数。

    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);

            if (demandList != null) {
                int nums = demandList.beginBroadcast();
                for (int i = 0; i < nums; i++) {
                    MessageBean messageBean = new MessageBean("我丢", count);
                    count++;
                    try {
                        demandList.getBroadcastItem(i).onDemandReceiver(messageBean);
                    } catch (RemoteException e) {
                        e.printStackTrace();
                    }
                }
                demandList.finishBroadcast();
            }

            mHandler.sendEmptyMessageDelayed(WHAT_MSG, 3000);//每3s推一次消息
        }
    };
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

客户端项目(接收定时推送)

在我们创建的客户端项目就不用过多的处理了，创建IDemandListener.Stub（此时我们这个客户端项目相对推送过程而言是”Server”），并且将它加入至demandManager即可。

    IDemandListener.Stub listener = new IDemandListener.Stub() {
        @Override
        public void onDemandReceiver(final MessageBean msg) throws RemoteException {
            //该方法运行在Binder线程池中，是非ui线程

        }
    };


    demandManager.registerListener(listener);
 
1
2
3
4
5
6
7
8
9
10

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

 
1
2
3
4
5
6
7
8

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

项目下载

http://download.youkuaiyun.com/download/qian520ao/9992461