很多人一提到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的代码里面，经常把这个能代表远程对象的东西叫做代理。仅此而已。只要能代表远程对象并执行函数。那么就叫做代理。具体怎么实现的，并不关心。在这里代理只是一种脱离实际代码的宏愿。
