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<yb.demo.myProcesses.useAIDL.dataModel.MusicData> 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<MusicData> 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()
判断当前进程是服务端进程还是客户端进程，如果是服务端进程则返回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<yb.demo.myProcesses.useAIDL.dataModel.MusicData> getMusicList() throws android.os.RemoteException { …… }
}
这里主要是为客户端提供接口代理，让客户端通过Binder机制，远程调用服务端实现的接口功能。
实现addMusic(MusicData)方法和getMusicList()方法
这两个方法由客户端发起请求，通常其内部实现是这样的：首先创建三个对象，_data用来存储这个方法的参数信息，按照参数顺序，逐个添加存储；_reply用来存储从服务端返回的数据；_result用来作为返回值返回，然后调用transact()方法发起RPC（远程过程调用）请求，调用服务端的onTransact()方法，同时当前线程挂起；当RPC过程返回后，当前线程继续执行，经过一系列处理后返回_result结果。
如getMusicList()
/**
* 获取数据列表接口
**/
@Override
public java.util.List<yb.demo.myProcesses.useAIDL.dataModel.MusicData> getMusicList() throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.util.List<yb.demo.myProcesses.useAIDL.dataModel.MusicData> _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;
}
当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以，一个远程方法不管是否耗时，最好是另起线程发起请求。
四、结语
经过前面的讲解，我们知道，基于Binder的数据通信流程大致如下：
基于Binder的数据通信流程图
- 1、客户端通过代理发起调用请求，并传入参数；
- 2、参数写入Data，通过transact()发起远程请求；
- 3、挂起线程，等待返回结果；
- 4、通过ServersManager，打通客户端与服务端；
- 5、回调onTransact()，从Data拿到参数，调用接口实现；
- 6、服务端实现处理，并且返回结果；
- 7、onTransact()拿到结果，写入Reply，并返回处理状态;
- 8、唤醒线程，transact()通过Reply拿到结果，并返回结果。
其实，感觉看完这节，还是对binder了解不足，于是，决定再继续写下去，下一节开始才是本系列的主角，正在准备资料中，写好马上给大家分享。
网友评论