AIDL与其他IDL语言类似，你需要做一些工作。 它允许你定义客户端与服务端达成一致的程序接口使用进程间通信相互交流。 在ANdroid上面，一个进程不能正常的访问另一个进程的内存。 所以说，他们需要分解他们的对象为操作系统可以理解的基本单位，然后为你把这些对象按次序跨越进程边界 书写这些代码是单调冗长的，所以android使用AIDL为你处理这个问题。
注意：使用AIDL只有在你允许来自不同应用的客户端跨进程通信访问你的service，并且想要在你的service种处理多线程的时候才是必要的。 如果你不需要执行不同应用之间的IPC并发，你应该通过实现Binder建立你的接口，或者如果你想执行IPC，但是不需要处理多线程。那么使用Messenger实现你的接口 不管怎样，确保你在实现一个AIDL之前理解了Bound Service
在你设计你的AIDL接口之前，请注意调用一个AIDL接口是直接的函数调用 你不应该假设线程在哪个调用中发生 情形与依赖调用是来自一个本地进程中的线程还是一个远程进程中的线程相关 尤其是：
- 来自本地进程的调用与调用者在同一个线程中执行。 如果这是你的主UI线程，线程继续在AIDL接口中执行 如果是其他的线程，则它是一个在service中执行你的代码的线程 这样，如果只是本地线程访问这个service，你完全可以控制哪些线程在其中执行（但是如果是那样的话，那么你压根就不应该使用AIDL，而应该通过实现Binder建立接口）
- 平台在你自己的进程中内部维护一个线程池中分配的远程进程的调用 你必须为从未知线程发出的即将到来的调用，并且是伴随同时多个调用做好准备 换句话说，AIDL接口的实现必须是完全的线程安全的
- 单向关键词限定了远程调用的行为 使用的时候，一个远程调用不会被阻塞；它只是简单的发送传输数据并且立即返回 最终接口的实现把它作为一个来自Binder线程池的常规调用、一个普通的远程调用来接收 如果本地调用使用单向的，那么就不会有影响，并且调用仍然是异步的
定义一个AIDL接口
你必须在一个.aidl文件中使用java编程语言语法定义你的AIDL接口，然后在提供service的应用中和任何绑定到这个service的应用中的源代码中（在src目录吓）保存它
当你编译包含.aidl文件的应用时，Android SDK工具基于这个.aidl文件生成一个IBinder接口，并且把它保存到项目的gen目录吓 service必须恰当的实现这个IBinder接口 之后客户端应用可以绑定到这个服务上，然后从IBinder调用方法来执行IPC
使用AIDL建立一个邻接的service需要遵循下面的步骤
- 1.建立.aidl文件
这个文件使用方法签名定义了语言接口
- 2.实现这个接口
Android SDk工具基于你的.aidl文件使用java语言生成一个接口 这个接口有一个内部抽象类，叫做Stub，它是继承Binder并且实现你AIDL接口的 你必须继承这个Stub类并且实现这些方法
- 3.暴露这个接口给客户端
实现一个service并且覆盖onBind()方法返回你的Stub实现类
警告：在你第一次发布AIDL之后的其中任何的改变必须保持向后兼容来避免破坏其他应用程序使用你的service 也就是说，因为你的.aidl文件必须被复制到其他应用程序中来让他们访问你service的接口，你必须维护原始接口的支持。
1.建立.aidl文件
AIDL使用一个简单的语法让你声明一个带有一个或者多个带有参数和返回值方法的接口 参数和返回值可以是任何类型，甚至是AIDL生成的接口
你必须使用java语言构建.aidl文件 每一个.aidl文件必须定义一个简单的接口并且要求只有接口声明和方法签名
默认的，AIDL支持下面数据类型：
- ava语言中的所有基本数据类型（比如int、long、char、boolean等等）
StringCharSequenceListList中的所有元素必须是AIDL支持的类型之一，或者是一个其他AIDL生成的接口，或者是你定义的parcelable List可以使用范型（例如，List
） 接收端的实际类经常是一个ArrayList，尽管方法是使用List接口生成的 MapMap中的所有元素必须是AIDL支持的类型之一，或者是一个其他AIDL生成的接口，或者是你定义的parcelable 范型map是不被支持的（比如这种形式Map
对于上述类型之外的类型，你必须声明 import ，即使在同一个包内。
当定义你的service接口的时候，注意：
- 方法可以接收0或多个参数，并且有返回值或者返回void
- 所有非基本数据类型要求要求一个定向的tag来指定数据是去往哪个方向的
无论是输入、输出，还是输入输出（参加下面的例子）
基本数据类型是默认支持的，并且不能是其他的。
警告：你应该限制方向于真正需要的地方，因为排列整理参数的开销是很昂贵的。
- .aidl文件中的所有的代码注释都在生成的IBinder接口中（除了在import和包声明之前的注释）
- 只支持方法，你不可以在AIDL暴露静态域
这有个.aidl文件的例子：
// IRemoteService.aidl
package com.example.android;
// Declare any non-default types here with import statements
/** Example service interface */
interface IRemoteService {
/** Request the process ID of this service, to do evil things with it. */
int getPid();
/** Demonstrates some basic types that you can use as parameters
* and return values in AIDL.
*/
void basicTypes(int anInt, long aLong, boolean aBoolean, float aFloat,
double aDouble, String aString);
}
简单的保存你的.aidl文件在你工程的src目录下，当你build你的应用时，SDK工具在你工程的gen目录下生成IBinder接口文件 生成的文件名字与.aidl名字匹配，但是是以.java为扩展名（例如IRemoteService.aidl对应为IRemoteService.java）
如果你使用Eclipse，增量编译几乎是立刻生成binder类。如果你不使用Eclipse，那么Ant工具在你下次编译你的应用（你应该使用ant debug或者ant release编译你的工程）时生成binder类。一旦你写好了.aidl文件，你的代码就可以链接到生成的类上面了。
2.实现接口
当你编译你的应用时，Android SDK工具生成一个.java接口文件用你的.aidl文件命名 生成的接口包含一个名字为Stub的子类（比如YourInterface.Stub），这是一个它父类的抽象实现，并且声明了.aidl中所有的方法
注意：Stub也定义了一些辅助的方法，最显著的就是asInterface()，它是用来接收一个IBinder（通常IBinder传递给客户端的onServiceConnected()回调方法）并且返回一个Stub接口的实例 更多细节参考Calling an IPC Method章节。
为了实现来自.aidl文件生成的接口，需要继承Binder接口（例如YourInterface.Stub）并且实现从.aidl文件中继承的方法。
这有一个使用匿名实例实现一个叫IRemoteService（定义在IRemoteService.aidl中，例子如上）的接口的例子
private final IRemoteService.Stub mBinder = new IRemoteService.Stub() {
public int getPid(){
return Process.myPid();
}
public void basicTypes(int anInt, long aLong, boolean aBoolean,
float aFloat, double aDouble, String aString) {
// Does nothing
}
};
mBinder是一个Stub类的实例
当实现你的AIDL接口的时候有很多规则需要注意
- 调用不保证在主线程中执行，所以你需要一开始就考虑多线程并且适当的build你的service为线程安全的
- 默认的，RPC调用是同步的。 如果你知道service需要花费一些时间来完成请求，你就不应该从activity的主线程中调用它，因为它可能使得应用没有响应（Android也许会显示一个ANR的对话框），通常你应该在客户端中一个单独的线程调用它
- 抛出的异常不会返回给调用者
3.暴露接口给客户端
一旦你为service实现了接口，你需要把它暴露给客户端，这样他们才能绑定到上面 为了给你的service暴露接口，继承Service并且实现onBind()方法返回一个你实现生成的Stub类（像我们在上一结讨论的那样） 这有一个service暴露IRemoteService接口给客户端的例子
public class RemoteService extends Service {
@Override
public void onCreate() {
super.onCreate();
}
@Override
public IBinder onBind(Intent intent) {
// Return the interface
return mBinder;
}
private final IRemoteService.Stub mBinder = new IRemoteService.Stub() {
public int getPid(){
return Process.myPid();
}
public void basicTypes(int anInt, long aLong, boolean aBoolean,
float aFloat, double aDouble, String aString) {
// Does nothing
}
};
}
现在，当一个客户端（比如一个activity）调用bindService()来连接到这个service，这个客户端的onServiceConnected()回调函数接收service中onBind()方法返回的mBinder实例
客户端必须可以访问接口类，所以如果客户端和服务端在不同的应用中，那么客户端所在的应用必须有一份.aidl文件的副本在其src目录下（生成android.os.Binder接口，提供客户端访问AIDL方法都在这个目录下）
当客户端在onServiceConnected()回调方法中接收到IBinder时，它必须调用你的ServiceInterface.Stub.asInterface(service)来把返回参数映射到你的ServiceInterface类型上。例如：
IRemoteService mIRemoteService;
private ServiceConnection mConnection = new ServiceConnection() {
// Called when the connection with the service is established
public void onServiceConnected(ComponentName className, IBinder service) {
// Following the example above for an AIDL interface,
// this gets an instance of the IRemoteInterface, which we can use to call on the service
mIRemoteService = IRemoteService.Stub.asInterface(service);
}
// Called when the connection with the service disconnects unexpectedly
public void onServiceDisconnected(ComponentName className) {
Log.e(TAG, "Service has unexpectedly disconnected");
mIRemoteService = null;
}
};
更多样本代码参见ApiDemos中的RemoteService.java
跨进程传递对象
如果你想通过IPC接口把一个类从一个进程传递到另一个进程中，那么是可以的。 然而，你必须保证为你的类而写的代码也是对IPC通道另一端是可用的，并且你的类必须支持Parcelable接口 支持Parcelable接口是很重要的，因为它允许Android系统把对象分解为可以被组织跨进程传输基本单元
为了建立一个支持Parcelable协议的类，你必须遵守下面的规则：
- 要实现Parcelable接口
- 实现writeToParcel，它是用来把对象的当前状态写入到一个Parcel对象中的。
- 在你的类中添加一个叫CREATOR的静态域，它要实现Parcelable.Creator接口
- 最后，建立一个.aidl文件声明你的parcelable类（如下面的Rect.aidl所示）
如果你使用一个定制的构建过程，不要构建.aidl文件。与C语言中的头文件类似，.aidl文件不会被编译
AIDL使用代码中的这些域和方法封装传送和解读你的对象
例如，这有一个Rect.aidl文件类建立一个Rect类，它是parcelable的
package android.graphics; // Declare Rect so AIDL can find it and knows that it implements // the parcelable protocol. parcelable Rect;
这有一个Rect类如何实现Parcelable协议的例子
import android.os.Parcel;
import android.os.Parcelable;
public final class Rect implements Parcelable {
public int left;
public int top;
public int right;
public int bottom;
public static final Parcelable.Creator<Rect> CREATOR = new
Parcelable.Creator<Rect>() {
public Rect createFromParcel(Parcel in) {
return new Rect(in);
}
public Rect[] newArray(int size) {
return new Rect[size];
}
};
public Rect() {
}
private Rect(Parcel in) {
readFromParcel(in);
}
public void writeToParcel(Parcel out) {
out.writeInt(left);
out.writeInt(top);
out.writeInt(right);
out.writeInt(bottom);
}
public void readFromParcel(Parcel in) {
left = in.readInt();
top = in.readInt();
right = in.readInt();
bottom = in.readInt();
}
}
在Rect类中组织传送数据是很简单的 看一下Parcel上面的其他函数，看看你可以如何将其他类型的值写入一个Parcel中。
警告：不要忘记从其他进程接收数据的安全本质性 这种情况下，Rect从Parcel中读取4个数字，但是这取决于你要保证他们在可接收范围之内而不管调用者到底试图要做些什么 获取更多关于如何远离恶意程序保证你应用安全的更多信息，参见Security and Permissions
调用一个IPC方法
下面是调用步骤，调用者必须调用一个AIDL定义的远程接口
- 在项目中的src目录下面导入.aidl文件
- 声明一个IBinder接口（基于AIDL生成的）的实例
- 实现ServiceConnection
- 调用Context.bindService()，传递到你的ServiceConnection实现中。
- 在你的onServiceConnected()实现中，你会收到一个IBinder实例（称为服务端） 调用YourInterfaceName.Stub.asInterface((IBinder)service)把返回值映射到YourInterface类型上面
- 调用你接口中定义的方法 你应该捕获当连接损坏时抛出的DeadObjectException异常，这是远程方法唯一会抛出的异常
- 使用你接口的实例调用Context.unbindService()来断开连接
调用IPC服务端的一些注释：
- 对象跨进程时是引用计数的
- 你可以传递一个匿名对象作为方法的参数
更多绑定service的信息请阅读Bound Services文档
调用一个AIDL建立的服务端的一些样本代码，来自ApiDemos工程中的Remote Service样本。
public static class Binding extends Activity {
/** The primary interface we will be calling on the service. */
IRemoteService mService = null;
/** Another interface we use on the service. */
ISecondary mSecondaryService = null;
Button mKillButton;
TextView mCallbackText;
private boolean mIsBound;
/**
* Standard initialization of this activity. Set up the UI, then wait
* for the user to poke it before doing anything.
*/
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.remote_service_binding);
// Watch for button clicks.
Button button = (Button)findViewById(R.id.bind);
button.setOnClickListener(mBindListener);
button = (Button)findViewById(R.id.unbind);
button.setOnClickListener(mUnbindListener);
mKillButton = (Button)findViewById(R.id.kill);
mKillButton.setOnClickListener(mKillListener);
mKillButton.setEnabled(false);
mCallbackText = (TextView)findViewById(R.id.callback);
mCallbackText.setText("Not attached.");
}
/**
* Class for interacting with the main interface of the service.
*/
private ServiceConnection mConnection = new ServiceConnection() {
public void onServiceConnected(ComponentName className,
IBinder service) {
// This is called when the connection with the service has been
// established, giving us the service object we can use to
// interact with the service. We are communicating with our
// service through an IDL interface, so get a client-side
// representation of that from the raw service object.
mService = IRemoteService.Stub.asInterface(service);
mKillButton.setEnabled(true);
mCallbackText.setText("Attached.");
// We want to monitor the service for as long as we are
// connected to it.
try {
mService.registerCallback(mCallback);
} catch (RemoteException e) {
// In this case the service has crashed before we could even
// do anything with it; we can count on soon being
// disconnected (and then reconnected if it can be restarted)
// so there is no need to do anything here.
}
// As part of the sample, tell the user what happened.
Toast.makeText(Binding.this, R.string.remote_service_connected,
Toast.LENGTH_SHORT).show();
}
public void onServiceDisconnected(ComponentName className) {
// This is called when the connection with the service has been
// unexpectedly disconnected -- that is, its process crashed.
mService = null;
mKillButton.setEnabled(false);
mCallbackText.setText("Disconnected.");
// As part of the sample, tell the user what happened.
Toast.makeText(Binding.this, R.string.remote_service_disconnected,
Toast.LENGTH_SHORT).show();
}
};
/**
* Class for interacting with the secondary interface of the service.
*/
private ServiceConnection mSecondaryConnection = new ServiceConnection() {
public void onServiceConnected(ComponentName className,
IBinder service) {
// Connecting to a secondary interface is the same as any
// other interface.
mSecondaryService = ISecondary.Stub.asInterface(service);
mKillButton.setEnabled(true);
}
public void onServiceDisconnected(ComponentName className) {
mSecondaryService = null;
mKillButton.setEnabled(false);
}
};
private OnClickListener mBindListener = new OnClickListener() {
public void onClick(View v) {
// Establish a couple connections with the service, binding
// by interface names. This allows other applications to be
// installed that replace the remote service by implementing
// the same interface.
bindService(new Intent(IRemoteService.class.getName()),
mConnection, Context.BIND_AUTO_CREATE);
bindService(new Intent(ISecondary.class.getName()),
mSecondaryConnection, Context.BIND_AUTO_CREATE);
mIsBound = true;
mCallbackText.setText("Binding.");
}
};
private OnClickListener mUnbindListener = new OnClickListener() {
public void onClick(View v) {
if (mIsBound) {
// If we have received the service, and hence registered with
// it, then now is the time to unregister.
if (mService != null) {
try {
mService.unregisterCallback(mCallback);
} catch (RemoteException e) {
// There is nothing special we need to do if the service
// has crashed.
}
}
// Detach our existing connection.
unbindService(mConnection);
unbindService(mSecondaryConnection);
mKillButton.setEnabled(false);
mIsBound = false;
mCallbackText.setText("Unbinding.");
}
}
};
private OnClickListener mKillListener = new OnClickListener() {
public void onClick(View v) {
// To kill the process hosting our service, we need to know its
// PID. Conveniently our service has a call that will return
// to us that information.
if (mSecondaryService != null) {
try {
int pid = mSecondaryService.getPid();
// Note that, though this API allows us to request to
// kill any process based on its PID, the kernel will
// still impose standard restrictions on which PIDs you
// are actually able to kill. Typically this means only
// the process running your application and any additional
// processes created by that app as shown here; packages
// sharing a common UID will also be able to kill each
// other's processes.
Process.killProcess(pid);
mCallbackText.setText("Killed service process.");
} catch (RemoteException ex) {
// Recover gracefully from the process hosting the
// server dying.
// Just for purposes of the sample, put up a notification.
Toast.makeText(Binding.this,
R.string.remote_call_failed,
Toast.LENGTH_SHORT).show();
}
}
}
};
// ----------------------------------------------------------------------
// Code showing how to deal with callbacks.
// ----------------------------------------------------------------------
/**
* This implementation is used to receive callbacks from the remote
* service.
*/
private IRemoteServiceCallback mCallback = new IRemoteServiceCallback.Stub() {
/**
* This is called by the remote service regularly to tell us about
* new values. Note that IPC calls are dispatched through a thread
* pool running in each process, so the code executing here will
* NOT be running in our main thread like most other things -- so,
* to update the UI, we need to use a Handler to hop over there.
*/
public void valueChanged(int value) {
mHandler.sendMessage(mHandler.obtainMessage(BUMP_MSG, value, 0));
}
};
private static final int BUMP_MSG = 1;
private Handler mHandler = new Handler() {
@Override public void handleMessage(Message msg) {
switch (msg.what) {
case BUMP_MSG:
mCallbackText.setText("Received from service: " + msg.arg1);
break;
default:
super.handleMessage(msg);
}
}
};
}