展会信息港展会大全

Android Service和Binder、AIDL
来源:互联网   发布日期:2016-01-13 22:15:44   浏览:3393次  

导读:1.首先理解service的作用和生命周期,由于activity如果切换,那么他就不再运行,那么我们想在玩游戏的时候听播放器中的音乐,activity就应运而生了,这是最常见的一种场景,同时service由于它的优先级比较高,不......

1.首先理解service的作用和生命周期,

由于activity如果切换,那么他就不再运行,那么我们想在玩游戏的时候听播放器中的音乐,activity就应运而生了,这是最常见的一种场景,同时service由于它的优先级比较高,不容易被回收,而且是独立进程,不会阻塞UI线程,因此,可以用来处理一些比较费时的任务。

service起于startService(),终于stopService,如果没有调用stopService,那么,即使调用者结束了,该service也一直存在。

也可以通过bindService来绑定service,unBindService分开并结束service。如果bind的时候没有启动service,那么它会调用service的create方法启动。

多个程序可同时bind同一个service,只有他们都unbind了,这个service就会自动结束。如果有部分unbinder的时候调用stopservice,这个stop也会等到它们全部结束的时候才真的结束。

2.service的种类,

由于adroid的独特的线程模型,service被同一个apk调用和不同apk调用原理是不同的,因此分成以下两种:

(1). 本地服务(Local Service):说白了就是在同一个apk内被调用。

(2). 远程服务(Remote Sercie):被另外一个apk调用。

3.涉及到的内容:

由于android的进程模型,不同的apk不能共用数据,因此如果有需要的话需要通过进程间通讯完成。

进程间通讯(ipc)涉及到三个部分:客户端(调用方),传递数据,服务端(被调用方)。

android的数据传递类似于RPC过程,采用aidl的方式传递,考虑到效率的原因,没有用java内置的serializable,而是采用原始数据拆分组装的parcel方式。

4.场景假设:

一个service提供产生Student数据的功能,作为服务端,一个apk中的activity想获取另一个apk中的一个学生。根据上边的分析,service即使服务端,activity即使客户端,student是要传输的数据,要被包装成pacel传递。

5.根据android思想,理想的传递过程:

student提供拆分成parcel的writeToParcel()方法和根据Parcel组装的构造函数Student(Pacel p);

一个bissiness Service(bizSvc)用来实现逻辑功能。

一个android service(adSvc)调用bizService提供功能。

一个MyBinder负责service描述符与bizService的映射(本地服务时供queryLocalInterface查找)和与客户端交互。(如果被本地调用,就查找到相应的service直接操作,不用远程通讯,如果被远程调用,就得负责与远程通讯)

一个Proxy负责在客户端提供transact()方法发送数据。

具体的调用过程如下:

调用的时候,客户端首先调用bindService(new Intent ("abc"), serviceConnection,Context.BIND_AUTO_CREATE);激活serviceConnection的onServiceConnected方法,在此方法中获取到一个binder(注:clientBinder,系统给我们的一个与远程进行通信的binder,不是我们刚才自己实现的),此binder能够查找系统中注册的service,如果没有查找到该Service,那么可认定该service是从其他apk获得的,就创建一个此service的静态代理类Proxy,否则,就把这个service返回,供客户端调用。

服务端收到这个Intent后,激活adSvc的onBind方法,创建一个MyBinder返回。之后,这个MyBinder负责与客户端的Proxy通信。

之后,客户端要调用service的方法,可直接调用(本地)或者通过代理调用(远程),这个Proxy调用clientBinder的transact方法,参数为要掉用的方法(TRANSACRION_XX),发送的参数(_data),接受的返回值(_reply),把消息传送给服务端。

服务端收到消息后,调用MyBinder的onTransac方法,根据Proxy传递过来参数,调用bizService不同的方法,并把产生的值组装成Parcel发送回去。之后客户端Proxy会自动调用sudent的相关方法,把数据重新组装,进行下一步处理。

理想的代码如下(这是理想的代码,经过拆分,但是不符合android的aidl规范,不能运行,见下文分析):

客户端代码:

final IMyBizService bizSvc;

