android ipc 多个客户端,Android IPC之AIDL进阶篇

前言

在Android IPC之AIDL中我介绍了如何使用AIDL进行多进程通信,不过由于当时个人水平有限,仅仅介绍了最基础的部分,所以本篇博客主要是在Android IPC之AIDL的基础上深入介绍下AIDL的进阶的几点理解以及用法。

AIDL接口中的in out inout的含义

在Android IPC之AIDL中稍微提了下,在客户端与服务端进行复杂数据传递的时候,需要使用这三个修饰符,表示数据的流向,并没有具体说明,这里通过我的测试给出一个结果,使用in修饰,客户端的对象可以"传递给"服务端,但是服务端不能修改客户端的对象,使用out修饰,客户端的对象不可以"传递给"服务端,但是服务端可以修改客户端的对象,inout则是双向的,服务端可以拿到客户端的数据也可以修改客户端的数据。"传递"之所以有引号,表示客户端和服务端的对象不是同一个,而是序列化/反序列化的而已。

上面的传递的意思是数据类型以及值都能传递过去,举例来说,一个Person,初始化为name=a,age=10,

使用in修饰,客户端为[name=a,age=10]服务端拿到的是[name=a,age=10],但是服务端修改age=11,客户端还是[name=a,age=10]

使用out修饰,客户端为[name=a,age=10]服务端拿到的是[name=null,age=0](String的默认类型为空,int的默认类型为0),服务端修改age=11,客户端变为[name=a,age=11]

使用inout修饰符,则服务端可以拿到正确的数据,对数据的修改也会同步到客户端

oneway的用法

AIDL定义的方法是阻塞的,所以我们需要很注意不要在UI线程中调用耗时很长的AIDL方法,不然会导致ANR,如果不想客户端被阻塞可以选择开启一个线程去执行或者使用oneway修饰被调用的方法或者接口。这样当客户端调用的时候就不会被阻塞了。

//IRemote.aidl

interface IRemote{

oneway void testOneWay();

}

如果我们多次调用被oneway修饰的方法,都不会被阻塞,而且远程方法是顺序执行的,比如上面的testOneWay()方法被调用两次,只有当第一次执行完毕,第二次才会继续执行,但是对于客户端来说是感知不到的。

服务端感知客户端是否崩溃

当我们绑定一个远程服务的时候,如果远程服务崩溃了,我们可以通过ServiceConnection的onServiceDisconnected感知到,可是如果客户端崩溃了,服务端怎么感知呢?

对于这种情景,我们可以让客户端传递一个Binder对象给服务端,然后服务端使用IBinder.linkToDeath监听,当客户端终止的时候,Binder对象也会被杀死,然后服务端就可以收到客户端死亡消息了。

binder.linkToDeath(new DeathRecipient() {

@Override

public void binderDied() {

Log.i("IPC", "client died");

}

}, 0);

具体实现如下。

首先定义个AIDL接口

//IRemote.aidl

interface IRemote{

void testClientError(IBinder binder);

}

服务端实现

@Override

public void testClientError(IBinder binder) throws RemoteException {

binder.linkToDeath(new DeathRecipient() {

@Override

public void binderDied() {

Log.i("IPC", "client died");

}

}, 0);

}

客户端调用,最后一句int i = 0/0;是为了测试客户端异常退出

private IBinder mToken = new Binder();

public void testError(View v) {

if (remoteInterface == null) {

return;

}

try {

remoteInterface.testClientError(mToken);

} catch (RemoteException e) {

e.printStackTrace();

}

int i = 0 / 0;

}

扩展:既然通过Binder对象可以感知到对应的进程是否死亡,那么我们也可以换种方式在客户端获取服务端的状态,上面的例子中,我们是主动new了一个Binder对象发送给服务端,那么怎么获取到服务端的Binder对象呢?答案就在ServiceConnection的onServiceConnected中,第二个参数就可以用来监听服务端是否死亡。

服务端调用客户端的方法

假设我们有这样一个需求,一个客户连接服务端的时候,服务端需要通知其他所有的客户端,如果在同一个进程中,我们可以使用回调的方式,在多进程条件下,我们也可以使用回调,不过客户端需要实现AIDL接口才行。

具体实现如下

首先定义一个AIDL接口,当连接的时候,服务端调用所有客户端的接口,显示一个Toast

//IClientCallBack.aidl

interface IClientCallBack{

void showToastInClient(String msg);

}

然后添加注册/解注册方法

//IRemote.aidl

interface IRemote{

void register(IClientCallBack callback);

void unregister(IClientCallBack callback);

}

客户端实现AIDL接口

