=====================================================================
D/AIDLDebug: setPersonIn1: Person{name=‘In’, age=‘1’}
D/AIDLDebug: setPersonIn2: Person{name=‘In’, age=‘666666’}
D/AIDLDebug: setPersonOut1: Person{name=‘null’, age=‘null’}
D/AIDLDebug: setPersonOut2: Person{name=‘null’, age=‘666666’}
D/AIDLDebug: setPersonInOut1: Person{name=‘InOut’, age=‘1’}
D/AIDLDebug: setPersonInOut2: Person{name=‘InOut’, age=‘666666’}
可以看到 in
和 inout
服务端都是可以接收到完整的属性,而 out
则服务端完全接收不到任何属性。
这验证了一部分我们的猜想:in
和 inout
可以从客户端传递参数中的属性到服务端,而 out
则不能从客户端传递参数的属性到服务端。
接着验证数据从服务端流向客户端,我们在服务端中修改了参数的属性,看一下客户端的对象属性有没有跟随变化:
D/AIDLDebug: in1: Person{name=‘In’, age=‘1’}
D/AIDLDebug: in2: Person{name=‘In’, age=‘1’}
D/AIDLDebug: out1: Person{name=‘Out’, age=‘1’}
D/AIDLDebug: out2: Person{name=‘null’, age=‘666666’}
D/AIDLDebug: inOut1: Person{name=‘InOut’, age=‘1’}
D/AIDLDebug: inOut2: Person{name=‘InOut’, age=‘666666’}
Log 证实了我们的猜想,in 的对象属性完全没有发生变化,而 out 和 inout 都同步了服务端的修改。
至此,我们的猜想已经得到了验证,最后还剩下一个问题,就是 in out inout 的生命周期,也就是说在该函数作用域之外,同步是否还会生效?修改我们的代码:
=====================================================================
客户端
findViewById(R.id.in).setOnClickListener(v -> {
try {
Person in = new Person(“In”, “1”);
Log.d(TAG, "in1: " + in);
mService.setPersonIn(in);
Log.d(TAG, "in2: " + in);
in.setPrice(“3”);
mService.personChanged();
} catch (RemoteException e) {
e.printStackTrace();
}
});
findViewById(R.id.out).setOnClickListener(v -> {
try {
Person out = new Person(“Out”, “1”);
Log.d(TAG, "out1: " + out);
mService.setPersonOut(out);
mService.changePerson();
Log.d(TAG, "out2: " + out);
} catch (RemoteException e) {
e.printStackTrace();
}
});
有两点修改:
-
in
修饰符在setPersonIn()
之后,客户端自行修改了对象参数,然后调用personChanged()
在服务端打印对象 -
out
修饰符在setPersonOut()
之后,调用changePerson()
改变服务端的对象属性,然后打印客户端的对象
服务端
D/AIDLDebug: setPersonIn1: Person{name=‘In’, age=‘1’}
D/AIDLDebug: setPersonIn2: Person{name=‘In’, age=‘666666’}
D/AIDLDebug: personChanged: Person{name=‘In’, age=‘666666’}
D/AIDLDebug: setPersonOut1: Person{name=‘null’, age=‘null’}
D/AIDLDebug: setPersonOut2: Person{name=‘null’, age=‘666666’}
D/AIDLDebug: changePerson: Person{name=‘CCCCCCC’, age=‘666666’}
客户端
D/AIDLDebug: in1: Person{name=‘In’, age=‘1’}
D/AIDLDebug: in2: Person{name=‘In’, age=‘1’}
D/AIDLDebug: out1: Person{name=‘Out’, age=‘1’}
D/AIDLDebug: out2: Person{name=‘null’, age=‘666666’}
可以看到,数据的流动不能始终保持,在离开了相应的函数作用域之后,流动就会失效。
=================================================================
方向标记规定了在跨进程通信中参数内部的数据流向:
-
in
:表示参数内部数据只能从客户端流向服务端 -
out
:表示参数内部数据只能从服务端流向 客户端 -
inout
:表示参数内部数据可以在客户端和服务端之间互相流动
而且,该流动特性只在被修饰的函数作用域内有效,一旦离开该作用域,流动特性就会失效。
==================================================================
通过源码印证下我们的结论,看一下生成的 AIDL java 文件:
@Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException
{
java.lang.String descriptor = DESCRIPTOR;
switch (code)
{
case INTERFACE_TRANSACTION:
{
reply.writeString(descriptor);
return true;
}
case TRANSACTION_setPersonIn:
{
data.enforceInterface(descriptor);
// 可以看到 _arg0 就是客户端传进来的参数
com.yaya.服务端.Person _arg0;
if ((0!=data.readInt())) {
_arg0 = com.yaya.服务端.Person.CREATOR.createFromParcel(data);
}
else {
_arg0 = null;
}
// 在这里将参数传递给服务端
this.setPersonIn(_arg0);
reply.writeNoException();
return true;
}
case TRANSACTION_setPersonOut:
{
data.enforceInterface(descriptor);
com.yaya.服务端.Person _arg0;
// out 根本没有从客户端拿数据,而是 new 了一个新对象
_arg0 = new com.yaya.服务端.Person();
// 然后将新对象传递给服务端
this.setPersonOut(_arg0);
reply.writeNoException();
// 在这里将服务端的对象重新写到序列化中,可以返给客户端。如果在 setPersonOut 方法中改变了参数,会在这里传递给客户端
if ((_arg0!=null)) {
reply.writeInt(1);
_arg0.writeToParcel(reply, android.os.Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
}
else {
reply.writeInt(0);
}
return true;
}
case TRANSACTION_setPersonInOut:
{
data.enforceInterface(descriptor);
// inout 在这里获取了客户端传递的参数
com.yaya.服务端.Person _arg0;
if ((0!=data.readInt())) {
_arg0 = com.yaya.服务端.Person.CREATOR.createFromParcel(data);
}
else {
_arg0 = null;
}
// 在这里传递给服务端
this.setPersonInOut(_arg0);
reply.writeNoException();
// 在这里回写给客户端
if ((_arg0!=null)) {
reply.writeInt(1);
_arg0.writeToParcel(reply, android.os.Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
}
else {
reply.writeInt(0);
}
return true;
}
case TRANSACTION_changePerson:
{
data.enforceInterface(descriptor);
this.changePerson();
reply.writeNoException();
return true;
}
case TRANSACTION_personChanged:
{
data.enforceInterface(descriptor);
this.personChanged();
reply.writeNoException();
return true;
}
case TRANSACTION_getPerson:
{
data.enforceInterface(descriptor);
com.yaya.服务端.Person _result = this.getPerson();
reply.writeNoException();
if ((_result!=null)) {
reply.writeInt(1);
_result.writeToParcel(reply, android.os.Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
}
else {
reply.writeInt(0);
}
return true;
}
default:
{
return super.onTransact(code, data, reply, flags);
}
}
}
参看源码中的注释,可以从代码层面印证我们的猜想,而且明确了为什么仅在函数作用域内才会流动。
==================================================================
如果你在 Android 11 上进行试验,可能会发现怎么都 bind 不上 Service:
ActivityManager: Unable to start service Intent { act=com.yaya.server cmp=com.yaya.server/.YaYaService } U=0: not found
reply.writeInt(0);
}
return true;
}
default:
{
return super.onTransact(code, data, reply, flags);
}
}
}
参看源码中的注释,可以从代码层面印证我们的猜想,而且明确了为什么仅在函数作用域内才会流动。
==================================================================
如果你在 Android 11 上进行试验,可能会发现怎么都 bind 不上 Service:
ActivityManager: Unable to start service Intent { act=com.yaya.server cmp=com.yaya.server/.YaYaService } U=0: not found