bindService(new Intent("abc"),new ServiceConnection(){

@Override

public void onServiceConnected(ComponentName name, IBinder clientBinder) {

if ((binder == null)) {

return null;

}

IInterface iin =clientBinder.queryLocalInterface(DESCRIPTOR);//如果是查找本地有,就直接返回

if (((iin != null) && (iin instanceof IMyService))) {

return ((IMyService) iin);

}

return new Proxy(obj);//否则采用远程代理

}

}, Context.BIND_AUTO_CREATE);

Proxy.java:

public class Proxy implements IMyBizService {

private IBinder mRemote;

private String description;

public Proxy(IBinder binder,String description) {

super();

this.mRemote=binder;

this.description=description;

}

@Override

public IBinder asBinder() {

return mRemote;

}

public Student getStudent() throws android.os.RemoteException {

android.os.Parcel _data = android.os.Parcel.obtain();

android.os.Parcel _reply = android.os.Parcel.obtain();

Student _result;

try {

_data.writeInterfaceToken(description);

mRemote.transact(MyBinder.TRANSACTION_getStudent, _data,_reply, 0);//发送参数给服务端

_reply.readException();

if ((0 != _reply.readInt())) {

_result = new Student(_reply);//接受参数并返回

} else {

_result = null;

}

} finally {

_reply.recycle();

_data.recycle();

}

return _result;

}

}

服务端代码:

MyService.java:

public class MyService extends Service {

@Override

public IBinder onBind(Intent intent) {

MyBizServiceImpl svc=new MyBizServiceImpl();

MyBinder binder= new MyBinder(new MyBizServiceImpl(),intent.getAction());

svc.setBinder(binder);//(此处有点绕,binder方法需要bizService作为参数实现绑定和调用,而bizSvc需要这个Binder作为参数,用来实现asBind方法,形成了一个环);

return binder;

}

}

MyBinder.java:

public class MyBinder extends Binder {

static final int TRANSACTION_getStudent = (IBinder.FIRST_CALL_TRANSACTION + 1);

private IInterface intf;

private String descripter;

public MyBinder(IInterface intf, String descripter) {

super();

this.intf=intf;

this.descripter=descripter;

this.attachInterface(intf, descripter);

}

@Override

public boolean onTransact(int code, Parcel data,Parcel reply, int flags)throws RemoteException {

IMyBizService myService=(IMyBizService) this.intf;

switch (code) {

case INTERFACE_TRANSACTION: {

reply.writeString(descripter);

return true;

}

case TRANSACTION_getStudent: {

data.enforceInterface(descripter);

Student _result = myService.getStudent();

reply.writeNoException();

if ((_result != null)) {

reply.writeInt(1);

_result.writeToParcel(reply,Parcelable.PARCELABLE_WRITE_RETURN_VALUE);//发送数据给客户端

} else {

reply.writeInt(0);

}

return true;

}

}

return super.onTransact(code, data, reply, flags);

}

}

MyBizService.java:

public class MyBizServiceImpl implements IMyBizService {

private IBinder binder;

public void setBinder(IBinder binder){

this.binder=binder;

}

@Override

public IBinder asBinder() {

return binder;

}

@Override

public Student getStudent() throws RemoteException {

Student st = new Student();

st.setName("devil");

return st;

}

}

5 aidl对这个机制的改进:

第4步的代码不能执行,只能作为理解原理和阅读代码用。因为为了安全和效率,aidl的关键类自动生成,不能修改,同时android对aidl的保护也使得需要一些额外的检查。

对比以上代码,android自动生成的代码有以下几个方面不同:

1).MyBinder,IMyBizService,和Proxy通通根据IMyBizService.aidl文件自动生成为IMyBizService.java文件。具体关系如下:

MyBinder和IMyBizService被合并成一个Stub类作为IMyBizService的内部类(直接导致this被滥用,但同时实现了这两个,那么相关方法直接用this就行了,不用形成前文所说的环了)。这个类负责接与客户端交互。而且还有一个额外静态方法asInterface供客户端在引起connection的onConnected时调用,实现根据传入的clientBinder判断本次调用是本地调用还是远程调用,从而确定是否采用Proxy,这样这个方法既然已经实现了,那么我们直接用就行了,无须再写一遍。具体IMyBizService的实现,只需继承Stub类即可。这样,只需在adService中创建MyBinder的时候,也就同时创建了MyBizService.

Proxy作为Stub的内部类(真纠结。。),被asInterface调用,从而进一步被客户端调用。

