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就帮我们查询一次,有票的话就帮我们下单。这里就以抢火车票为例来说明代理模式的结构。
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文件中,代码有点乱,整理一下之后,结构大致是这样子的:
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的流程还有疑惑的话,那就再来一张时序图好了。
binder
看图说话,当我们在客户端中去bindService()的时候,Server端在onBind()中返回了一个Binder对象,经过Binder驱动的转换,这个Binder到了客户端中变成了BinderProxy,客户端接着再把BinderProxy转换成Stub.Proxy,后面我们与Server的跨进程通信就都是通过Stub.Proxy发起的,然后Binder驱动会帮我们将数据跨进程传输给真正的Binder,Binder执行完操作后再将结果写入由Binder驱动传回来。由此完成了一次跨进程通信。
从图中我们也可以看出通信过程是同步的。当客户端发起请求的同时,当前的线程会被挂起,直到结果返回。所以要注意的是如果请求太耗时的话,不应该在主线程中去请求,否则容易出现ANR。给个Systrace直观感受一下。
Systrace
相应的CPU信息是处于休眠状态的。
cpu
最后
掌握了Binder的上层原理之后,后面再来深入Framework层学习就会简单一些,这篇文章也是为了后面的学习打下基础。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对脚本之家的支持。
相关文章
Android UI自定义ListView实现下拉刷新和加载更多效果
这篇文章主要介绍了Android UI自定义ListView实现下拉刷新和加载更多效果,具有一定的参考价值,感兴趣的小伙伴们可以参考一下2016-11-11android 中使用TableLayout实现表单布局效果示例
本篇文章主要介绍了android 中使用TableLayout实现表单布局效果示例,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧2018-06-06Android App中用Handler实现ViewPager页面的自动切换
这篇文章主要介绍了Android App中用Handler实现ViewPager页面的自动切换的方法,类似于相册自动播放,主要是切换后要提示当前页面所在的位置,需要的朋友可以参考下2016-05-05Android Studio preview 不固定及常见问题的解决办法
preview 可以帮助您预览您的布局文件将如何在用户的设备上呈现。这篇文章主要介绍了Android Studio preview 不固定及常见问题的解决办法,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧2018-05-05
最新评论