欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  移动技术

Android Binder入门学习笔记

程序员文章站 2022-06-16 13:32:47
写在前面 binder是android给我们提供的一种跨进程通信方式。理解binder能帮助我们更好的理解android的系统设计,比如说四大组件,ams,wms等系...

写在前面

binder是android给我们提供的一种跨进程通信方式。理解binder能帮助我们更好的理解android的系统设计,比如说四大组件,ams,wms等系统服务的底层通信机制就都是基于binder机制的。当然了,binder机制的底层驱动实现很复杂,本文的目的只是为了理清binder的使用和在应用层的结构和流程,对于binder在底层是如何实现的,目前能力还没到这一步去分析,不会涉及到。对于这部分,不妨将它看成是一个黑盒子,我们输入什么,然后底层会给我们提供什么。

代理模式

我们知道,a进程如果想要执行b进程的b方法,是没办法直接办得到的,但是通过binder机制,b进程可以返回给a进程一个代理对象proxy,然后a进程通过调用proxy的方法,由proxy帮我们将信息传递给b进程,从而间接调用b方法。没错,binder实现过程中用到了代理模式。所以在继续前行之前,有必要简单了解下代理模式先。

代理模式相对来说好理解一些,因为在生活中,到处都有代理的影子,比如说我们想去香港买个mac,但是自己不方便去,于是我们找了代购;比如说现在年底了要抢火车票,但是在12306手动抢票根本抢不到啊,所以我们找了第三方抢票软件,它会每隔几十ms就帮我们查询一次,有票的话就帮我们下单。这里就以抢火车票为例来说明代理模式的结构。

Android Binder入门学习笔记

proxy

模式比较简单,就直接上代码了。

// 声明买票接口
public interface iticket {
 boolean buyticket();
}

// 官方的12306
public class real12306 implements iticket {
 @override
 public boolean buyticket() {
  if (抢票成功) return true;
  return false;
 }
}

// 第三方抢票软件
public class thirdparty12306 implements iticket {

 private real12306 real12306;
 
 public thirdparty12306(real12306 real12306) {
  this.real12306 = real12306;
 }
 
 @override
 public boolean buyticket() {
  while (true) {
   if (real12306.buyticket()) {
    return true;
   }
   // 10ms查询一次结果
   try {
    thread.sleep(10);
   } catch (interruptedexception e) {
    e.printstacktrace();
   }
  }
 }
}

public class main {

 public static void main(string[] args) {

  // 初始化我们的购票信息
  real12306 real12306 = new real12306();
  
  thirdparty12306 thirdparty12306 = new thirdparty12306(real12306);
  
  // 开始不断抢票,释放我们的劳动力
  thirdparty12306.buyticket();
 }
}

使用了代理模式之后,我们就不用时时刻刻盯着12306刷票了,只需要把这些重复无聊的工作交给代理去帮我们干就好了。

aidl

一般来说,我们使用binder都是通过aidl来完成的。我们新建一个aidl文件,然后定义一个接口,这样android studio就会帮我们生成一个java接口文件。以一个最简单的接口来说吧。

package example.com.aidl;
interface imath {
 int add(int a, int b);
}

生成的imath.java文件中,代码有点乱,整理一下之后,结构大致是这样子的:

Android Binder入门学习笔记

aidl

简单来说,生成了一个imath接口,接口内定义了一个抽象类imath.stub,继承了binder,imath.stub又有一个内部类imath.stub.proxy。imath.stub和imath.stub.proxy都实现了imath这个接口。结合上面的代理模式,从这里我们就可以猜出,在跨进程通信中,由于各个进程都是独立的,我们的客户端拿不到服务端的imath.stub类,只能获得它的代理imath.stub.proxy,再通过它来间接帮我们访问imath.stub类,从而完成跨进程通信。

binder流程

看了上面的结构图之后,估计大家还是看不懂的。不急,我们再结合上面这个例子来说明。binder机制是基于c/s模型的,也就是说,需要一个client进程和一个server进程。client和server是相对的,谁发消息,谁就是client,谁接收消息,谁就是server。在实际开发中,server进程通常是四大组件中的service(service必须在manifest文件中指定进程名字)。

class remoteservice : service() {

 val math = math()

 override fun oncreate() {
  super.oncreate()
  log.d(tag, "oncreate")
 }
 
 override fun onbind(intent: intent): ibinder {
  return math
 }

 inner class math : imath.stub() {
  override fun add(a: int, b: int): int {
   return a + b
  }

 }
}

在remoteservice中,我们先定义一个math类,继承自imath.stub,在这里实现我们具体的服务端逻辑。因为imath.stub继承自binder,binder又实现了ibinder接口,所以在onbind()方法中直接返回math对象。接着再来看客户端的业务逻辑。

// 定义serviceconnection类
inner class myserviceconnection : serviceconnection {
 override fun onservicedisconnected(name: componentname?) {
  log.d(tag, "onservicedisconnected")
 }

 override fun onserviceconnected(name: componentname?, service: ibinder?) {
  if (service == null) return

  // 将ibinder转换成imath
  math = imath.stub.asinterface(service)

  log.d(tag, "result is ${math.add(1, 2)}")
 }
}

// 在oncreate中绑定remoteservice
val intent = intent(this, remoteservice::class.java)
bindservice(intent, serviceconnection, context.bind_auto_create)