2).由于自动生成的IMyBizService.java中的Stub的onTransact利用了Student类中的一个CREATE内部域作为转换器,我们必须在Student类中添加并实现这个域,注意:域名必须是CREATE大写。(这个实现有点囧,可能是因为在自动生成文件的时候无法确定这个转换方法的写法)。

6 这个模型一些特例

1).如果本service只作为本地调用,可无须aidl相关操作,服务端的binder直接像stub那样,即使binder又是service,这样,调用方(如Activity)由于与该service在同一个apk中,ServiceConnection中获取的clientBind就是service返回的那个myBinder,这样的话,直接强转即可得到IMyBizService.不用调用queryLocalInterface()方法再查找一次。

2).如果不用额外调用service的其他方法,只是启动一个service的话,那么直接用startService即可,无须bind。

7.对这个模型的感受

这个模型有点囧,作者本来想让码工少写点代码,结果理解起来结构感觉乱糟糟的,而且没有一条主线,内部类各种相互调,客户端服务端不分,太不给力了。除非使用者之前有良好的rpc功底和代码运用能力,否则,要实现自己定制的功能比以前还得小心,要不就是对着示例代码照猫画虎,调试起来就是一种折磨。(一家之言,有理解不对的地方多多提醒,文中示例参考了http://4225953-163-com.javaeye.com/blog/792997一文中的示例)

8.附带标准aidl实现的完整过程:

1)实现要传递的数据结构和aidl(student.java和student.aidl)

2)实现相关的service的aidl(IMyBizService.aidl)

2)如果是eclipse,在1,2完成的情况下,会自动在gen目录下生成IMyBizService.java文件,如果非eclispse,则需要用sdk/platfroms/{version}/tools/aidl工具生成。

3)在myService中集成Stub类,实现IMyBizServic的方法,并作为binder在onBind方法中返回。

4)把IBizInterface.java和Student.java考进客户端工程(aidl文件安不需要,并且包名不能改变),客户端调用Stub的asInterface方法获取到相关的接口代理

5)利用接口代理调用各种方法

6)对于以上各个步骤中的具体操作,网上到处都是。

人收藏此文章, 关注此文章发表于3个月前 , 已有 206次阅读 共 个评论人收藏此文章

1.首先理解service的作用和生命周期,

由于activity如果切换,那么他就不再运行,那么我们想在玩游戏的时候听播放器中的音乐,activity就应运而生了,这是最常见的一种场景,同时service由于它的优先级比较高,不容易被回收,而且是独立进程,不会阻塞UI线程,因此,可以用来处理一些比较费时的任务。

service起于startService(),终于stopService,如果没有调用stopService,那么,即使调用者结束了,该service也一直存在。

也可以通过bindService来绑定service,unBindService分开并结束service。如果bind的时候没有启动service,那么它会调用service的create方法启动。

多个程序可同时bind同一个service,只有他们都unbind了,这个service就会自动结束。如果有部分unbinder的时候调用stopservice,这个stop也会等到它们全部结束的时候才真的结束。

2.service的种类,

由于adroid的独特的线程模型,service被同一个apk调用和不同apk调用原理是不同的,因此分成以下两种:

(1). 本地服务(Local Service):说白了就是在同一个apk内被调用。

(2). 远程服务(Remote Sercie):被另外一个apk调用。

3.涉及到的内容:

由于android的进程模型,不同的apk不能共用数据,因此如果有需要的话需要通过进程间通讯完成。

进程间通讯(ipc)涉及到三个部分:客户端(调用方),传递数据,服务端(被调用方)。

android的数据传递类似于RPC过程,采用aidl的方式传递,考虑到效率的原因,没有用java内置的serializable,而是采用原始数据拆分组装的parcel方式。

4.场景假设:

一个service提供产生Student数据的功能,作为服务端,一个apk中的activity想获取另一个apk中的一个学生。根据上边的分析,service即使服务端,activity即使客户端,student是要传输的数据,要被包装成pacel传递。

5.根据android思想,理想的传递过程:

student提供拆分成parcel的writeToParcel()方法和根据Parcel组装的构造函数Student(Pacel p);

一个bissiness Service(bizSvc)用来实现逻辑功能。

一个android service(adSvc)调用bizService提供功能。