private IClientCallBack mCallBack = new IClientCallBack.Stub() {

@Override

public void showToastInClient(String msg) throws RemoteException {

Toast.makeText(MainActivity.this, msg, Toast.LENGTH_SHORT).show();

}

};

然后接下来就是服务端保存所有的回调接口到一个List中,剩下的就和普通调用一样了。

可是重点来了,如果客户端注册了回调,但是没有解除注册就意外终止了,那么服务端是无法感知到的,这样无疑浪费了资源,而且导致程序不稳定,所以我们需要在客户端意外终止的时候移除监听,由于使用的AIDL接口,所以这时我们就可以使用上面的IBinder.linkToDeath方法了。类似如下形式。

@Override

public void register(IClientCallBack callback) throws RemoteException {

callback.asBinder().linkToDeath(new DeathRecipient() {

@Override

public void binderDied() {

// TODO Auto-generated method stub

}

}, 0);

......

}

程序员都是喜欢偷懒的,能简单就简单,上面还要我们自己去实现binderDied方法,无疑是降低了开发效率,好歹谷歌给我们提供了RemoteCallbackList用来为我们保存回调列表,它会在客户端异常终止的时候自动移出,免去了我们的人工操作,流程如下。

public class RemoteService extends Service {

//定义RemoteCallbackList对象,保存类型为IClientCallBack

private RemoteCallbackList mList = new RemoteCallbackList();

@Override

public void onDestroy() {

//当RemoteService销毁的时候,清空RemoteCallbackList列表

mList.kill();

super.onDestroy();

}

private IRemote.Stub mStud = new Stub() {

@Override

public void register(IClientCallBack callback) throws RemoteException {

//保存回调到RemoteCallbackList中

mList.register(callback);

//开始通知全部客户端

int i = mList.beginBroadcast();

Log.i("IPC", "size = " + (i - 1));

//遍历客户端

while (i > 0) {

i--;

try {

mList.getBroadcastItem(i).showToastInClient("i am from Server");

} catch (RemoteException e) {

e.printStackTrace();

}

}

//结束通知客户端

mList.finishBroadcast();

}

@Override

public void unregister(IClientCallBack callback) throws RemoteException {

//将回调从RemoteCallbackList移除

mList.unregister(callback);

}

};

}

RemoteCallbackList的内部实现与我们上面提到的一样,使用的IBinder.linkToDeath方法。有兴趣的可以查看下其源码。

给服务端加入权限认证

有时候,我们并不想让我们的远程服务随便的被人绑定,这是就需要使用给我们的服务加入权限认证才行。一般来说,有两种方法。

首先我们在AndroidManifest.xml文件中声明的权限,如下

然后我们在Service的onBind方法中使用checkCallingOrSelfPermission方法验证客户端是否声明了权限,如果没有声明,则返回null,那么客户端的onServiceConnected方法将不会被回调,客户端将绑定失败。这个方法对于普通的Service同样适用。

public class MyService extends Service {

private static final String TAG = "MyService";

public MyService() {

}

@Override

public IBinder onBind(Intent intent) {

int permission = checkCallingOrSelfPermission("com.remote.service.PRI");

if (permission == PackageManager.PERMISSION_DENIED) {

Log.i(TAG, "onBind: Error");

return null;

}

Log.i(TAG, "onBind: Success");

return mBinder;

}

}

如果客户端想绑定我们的服务,那么需要在AndroidManifest.xml文件中声明这个权限才行。

对于AIDL来说,我们可以在实现AIDL接口的Stub中,覆写onTransact,在onTransact方法中进行权限验证,如下。

private IRemote.Stub mStud = new IRemote.Stub() {

/**

* 这里可以进行权限验证,true,允许绑定,false,不允许绑定

*/

public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags)

throws RemoteException {

int check = checkCallingOrSelfPermission("com.ryg.chapter_2.permission.ACCESS_BOOK_SERVICE");

Log.d("IPC", "onbind check=" + check);

// getCallingPid();

// getCallingUid();

// 只允许包名以org.ipc.demo开头的app 调用本服务提供的方法

// 此方法并不能阻止绑定,但是能让非法调用者无法使用本服务提供的方法

String[] packagesForUid = getPackageManager().getPackagesForUid(getCallingUid());

if (packagesForUid != null && packagesForUid.length > 0) {

if (packagesForUid[0].startsWith("org.ipc.demo")) {

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

}

}

return false;

};

};

在onTransact方法中,我们不仅可以验证是否声明了权限,我们还可以获取到客户端的包名,对包名等信息进行限制,但是此方法会回调客户端的onServiceConnected方法,但是客户端无法调用服务端提供的方法。

参考资料:《Android开发艺术探索》第二章、

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值