Android夸进程通信机制系列：
Android夸进程通信机制一：多进程简介
Android夸进程通信机制二：Parcel 与 Parcelable
Android夸进程通信机制三：Messenger与Message
Android夸进程通信机制四：使用 Bundle进行进程间通信
Android夸进程通信机制五：使用文件共享进行进程间通信
Android夸进程通信机制六：使用ContentProvider进行进程间通信
Android夸进程通信机制七：使用 Socket进行进程间通信
Android夸进程通信机制八：使用 AIDL进行进程间通信
Android夸进程通信机制九：AIDL深入了解
...

一、前言

前面一节一节讲述了，如何运用AIDL进行跨进程通信，这章本来想讲一下binder的原理，但是，感觉AIDL还是存在不少懵懂的地方，故，先深入AIDL，再来讲Binder。

结合前一节，讲使用AIDL的例子，我们将通过AIDL的方式将一个MusicData实体类的对象在服务端和客户端之间互相传递。

二、使用AIDL进行跨进程通信

我们来重温一下使用AIDL进行跨进程通信的步骤

1、创建数据实体类——MusicData（序列化）；
2、创建数据实体类的映射AIDL文件——MusicData.aidl（要和声明的实体类在一个包里）；
3、添加AIDL接口描述文件——IUseAidlInterface.aidl（注意包名、类名、文件名）；
4、编译生成Binder 的 Java 文件——IUseAidlInterface.java；
5、服务端实现IUseAidlInterface.Stub()，并向客户端返回IBinder;
6、客户端绑定服务端，实现ServiceConnection，拿到IBinder进行跨进程调用。

这样就可以使用AIDL在进程间进行通信了，详见Android夸进程通信机制八：使用 AIDL进行进程间通信。

三、IUseAidlInterface.java

在步骤4中，编译完成后，会在以下名目录下生成一个IUseAidlInterface.java文件

build/generated/aidl_source_output_dir/debug/compileDebugAidl/out/你的aidl包名/

这个类是系统根据我们编写的IUseAidlInterface.aidl文件自动生成的Binder类。

1、IUseAidlInterface结构分析

这个类的代码结构如下：

/* * This file is auto-generated.  DO NOT MODIFY. * Original file: /Users/yufenfen/workspace/android/YuFFDemo/app/src/main/aidl/yb/demo/myProcesses/useAIDL/IUseAidlInterface.aidl */package yb.demo.myProcesses.useAIDL;public interface IUseAidlInterface extends android.os.IInterface {    /**     * Local-side IPC implementation stub class.     */    public static abstract class Stub extends android.os.Binder implements yb.demo.myProcesses.useAIDL.IUseAidlInterface{……}    /**     * 根据需求，新添加，MusicData要实现Parcelable接口，并且要添加对应的Aidl映射文件     * 提交数据接口     **/    public void addMusic(yb.demo.myProcesses.useAIDL.dataModel.MusicData data) throws android.os.RemoteException;    /**     * 获取数据列表接口     **/    public java.util.List getMusicList() throws android.os.RemoteException;}

这里，结构由三部分Stub、addMusic 和 getMusicList组成，可以看出：

IUseAidlInterface是个接口，继承 android.os.IInterface，并且新加了自己的接口 addMusic 和 getMusicList。

新增的两个接口就是在Aidl接口描述文件中的那两个，也就是说，我们在我们在Aidl接口描述文件中添加的接口都会在这里自动地生成。

加上android.os.IInterface的唯一接口 asBinder()，如果要

implements yb.demo.myProcesses.useAIDL.IUseAidlInterface

则需要在实现处实现三个接口： addMusic 、 getMusicList 和asBinder()。

静态抽象内部类Stub，通过这个内部类，把所有的AIDL细节都包装起来。

Stub是个抽象类，它只实现了 asBinder()，而接口 addMusic 和 getMusicList则留给具体实现处实现，这样，我们的服务端就可以无需关心AIDL的内部细节，只需要实现目标功能接口即可完成跨进程通信。
见服务端：

    IBinder mIBinder = new IUseAidlInterface.Stub() {        @Override        public void addMusic(MusicData data) throws RemoteException {            mData.add(data);        }        @Override        public List getMusicList() throws RemoteException {            return mData;        }    };

四、Binder

继续前面的结构，先来看一下Stub的内部组成

    /**     * Local-side IPC implementation stub class.     */    public static abstract class Stub extends android.os.Binder implements yb.demo.myProcesses.useAIDL.IUseAidlInterface {        private static final java.lang.String DESCRIPTOR = "yb.demo.myProcesses.useAIDL.IUseAidlInterface";        /**         * Construct the stub at attach it to the interface.         */        public Stub() { this.attachInterface(this, DESCRIPTOR); }        /**         * Cast an IBinder object into an yb.demo.myProcesses.useAIDL.IUseAidlInterface interface,         * generating a proxy if needed.         */        public static yb.demo.myProcesses.useAIDL.IUseAidlInterface asInterface(android.os.IBinder obj) {……}        @Override        public android.os.IBinder asBinder() { return this; }        @Override        public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException { …… }        private static class Proxy implements yb.demo.myProcesses.useAIDL.IUseAidlInterface { …… }        static final int TRANSACTION_addMusic = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);        static final int TRANSACTION_getMusicList = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);    }

Stub继承Binder，由此可见，这一块就是AIDLDE 核心部分了，先看一下Binder的描述：

Base class for a remotable object, the core part of a lightweight remote procedure call mechanism defined by IBinder.

