Android Binder入门学习笔记_android教程

上一篇: Android Handler机制的工作原理详... 下一篇:Android启动优化之延时加载的步骤...

Android Binder入门学习笔记

发布时间：2019-08-08 发布网站：脚本宝典

脚本宝典收集整理的这篇文章主要介绍了Android Binder入门学习笔记，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

写在前面

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&#63;) {   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的流程还有疑惑的话，那就再来一张时序图好了。

@H_221_126@

binder

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

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

Android Binder入门学习笔记