一个MyBinder负责service描述符与bizService的映射(本地服务时供queryLocalInterface查找)和与客户端交互。(如果被本地调用,就查找到相应的service直接操作,不用远程通讯,如果被远程调用,就得负责与远程通讯)

一个Proxy负责在客户端提供transact()方法发送数据。

具体的调用过程如下:

调用的时候,客户端首先调用bindService(new Intent ("abc"), serviceConnection,Context.BIND_AUTO_CREATE);激活serviceConnection的onServiceConnected方法,在此方法中获取到一个binder(注:clientBinder,系统给我们的一个与远程进行通信的binder,不是我们刚才自己实现的),此binder能够查找系统中注册的service,如果没有查找到该Service,那么可认定该service是从其他apk获得的,就创建一个此service的静态代理类Proxy,否则,就把这个service返回,供客户端调用。

服务端收到这个Intent后,激活adSvc的onBind方法,创建一个MyBinder返回。之后,这个MyBinder负责与客户端的Proxy通信。

之后,客户端要调用service的方法,可直接调用(本地)或者通过代理调用(远程),这个Proxy调用clientBinder的transact方法,参数为要掉用的方法(TRANSACRION_XX),发送的参数(_data),接受的返回值(_reply),把消息传送给服务端。

服务端收到消息后,调用MyBinder的onTransac方法,根据Proxy传递过来参数,调用bizService不同的方法,并把产生的值组装成Parcel发送回去。之后客户端Proxy会自动调用sudent的相关方法,把数据重新组装,进行下一步处理。

理想的代码如下(这是理想的代码,经过拆分,但是不符合android的aidl规范,不能运行,见下文分析):

客户端代码:

final IMyBizService bizSvc;

bindService(new Intent("abc"),new ServiceConnection(){

@Override

public void onServiceConnected(ComponentName name, IBinder clientBinder) {

if ((binder == null)) {

return null;

}

IInterface iin =clientBinder.queryLocalInterface(DESCRIPTOR);//如果是查找本地有,就直接返回

if (((iin != null) && (iin instanceof IMyService))) {

return ((IMyService) iin);

}

return new Proxy(obj);//否则采用远程代理

}

}, Context.BIND_AUTO_CREATE);

Proxy.java:

public class Proxy implements IMyBizService {

private IBinder mRemote;

private String description;

public Proxy(IBinder binder,String description) {

super();

this.mRemote=binder;

this.description=description;

}

@Override

public IBinder asBinder() {

return mRemote;

}

public Student getStudent() throws android.os.RemoteException {

android.os.Parcel _data = android.os.Parcel.obtain();

android.os.Parcel _reply = android.os.Parcel.obtain();

Student _result;

try {

_data.writeInterfaceToken(description);

mRemote.transact(MyBinder.TRANSACTION_getStudent, _data,_reply, 0);//发送参数给服务端

_reply.readException();

if ((0 != _reply.readInt())) {

_result = new Student(_reply);//接受参数并返回

} else {

_result = null;

}

} finally {

_reply.recycle();

_data.recycle();

}

return _result;

}

}

服务端代码:

MyService.java:

public class MyService extends Service {

@Override

public IBinder onBind(Intent intent) {

MyBizServiceImpl svc=new MyBizServiceImpl();

MyBinder binder= new MyBinder(new MyBizServiceImpl(),intent.getAction());

svc.setBinder(binder);//(此处有点绕,binder方法需要bizService作为参数实现绑定和调用,而bizSvc需要这个Binder作为参数,用来实现asBind方法,形成了一个环);

return binder;

}

}

MyBinder.java:

public class MyBinder extends Binder {

static final int TRANSACTION_getStudent = (IBinder.FIRST_CALL_TRANSACTION + 1);

private IInterface intf;

private String descripter;

public MyBinder(IInterface intf, String descripter) {

super();

this.intf=intf;

this.descripter=descripter;

this.attachInterface(intf, descripter);

}

@Override

public boolean onTransact(int code, Parcel data,Parcel reply, int flags)throws RemoteException {

IMyBizService myService=(IMyBizService) this.intf;

switch (code) {

case INTERFACE_TRANSACTION: {

reply.writeString(descripter);

return true;

}

case TRANSACTION_getStudent: {

data.enforceInterface(descripter);

Student _result = myService.getStudent();

reply.writeNoException();

if ((_result != null)) {

reply.writeInt(1);

_result.writeToParcel(reply,Parcelable.PARCELABLE_WRITE_RETURN_VALUE);//发送数据给客户端

} else {

reply.writeInt(0);

}

return true;

}

}

return super.onTransact(code, data, reply, flags);

}

}

