Head First设计模式读书笔记十 第十一章 代理模式

之前的总结链接
https://blog.csdn.net/u011109881/article/details/59191308

代理模式本身的框架结构并不难理解，但是在实际应用中，我们往往被实际应用的复杂外表所欺骗，而看不到代理模式的本质。比如HEAD First书中的RMI远程代理的例子，或者是Android中跨进程的AIDL的例子。我们往往会困惑于远程代理是如何实现的，Android里面是如何跨进程的。事实上，如果我们暂且不讨论这些原理性问题，而只是看框架结构的话，会发现他们其实本质都很清晰，都是使用了代理模式的框架。

代理模式举例（远程代理AIDL）

因为对RMI的原理不是很了解，所以就拿我稍微熟悉一些的AIDL来作为代理模式的例子吧。
我自己也写过一些AIDL的例子，但是感觉没有大神写的经典，so，还是举这个例子吧：
https://blog.csdn.net/lmj623565791/article/details/38461079/
注意：原文注重的时AIDL的原理分析，而我这里注重的时AIDL的框架结构。
原文中AIDL分为客户端和服务端
步骤：

• 1.创建ICalcAIDL.aidl文件（决定了生成文件的实际内容，相当于Stub类的定义，类似于声明）
• 2.系统会根据ICalcAIDL.aidl自动生成ICalcAIDL.java的java文件（起实际作用的类）
• 3.创建CalcService.java在服务端作为客户端的服务（用于返回ICalcAIDL.Stub的实例，即binder对象）

服务器端就这么多
客户端：

• 1.布局+Activity。activity的作用就是获取服务端的代理，利用代理调用服务器的方法

执行流程：

• 客户端点击bind按钮，activity请求远程服务。
• 服务器端onCreate创建服务，onBind触发，返回binder对象

（注意binder对象是ICalcAIDL.Stub的实例，具体返回是通过ICalcAIDL.java中return new com.zhy.calc.aidl.ICalcAIDL.Stub.Proxy(obj);的方式返回的）
这个返回的binder其实就是服务端的代理，通过这个binder，可以访问服务器的方法。
工作流程图如下：

也可以参考我之前写的AIDL相关生成文件的流程解析
https://blog.csdn.net/u011109881/article/details/78544123

拿到这个binder对象后，这个binder就成了服务器代理，以调用Add为例，调用流程如下：

• 客户端调用binder的add方法，客户端transact方法调用，客户端挂起
• 服务端onTransact调用，根据客户端transact方法的参数判断调用的具体是哪个方法，并返回结果
• 客户端收到结果，挂起终了，继续处理返回结果
  在此过程中，binder充当了服务器端的代理，客服端看上去好像直接调用了服务器端的方法，其实只是告诉代理对象binder自己想调用什么方法，并传入参数，最后实际调用的方法仍然是服务器上的方法。
  

代理模式的通常结构

对比AIDL的例子，可以看到根据aidl生成的文件中包含内部类private static class Proxy，这个Proxy继承了实现了ICalcAIDL接口（鸿洋大神的博客里面看不出来，但是自己写的demo话可以看到），而Service对象内部也有一个ICalcAIDL.Stub的实例，所以Proxy看起来才和Service一样。

代理模式的几个应用场景

代理模式最大的特点是调用者无法直接访问被调用者，中间隔了一个代理对象，相当于一个类似中介的对象。利用这个特点可以做到如下功能：
1.限制调用者，只给调用者有限的访问权限，这也是常说的访问控制。
2.通过代理对象实现跨进程调用，即远程代理。
3.当创建对象的开销很大时，我们往往会创建一个虚拟代理，虚拟代理可以处理一些简单的请求，但有些东西只有真实对象才能进行。但是由于真实对象创建非常耗资源，只有当必要时刻才会创建真实对象，以节省资源。真实对象创建前和创建中，均由代理类充当真实对象。即虚拟代理