AIDL传输大小不能操过1M #define BINDER_VM_SIZE ((110241024) - (4096 *2))
为了说的深入浅出一点,我们先从AIDL的作用和使用说起,然后再开始介绍一些概念和工作原理。
AIDL用来做什么
AIDL是Android中IPC(Inter-Process Communication)方式中的一种,AIDL是Android Interface definition language的缩写,对于小白来说,AIDL的作用是让你可以在自己的APP里绑定一个其他APP的service,这样你的APP可以和其他APP交互。
AIDL的使用
在android studio 2.0里面使用AIDL,因为是两个APP交互么,所以当然要两个APP啦,我们在第一个工程目录右键
输入名称后,sutido就帮我们创建了一个AIDL文件。
// IMyAidlInterface.aidl
package cc.abto.demo;
// Declare any non-default types here with import statements
interface IMyAidlInterface {
/**
* 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);
}
上面就是studio帮我生成的aidl文件。basicTypes这个方法可以无视,看注解知道这个方法只是告诉你在AIDL中你可以使用的基本类型(int, long, boolean, float, double, String),因为这里是要跨进程通讯的,所以不是随便你自己定义的一个类型就可以在AIDL使用的,这些后面会说。我们在AIDL文件中定义一个我们要提供给第二个APP使用的接口。
interface IMyAidlInterface {
String getName();
}
定义好之后,就可以sync project一下,然后新建一个service。在service里面创建一个内部类,继承你刚才创建的AIDL的名称里的Stub类,并实现接口方法,在onBind返回内部类的实例。
public class MyService extends Service
{
public MyService()
{
}
@Override
public IBinder onBind(Intent intent)
{
return new MyBinder();
}
class MyBinder extends IMyAidlInterface.Stub
{
@Override
public String getName() throws RemoteException
{
return "test";
}
}
}
接下来,将我们的AIDL文件拷贝到第二个项目,然后sync project一下工程。
这边的包名要跟第一个项目的一样哦,这之后在Activity中绑定服务。
public class MainActivity extends AppCompatActivity
{
private IMyAidlInterface iMyAidlInterface;
@Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
bindService(new Intent("cc.abto.server"), new ServiceConnection()
{
@Override
public void onServiceConnected(ComponentName name, IBinder service)
{
iMyAidlInterface = IMyAidlInterface.Stub.asInterface(service);
}
@Override
public void onServiceDisconnected(ComponentName name)
{
}
}, BIND_AUTO_CREATE);
}
public void onClick(View view)
{
try
{
Toast.makeText(MainActivity.this, iMyAidlInterface.getName(), Toast.LENGTH_SHORT).show();
}
catch (RemoteException e)
{
e.printStackTrace();
}
}
}
这边我们通过隐式意图来绑定service,在onServiceConnected方法中通过IMyAidlInterface.Stub.asInterface(service)获取iMyAidlInterface对象,然后在onClick中调用iMyAidlInterface.getName()。
自定义类型
如果我要在AIDL中使用自定义的类型,要怎么做呢。首先我们的自定义类型要实现Parcelable接口,下面的代码中创建了一个User类并实现Parcelable接口。这边就不对Parcelable进行介绍了,不熟悉的童鞋自行查找资料,总之我们这边可以借助studio的Show Intention Action(也就是Eclipse中的Quick Fix,默认是alt+enter键)帮我们快速实现Parcelable接口。
接下新建一个aidl文件,名称为我们自定义类型的名称,这边是User.aidl。在User.aidl申明我们的自定义类型和它的完整包名,注意这边parcelable是小写的,不是Parcelable接口,一个自定类型需要一个这样同名的AIDL文件。
package cc.abto.demo;
parcelable User;
然后再在我们的AIDL接口中导入我们的AIDL类型。
然后定义接口方法,sync project后就可以在service中做具体实现了。
public class MyService extends Service
{
//...
@Override
public IBinder onBind(Intent intent)
{
return new MyBinder();
}
class MyBinder extends IMyAidlInterface.Stub
{
//...
@Override
public User getUserName() throws RemoteException
{
return new User("wswf");
}
}
}
最后将我们的AIDL文件和自定义类型的java一并拷贝到第二个项目,注意包名都要一样哦
然后就可以在Activity中使用该自定义类型的AIDL接口了
public class MainActivity extends AppCompatActivity
{
//...
public void onClick(View view)
{
try
{
Toast.makeText(MainActivity.this, iMyAidlInterface.getUserName().getName(), Toast.LENGTH_SHORT).show();
}
catch (RemoteException e)
{
e.printStackTrace();
}
}
}
效果图就不贴了哈,通过这种方式我们就可以让两个APP之间进行交互了。
最后
为什么APP间的进程交互这么麻烦,是因为它们属于不同的进程,之间的交互涉及到进程间的通讯。而AIDL只是Android中众多进程间通讯方式中的一种方式,那么AIDL到底是什么鬼,它是如何工作的,Android的IPC机制又是怎样的呢。
AIDL的原理
IPC
在这之前我们先简单说一下IPC,IPC是Inter-Process Communication的缩写,是进程间通信或者跨进程通信的意思,既然说到进程,大家要区分一下进程和线程,进程一般指的是一个执行单元,它拥有独立的地址空间,也就是一个应用或者一个程序。线程是CPU调度的最小单元,是进程中的一个执行部分或者说是执行体,两者之间是包含与被包含的关系。因为进程间的资源不能共享的,所以每个系统都有自己的IPC机制,Android是基于Linux内核的移动操作系统,但它并没有继承Linux的IPC机制,而是有着自己的一套IPC机制。
Binder
Binder就是Android中最具特色的IPC方式,AIDL其实就是通过Binder实现的,因为在我们定义好aidl文件后,studio就帮我们生成了相关的Binder类。事实上我们在使用AIDL时候继承的Stub类,就是studio帮我们生成的Binder类,所以我们可以通过查看studio生成的代码来了解Binder的工作原理。首先我们定义一个AIDL文件
// UserManager.aidl
package cc.abto.demo;
interface UserManager {
String getName();
String getOtherName();
}
sycn project工程后,查看生成的UserManager.java文件
package cc.abto.demo;
// Declare any non-default types here with import statements
public interface UserManager extends android.os.IInterface
{
/**
* Local-side IPC implementation stub class.
*/
public static abstract class Stub extends android.os.Binder implements cc.abto.demo.UserManager
{
//...
}
public java.lang.String getName() throws android.os.RemoteException;
public java.lang.String getOtherName() throws android.os.RemoteException;
}
生成的代码还是比较多的,我就不一次性全部贴上来了,先按类结构来看。
sutido帮我们生成了一个继承android.os.IInterface接口的UserManager接口,所有在Binder中传输的接口都必须实现IInterface接口。接口定义了我们在AIDL文件中定义的方法,然后还有个内部静态类Stub,我们接着看这个Stub。
public static abstract class Stub extends android.os.Binder implements cc.abto.demo.UserManager
{
private static final java.lang.String DESCRIPTOR = "cc.abto.demo.UserManager";
/**
* Construct the stub at attach it to the interface.
*/
public Stub()
{
this.attachInterface(this, DESCRIPTOR);
}
/**
* Cast an IBinder object into an cc.abto.demo.UserManager interface,
* generating a proxy if needed.
*/
public static cc.abto.demo.UserManager asInterface(android.os.IBinder obj)
{
if ((obj == null))
{
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof cc.abto.demo.UserManager)))
{
return ((cc.abto.demo.UserManager) iin);
}
return new cc.abto.demo.UserManager.Stub.Proxy(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
{
switch (code)
{
case INTERFACE_TRANSACTION:
{
reply.writeString(DESCRIPTOR);
return true;
}
case TRANSACTION_getName:
{
data.enforceInterface(DESCRIPTOR);
java.lang.String _result = this.getName();
reply.writeNoException();
reply.writeString(_result);
return true;
}
case TRANSACTION_getOtherName:
{
data.enforceInterface(DESCRIPTOR);
java.lang.String _result = this.getOtherName();
reply.writeNoException();
reply.writeString(_result);
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements cc.abto.demo.UserManager
{
//...
}
static final int TRANSACTION_getName = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
static final int TRANSACTION_getOtherName = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);
}
Stub继承了android.os.Binder并实现UserManager接口,下图是Stub的类结构。
我们可以看到Stub中的常量,其中两个int常量是用来标识我们在接口中定义的方法的,DESCRIPTOR常量是 Binder的唯一标识。
asInterface 方法用于将服务端的Binder对象转换为客户端所需要的接口对象,该过程区分进程,如果进程一样,就返回服务端Stub对象本身,否则呢就返回封装后的Stub.Proxy对象。
onTransact 方法是运行在服务端的Binder线程中的,当客户端发起远程请求后,在底层封装后会交由此方法来处理。通过code来区分客户端请求的方法,注意一点的是,如果该方法返回false的换,客户端的请求就会失败。一般可以用来做权限控制。
最后我们来看一下Proxy代理类。
private static class Proxy implements cc.abto.demo.UserManager
{
private android.os.IBinder mRemote;
Proxy(android.os.IBinder remote)
{
mRemote = remote;
}
@Override
public android.os.IBinder asBinder()
{
return mRemote;
}
public java.lang.String getInterfaceDescriptor()
{
return DESCRIPTOR;
}
@Override
public java.lang.String getName() throws android.os.RemoteException
{
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.lang.String _result;
try
{
_data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(Stub.TRANSACTION_getName, _data, _reply, 0);
_reply.readException();
_result = _reply.readString();
}
finally
{
_reply.recycle();
_data.recycle();
}
return _result;
}
@Override
public java.lang.String getOtherName() throws android.os.RemoteException
{
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.lang.String _result;
try
{
_data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(Stub.TRANSACTION_getOtherName, _data, _reply, 0);
_reply.readException();
_result = _reply.readString();
}
finally
{
_reply.recycle();
_data.recycle();
}
return _result;
}
}
代理类中我们主要看一下getName和getOtherName方法就可以了,这两个方法都是运行在客户端,当客户端发起远程请求时,_data会写入参数,当然这边的例子并没有(啦啦啦...),然后调用transact方法发起RPC(远程过程调用)请求,同时挂起当前线程,然后服务端的onTransact方法就会被 调起,直到RPC过程返回后,当前线程继续执行,并从_reply取出返回值(如果有的话),并返回结果。
最后
分析完sutido生成的Binder之后,我们就大概知道AIDL的工作原理,定义好AIDL文件只是方便sutido帮我生成所需的Binder类,AIDL并不是必须的文件,因为这个Binder类我们也可以手写出来(当然,你闲的没事的话),所以这边最重要的还是Binder的知识点,其他一些IPC方式其实都是通过Binder来实现的,比如说Messager,Bundle,ContentProvider,只是它们的封装方式不一样而已。总的来说,从应用层来说,Binder是客户端和服务端之间通信的媒介。从FrameWork层来说,Binder是ServiceManager连接各种Manager和ManagerService的桥梁。Android系统中充斥着大量的CS模型,而Binder作为独有的IPC方式,如果我们能更好的理解它,对我们的开发工作就会带来更多的帮助。
AIDL的in out inout参数意义
如果按照这个意思的话,似乎它们的含义就很清晰了:in 与 out 分别表示客户端与服务端之间的两条单向的数据流向,而 inout 则表示两端可双向流通数据。基于这种猜测,我设计了一个实验来验证它,AIDL文件是这样的:
// Book.aidl
package com.lypeer.ipcclient;
parcelable Book;
// BookManager.aidl
package com.lypeer.ipcclient;
import com.lypeer.ipcclient.Book;
interface BookManager {
//保证客户端与服务端是连接上的且数据传输正常
List getBooks();
//通过三种定位tag做对比试验,观察输出的结果
Book addBookIn(in Book book);
Book addBookOut(out Book book);
Book addBookInout(inout Book book);
}
对其中的AIDL的语法不熟悉的,可以再去温故一下:Android:学习AIDL,这一篇文章就够了(上) ,我这里就不赘叙了。我主要讲一下实验的思路。可以看到,有定位tag的那三个方法它们的传参和返回值都是 Book 对象(Book是我自定义的一个实现了Parcelable的类,里面只有两个参数,String name 和 int price),并且它们的定位tag都不一样,接下来我会在客户端调用这三个方法,然后分别在客户端和服务端打印相关信息,从而验证我的猜想。下面贴上客户端和服务端的代码:
首先还是对于复述一遍得出的结论:AIDL中的定向 tag 表示了在跨进程通信中数据的流向,其中 in 表示数据只能由客户端流向服务端, out 表示数据只能由服务端流向客户端,而 inout 则表示数据可在服务端与客户端之间双向流通。其中,数据流向是针对在客户端中的那个传入方法的对象而言的。in 为定向 tag 的话表现为服务端将会接收到一个那个对象的完整数据,但是客户端的那个对象不会因为服务端对传参的修改而发生变动;out 的话表现为服务端将会接收到那个对象的参数为空的对象,但是在服务端对接收到的空对象有任何修改之后客户端将会同步变动;inout 为定向 tag 的情况下,服务端将会接收到客户端传来对象的完整信息,并且客户端将会同步服务端对该对象的任何变动。(没错,这就是从上面复制粘粘的:))