当连接上service后,就会回调客户端的onserviceconnected()方法,这里传进来的service是一个binderproxy对象。

binderproxy是binder的代理类,同样也实现了ibinder接口。我们在server端返回的明明是一个math对象,到这里就变成了binderproxy对象了,是不是有点神奇?别忘了,math本身就是一个binder对象。由于是跨进程通信,我们无法直接拿到这个binder对象,只能由binderproxy对象来帮助我们完成任务。至于binder是怎么变成binderproxy的,这就是binder机制的底层原理了,将它当成一个黑盒子就好了。

拿到binderproxy对象后,再将它转换成我们定义的imath接口。

// imath.java
private static final java.lang.string descriptor = "example.com.aidl.imath";

public static example.com.aidl.imath asinterface(android.os.ibinder obj) {
 if ((obj == null)) {
  return null;
 }
 android.os.iinterface iin = obj.querylocalinterface(descriptor);
 if (((iin != null) && (iin instanceof example.com.aidl.imath))) {
  return ((example.com.aidl.imath) iin);
 }
 return new example.com.aidl.imath.stub.proxy (obj);
}

// binder.java
public @nullable iinterface querylocalinterface(@nonnull string descriptor) {
 if (mdescriptor != null && mdescriptor.equals(descriptor)) {
  return mowner;
 }
 return null;
}

从asinterface()方法中可以看到,根据key值descriptor在binder中匹配mowner,它是一个iinterface对象。但既然是去取值,就应该有地方将他们存进来的,我们好像错过了什么。这里还得回到math的初始化过程,math继承自imath.stub,看一下它的构造方法就能明白了。

// imath.java
public stub() {
 this.attachinterface(this, descriptor);
}

// binder.java
public void attachinterface(@nullable iinterface owner, @nullable string descriptor) {
 mowner = owner;
 mdescriptor = descriptor;
}

到了这里,iinterface的获取已经很明显了吧。但其实,这里取出来的是null。what?为什么?别忘了,remoteservice是运行在一个单独的进程中的,attachinterface()方法是binder调用的。而我们的客户端拿到的只是binderproxy,查询到的iinterface当然是null了,所以我们还得接着看asinterface()方法。(当然了,如果remoteservice和客户端运行在同一个进程的话,这里就能直接拿到iinterface了,但这与跨进程通信就没有半毛钱关系了。)

return new example.com.aidl.imath.stub.proxy(obj);

直接返回了一个代理对象。后续我们要跟server端做交互就得靠它了。比如我们调用了proxy.add()方法:

@override
public int add(int a, int b) throws android.os.remoteexception {
 android.os.parcel _data = android.os.parcel.obtain();
 android.os.parcel _reply = android.os.parcel.obtain ();
 int _result;
 try {
  // 使用parcel来写入数据以便于跨进程传输
  _data.writeinterfacetoken(descriptor);
  _data.writeint(a);
  _data.writeint(b);
  
  // mremote是在asinterface中获得的binderproxy对象
  mremote.transact(stub.transaction_add, _data, _reply, 0);
  
  // 使用parcel来接收返回值
  _reply.readexception();
  _result = _reply.readint();
 } finally {
  _reply.recycle();
  _data.recycle();
 }
 return _result;
}

核心方法是mremote.transact(stub.transaction_add, _data, _reply, 0);。这里的mremote是客户端拿到的binderproxy对象,然后就要开始跨进程传输了。又到了黑盒子出现的时候了,客户端发起跨进程通信后,服务端就会在自己进程的ontranscat()方法中收到通知:

@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_add : {
   data.enforceinterface(descriptor);
   int _arg0;
   _arg0 = data.readint();
   int _arg1;
   _arg1 = data.readint();
   int _result = this.add(_arg0, _arg1);
   reply.writenoexception();
   reply.writeint(_result);
   return true;
  } default: {
  return super.ontransact(code, data, reply, flags);
  }
 }
}

在server端收到信息后,会先通过parcel将信息解析出来,然后执行我们调用的add()方法,也就是我们在remoteservice中重写imath.stub的add()方法。最后将结果写回parcel中再跨进程传回给客户端,从而完成了一次跨进程通信。
如果看到这里,对于binder的流程还有疑惑的话,那就再来一张时序图好了。

Android Binder入门学习笔记

binder

看图说话,当我们在客户端中去bindservice()的时候,server端在onbind()中返回了一个binder对象,经过binder驱动的转换,这个binder到了客户端中变成了binderproxy,客户端接着再把binderproxy转换成stub.proxy,后面我们与server的跨进程通信就都是通过stub.proxy发起的,然后binder驱动会帮我们将数据跨进程传输给真正的binder,binder执行完操作后再将结果写入由binder驱动传回来。由此完成了一次跨进程通信。

从图中我们也可以看出通信过程是同步的。当客户端发起请求的同时,当前的线程会被挂起,直到结果返回。所以要注意的是如果请求太耗时的话,不应该在主线程中去请求,否则容易出现anr。给个systrace直观感受一下。

Android Binder入门学习笔记

systrace

相应的cpu信息是处于休眠状态的。

Android Binder入门学习笔记

cpu

最后

掌握了binder的上层原理之后,后面再来深入framework层学习就会简单一些,这篇文章也是为了后面的学习打下基础。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对的支持。