安卓高手之路之java层Binder_移动开发_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > 移动开发 > 安卓高手之路之java层Binder

安卓高手之路之java层Binder

 2014/10/21 17:37:27  xiaochao1234  程序员俱乐部  我要评论(0)
  • 摘要:很多人一提到Binder就说代理模式,人云亦云的多,能理解精髓的少。本篇文章就从设计角度分析一下java层BInder的设计目标,以及设计思路,设计缺陷,从而驾驭它。对于【邦德儿】的理解,从通信的角度来看,就是一种通信方式而已,与socket没有任何区别。客户端transact,服务端onTransact.但是,从【邦德儿】本身来说,如果客户端和服务端在一个进程,那么再通过底层驱动去把数据转过去就显得多余了。基于这种理论,设计的时候,如果客户端和服务端在一个进程就直接函数调用,而不再通过驱动
  • 标签:Java 高手

     很多人一提到Binder就说代理模式,人云亦云的多,能理解精髓的少。 本篇文章就从设计角度分析一下java层BInder的设计目标,以及设计思路,设计缺陷,从而驾驭它。

     对于【邦德儿】的理解, 从通信的角度来看,就是一种通信方式而已,与socket没有任何区别。客户端transact,服务端onTransact.  但是,从【邦德儿】本身来说,如果客户端和服务端在一个进程,那么再通过底层驱动去把数据转过去就显得多余了。基于这种理论,设计的时候,如果客户端和服务端在一个进程就直接函数调用,而不再通过驱动。对于调用者来说,他只需要得到一个接口用来transact。并不愿意知道具体的通信细节。也就是说,不关心是否是通过【邦德儿】驱动来传输的,还是直接在同进程通过函数的调用传输的。调用者确实不愿意关心,调用者不愿意关心的,那么被调用者就得关心,不然代码谁来写。所以【邦德儿】本身必须要处理这两种情况:

        1.在同一个进程。这个对应的是Binder。

        2.不在同一个进程。这个对应的是BInderProxy。

    对于调用者来说,这两个东西都实现了IBinder接口中的transact函数。BInderProxy通过底层驱动,把数据传输到服务端而BInder则直接通过内部调用转给onTransact处理。

    附注:

在这里吐槽一下google。命名莫名其妙故弄玄虚。看到一个IBinder,脑子里除了邦德儿之外没有别的想法。我觉得,在设计上transact应该对应一个ISenderBinder,而onTransact对应一个IReceiverBinder。Binder实现了ISenderBinder和IReceiverBinder接口。这样的逻辑才够清晰。客户端只要看到ISenderBinder就倍感亲切,服务端只要看到IReceiverBinder就感觉自己在为别人做好事。一开始要做的事情就是打开通信通道,也就是把ISenderBinder这个东西对应的对象传给客户端。而服务端用谁进行服务都无所谓,只要是跟ISenderBinder是一对的就OK。BInderProxy应该叫做SenderBinder才合适。

 

 

       那么对于应用程序来说,他需要什么?他需要函数调用,而不是transact这类东西。如果整天关心这些底层的打包解包那么也就很头大了。IActivityManager这个是用户需要的接口,之前的transact接口明显不合适让用户使用。把恶心的transact函数适配到IActivityManager。用户用起来更好用了。既然是适配,那么就有个接口转换。一个叫做asInterface,一个叫做asBInder。网上一讲这个东西就说是代理。这是其实是适配。asInterface将IBinder适配为IActivityManager。而asBInder将IActivityManager适配为IBinder。

       google的代码里面,经常把这个能代表远程对象的东西叫做代理。仅此而已。只要能代表远程对象并执行函数。那么就叫做代理。具体怎么实现的,并不关心。在这里代理只是一种脱离实际代码的宏愿。

 

发表评论
用户名: 匿名