MyBizService.java:

public class MyBizServiceImpl implements IMyBizService {

private IBinder binder;

public void setBinder(IBinder binder){

this.binder=binder;

}

@Override

public IBinder asBinder() {

return binder;

}

@Override

public Student getStudent() throws RemoteException {

Student st = new Student();

st.setName("devil");

return st;

}

}

5 aidl对这个机制的改进:

第4步的代码不能执行,只能作为理解原理和阅读代码用。因为为了安全和效率,aidl的关键类自动生成,不能修改,同时android对aidl的保护也使得需要一些额外的检查。

对比以上代码,android自动生成的代码有以下几个方面不同:

1).MyBinder,IMyBizService,和Proxy通通根据IMyBizService.aidl文件自动生成为IMyBizService.java文件。具体关系如下:

MyBinder和IMyBizService被合并成一个Stub类作为IMyBizService的内部类(直接导致this被滥用,但同时实现了这两个,那么相关方法直接用this就行了,不用形成前文所说的环了)。这个类负责接与客户端交互。而且还有一个额外静态方法asInterface供客户端在引起connection的onConnected时调用,实现根据传入的clientBinder判断本次调用是本地调用还是远程调用,从而确定是否采用Proxy,这样这个方法既然已经实现了,那么我们直接用就行了,无须再写一遍。具体IMyBizService的实现,只需继承Stub类即可。这样,只需在adService中创建MyBinder的时候,也就同时创建了MyBizService.

Proxy作为Stub的内部类(真纠结。。),被asInterface调用,从而进一步被客户端调用。

2).由于自动生成的IMyBizService.java中的Stub的onTransact利用了Student类中的一个CREATE内部域作为转换器,我们必须在Student类中添加并实现这个域,注意:域名必须是CREATE大写。(这个实现有点囧,可能是因为在自动生成文件的时候无法确定这个转换方法的写法)。

6 这个模型一些特例

1).如果本service只作为本地调用,可无须aidl相关操作,服务端的binder直接像stub那样,即使binder又是service,这样,调用方(如Activity)由于与该service在同一个apk中,ServiceConnection中获取的clientBind就是service返回的那个myBinder,这样的话,直接强转即可得到IMyBizService.不用调用queryLocalInterface()方法再查找一次。

2).如果不用额外调用service的其他方法,只是启动一个service的话,那么直接用startService即可,无须bind。

7.对这个模型的感受

这个模型有点囧,作者本来想让码工少写点代码,结果理解起来结构感觉乱糟糟的,而且没有一条主线,内部类各种相互调,客户端服务端不分,太不给力了。除非使用者之前有良好的rpc功底和代码运用能力,否则,要实现自己定制的功能比以前还得小心,要不就是对着示例代码照猫画虎,调试起来就是一种折磨。(一家之言,有理解不对的地方多多提醒,文中示例参考了http://4225953-163-com.javaeye.com/blog/792997一文中的示例)

8.附带标准aidl实现的完整过程:

1)实现要传递的数据结构和aidl(student.java和student.aidl)

2)实现相关的service的aidl(IMyBizService.aidl)

2)如果是eclipse,在1,2完成的情况下,会自动在gen目录下生成IMyBizService.java文件,如果非eclispse,则需要用sdk/platfroms/{version}/tools/aidl工具生成。

3)在myService中集成Stub类,实现IMyBizServic的方法,并作为binder在onBind方法中返回。

4)把IBizInterface.java和Student.java考进客户端工程(aidl文件安不需要,并且包名不能改变),客户端调用Stub的asInterface方法获取到相关的接口代理

5)利用接口代理调用各种方法

6)对于以上各个步骤中的具体操作,网上到处都是。

赞助本站

人工智能实验室

相关热词: Service Binder AIDL

AiLab云推荐
展开

热门栏目HotCates

Copyright © 2010-2024 AiLab Team. 人工智能实验室 版权所有    关于我们 | 联系我们 | 广告服务 | 公司动态 | 免责声明 | 隐私条款 | 工作机会 | 展会港