朋友让你做网站如何拒绝,wordpress首页新闻显示数量,项目建设管理办法,手机app下载网很多人一提到Binder就说代理模式#xff0c;人云亦云的多#xff0c;能理解精髓的少。 本篇文章就从设计角度分析一下java层BInder的设计目标#xff0c;以及设计思路#xff0c;设计缺陷#xff0c;从而驾驭它。 对于【邦德儿】的理解, 从通信的角度来看#xff0c;就是… 很多人一提到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的代码里面经常把这个能代表远程对象的东西叫做代理。仅此而已。只要能代表远程对象并执行函数。那么就叫做代理。具体怎么实现的并不关心。在这里代理只是一种脱离实际代码的宏愿。 转载于:https://www.cnblogs.com/android-blogs/p/5420312.html