远程对象的基类，IBinder定义的轻量级远程过程调用机制的核心部分。它是IBinder的一个实现，它提供了这样一个对象的标准本地实现。

那么，我们就从抽象静态内部类Stub入手，一起分析一下Binder。

1、结构元素的简述

Stub结构元素如下：

stub()： Construct the stub at attach it to the interface.
asInterface()：Cast an IBinder object into an IUseAidlInterface interface, generating a proxy if needed.
asBinder()：返回当前的Binder对象；
onTransact(int code, Parcel data, Parcel reply, int flag)：这个方法运行在服务端的Binder线程池中，当客户端发起请求时，就由这个方法来处理请求;
DESCRIPTOR：Binder的唯一标识，一般用当前Binder的包路径表示；
TRANSACTION_addMusic：一个整形的ID，用于表示客户端请求的是哪个方法；
TRANSACTION_getMusicList：一个整形的ID，用于表示客户端请求的是哪个方法；
Proxy: 为客户端提供代理。

我们先对结构元素作简单的描述，有个整体的了解，下面再对关键部分详细讲解。

1.1、asInterface()

用于将服务器端的Binder对象装换成客户端所需要的AIDL接口类型的对象，这里是区分进程的，如果客户端和服务端位于同一进程，那么这里返回的是服务端的Stub对象本身，否则返回的是系统封装后的Stub.Proxy对象；

1.2、asBinder()

上面提到Stub虽然实现了接口IUseAidlInterface，但只实现了其中的asBinder()，我们先看一下IInterface：

package android.os;/** * 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();}

IInterface是Binder接口的基类。定义新接口时，您必须继承它。
IInterface只定义了一个接口asBinder()，它对外提供与此接口关联的Binder对象。输出Binder对象必须使用这种方法而不是简单的强制转换，这样代理对象才能返回正确的结果。

1.3 onTransact(int code, Parcel data, Parcel reply, int flag)

当客户端调用代理的相关接口时，Binder机制会回调此方法，它通过code知道客户端想要访问在服务端实现的目标方法；通过data来获取目标方法所需的参数；执行完目标方法后，将返回值写入到reply中。另外，如果这个方法返回false，则客户端请求失败，我们可以通过这一点来判断客户端是否有权访问我们的服务；

2、内部类Proxy

Proxy是Stub的内部静态类，它实现了接口IUseAidlInterface，AIDL提供给客户端的代理。

    public static abstract class Proxy implements yb.demo.myProcesses.useAIDL.IUseAidlInterface {        private android.os.IBinder mRemote;                    Proxy(android.os.IBinder remote) { mRemote = remote; }        @Override        public android.os.IBinder asBinder() { return this; }        public java.lang.String getInterfaceDescriptor() { return DESCRIPTOR; }        /**         * 根据需求，新添加，MusicData要实现Parcelable接口，并且要添加对应的Aidl映射文件         * 提交数据接口         **/        @Override        public void addMusic(yb.demo.myProcesses.useAIDL.dataModel.MusicData data) throws android.os.RemoteException {……}        /**         * 获取数据列表接口         **/        @Override        public java.util.List getMusicList() throws android.os.RemoteException { …… }}

这里主要是为客户端提供接口代理，让客户端通过Binder机制，远程调用服务端实现的接口功能。

实现addMusic(MusicData)方法和getMusicList()方法

这两个方法由客户端发起请求，通常其内部实现是这样的：首先创建三个对象，_data用来存储这个方法的参数信息，按照参数顺序，逐个添加存储；_reply用来存储从服务端返回的数据；_result用来作为返回值返回，然后调用transact()方法发起RPC（远程过程调用）请求，调用服务端的onTransact()方法，同时当前线程挂起；当RPC过程返回后，当前线程继续执行，经过一系列处理后返回_result结果。
如getMusicList()

/**  * 获取数据列表接口  **/  @Override  public java.util.List getMusicList() throws android.os.RemoteException {    android.os.Parcel _data = android.os.Parcel.obtain();    android.os.Parcel _reply = android.os.Parcel.obtain();    java.util.List _result;      try {        _data.writeInterfaceToken(DESCRIPTOR);                    mRemote.transact(Stub.TRANSACTION_getMusicList, _data, _reply, 0);        _reply.readException();        _result = _reply.createTypedArrayList(yb.demo.myProcesses.useAIDL.dataModel.MusicData.CREATOR);      } finally {         _reply.recycle();        _data.recycle();      }      return _result;    }

当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以，一个远程方法不管是否耗时，最好是另起线程发起请求。
另外，由于服务器端的Binde方法运行在Binder线程池中，故Binder方法不管是否耗时，都应该采用同步方式实现，因为他已经运行在一个线程中。

四、结语

经过前面的讲解，我们知道，基于Binder的数据通信流程大致如下：

基于Binder的数据通信流程图

1、客户端通过代理发起调用请求，并传入参数；
2、参数写入Data，通过transact()发起远程请求；
3、挂起线程，等待返回结果；
4、通过ServersManager，打通客户端与服务端；
5、回调onTransact()，从Data拿到参数，调用接口实现；
6、服务端实现处理，并且返回结果；
7、onTransact()拿到结果，写入Reply，并返回处理状态;
8、唤醒线程，transact()通过Reply拿到结果，并返回结果。

其实，感觉看完这节，还是对binder了解不足，于是，决定再继续写下去，下一节开始才是本系列的主角，正在准备资料中，写好马上给大家分享。

Android夸进程通信机制九：AIDL深入了解