代码的分离与解耦，向移动架构师进阶！

1、代理概念

为某个对象提供一个代理，以控制对这个对象的访问。 代理类和委托类有共同的父类或父接口，这样在任何使用委托类对象的地方均可以用代理对象替代。代理类负责请求的预处理、过滤、将请求分派给委托类处理、以及委托类执行完请求后的后续处理。

图1：代理模式

从图中能够看出，代理接口（Subject）、代理类（ProxySubject）、委托类（RealSubject）造成一个“品”字结构。

根据代理类的生成时间不一样能够将代理分为静态代理和动态代理两种。

下面以一个模拟需求说明静态代理和动态代理：委托类要处理一项耗时较长的任务，客户类须要打印出执行任务消耗的时间。解决这个问题须要记录任务执行前时间和任务执行后时间，两个时间差就是任务执行消耗的时间

2、静态代理

由咱们本身建立或工具生成代理类的源码，再编译代理类。所谓静态也就是在程序运行前就已经存在代理类的字节码文件，代理类和委托类的关系在运行前就肯定了

1：代理接口

/** 
 * 代理类，实现了代理接口。 
 */  
public class ProxySubject implements Subject {  
 //代理类持有一个委托类的对象引用  
 private Subject delegate;  

 public ProxySubject(Subject delegate) {  
  this.delegate = delegate;  
 }  

 /** 
  * 将请求分派给委托类执行，记录任务执行先后的时间，时间差即为任务的处理时间 
  *  
  * @param taskName 
  */  
 @Override  
 public void dealTask(String taskName) {  
  long stime = System.currentTimeMillis();   
  //将请求分派给委托类处理  
  delegate.dealTask(taskName);  
  long ftime = System.currentTimeMillis();   
  System.out.println("执行任务耗时"+(ftime - stime)+"毫秒");  

 }  
}  

复制代码

清单3：静态代理类

public class SubjectStaticFactory {  
 //客户类调用此工厂方法得到代理对象。  
 //对客户类来讲，其并不知道返回的是代理类对象仍是委托类对象。  
 public static Subject getInstance(){   
  return new ProxySubject(new RealSubject());  
 }  
}  

复制代码

清单4：生成静态代理类工厂

public class SubjectStaticFactory {  
 //客户类调用此工厂方法得到代理对象。  
 //对客户类来讲，其并不知道返回的是代理类对象仍是委托类对象。  
 public static Subject getInstance(){   
  return new ProxySubject(new RealSubject());  
 }  
}  

复制代码

清单5：客户类

public class Client1 {  

 public static void main(String[] args) {  
  Subject proxy = SubjectStaticFactory.getInstance();  
  proxy.dealTask("DBQueryTask");  
 }   

} 

复制代码

静态代理类优缺点

优势：业务类只须要关注业务逻辑自己，保证了业务类的重用性。这是代理的共有优势。 缺点： 1）代理对象的一个接口只服务于一种类型的对象，若是要代理的方法不少，势必要为每一种方法都进行代理，静态代理在程序规模稍大时就没法胜任了。 2）若是接口增长一个方法，除了全部实现类须要实现这个方法外，全部代理类也须要实现此方法。增长了代码维护的复杂度。

3、动态代理

动态代理类的源码是在程序运行期间由JVM根据反射等机制动态的生成，因此不存在代理类的字节码文件。代理类和委托类的关系是在程序运行时肯定。

一、先看看与动态代理紧密关联的Java API。 1）java.lang.reflect.Proxy 这是 Java 动态代理机制生成的全部动态代理类的父类，它提供了一组静态方法来为一组接口动态地生成代理类及其对象。

Proxy类的静态方法

// 方法 1: 该方法用于获取指定代理对象所关联的调用处理器  
static InvocationHandler getInvocationHandler(Object proxy)   

// 方法 2：该方法用于获取关联于指定类装载器和一组接口的动态代理类的类对象  
static Class getProxyClass(ClassLoader loader, Class[] interfaces)   

// 方法 3：该方法用于判断指定类对象是不是一个动态代理类  
static boolean isProxyClass(Class cl)   

// 方法 4：该方法用于为指定类装载器、一组接口及调用处理器生成动态代理类实例  
static Object newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler h)   

复制代码

java.lang.reflect.InvocationHandler 这是调用处理器接口，它自定义了一个 invoke 方法，用于集中处理在动态代理类对象上的方法调用，一般在该方法中实现对委托类的代理访问。每次生成动态代理类对象时都要指定一个对应的调用处理器对象。

清单7：InvocationHandler的核心方法

// 该方法负责集中处理动态代理类上的全部方法调用。第一个参数既是代理类实例，第二个参数是被调用的方法对象  
// 第三个方法是调用参数。调用处理器根据这三个参数进行预处理或分派到委托类实例上反射执行  
Object invoke(Object proxy, Method method, Object[] args)  

复制代码

java.lang.ClassLoader

具体步骤是： a. 实现InvocationHandler接口建立本身的调用处理器 b. 给Proxy类提供ClassLoader和代理接口类型数组建立动态代理类 c. 以调用处理器类型为参数，利用反射机制获得动态代理类的构造函数 d. 以调用处理器对象为参数，利用动态代理类的构造函数建立动态代理类对象

清单8：分步骤实现动态代理

// InvocationHandlerImpl 实现了 InvocationHandler 接口，并能实现方法调用从代理类到委托类的分派转发  
// 其内部一般包含指向委托类实例的引用，用于真正执行分派转发过来的方法调用  
InvocationHandler handler = new InvocationHandlerImpl(..);   

// 经过 Proxy 为包括 Interface 接口在内的一组接口动态建立代理类的类对象  
Class clazz = Proxy.getProxyClass(classLoader, new Class[] { Interface.class, ... });   

// 经过反射从生成的类对象得到构造函数对象  
Constructor constructor = clazz.getConstructor(new Class[] { InvocationHandler.class });   

// 经过构造函数对象建立动态代理类实例  
Interface Proxy = (Interface)constructor.newInstance(new Object[] { handler });   

复制代码

Proxy类的静态方法newProxyInstance对上面具体步骤的后三步作了封装，简化了动态代理对象的获取过程。

清单9：动态代理实现示例

/** 
 * 动态代理类对应的调用处理程序类 
 */  
public class SubjectInvocationHandler implements InvocationHandler {  

 //代理类持有一个委托类的对象引用  
 private Object delegate;  

 public SubjectInvocationHandler(Object delegate) {  
  this.delegate = delegate;  
 }  

 @Override  
 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {  
  long stime = System.currentTimeMillis();   
  //利用反射机制将请求分派给委托类处理。Method的invoke返回Object对象做为方法执行结果。  
  //由于示例程序没有返回值，因此这里忽略了返回值处理  
  method.invoke(delegate, args);  
  long ftime = System.currentTimeMillis();   
  System.out.println("执行任务耗时"+(ftime - stime)+"毫秒");  

  return null;  
 }  
}   

复制代码

动态代理机制特色

首先是动态生成的代理类自己的一些特色。 1）包：若是所代理的接口都是 public 的，那么它将被定义在顶层包（即包路径为空），若是所代理的接口中有非 public 的接口（由于接口不能被定义为 protect 或 private，因此除 public 以外就是默认的 package 访问级别），那么它将被定义在该接口所在包（假设代理了 com.ibm.developerworks 包中的某非 public 接口 A，那么新生成的代理类所在的包就是 com.ibm.developerworks），这样设计的目的是为了最大程度的保证动态代理类不会由于包管理的问题而没法被成功定义并访问；

2）类修饰符：该代理类具备 final 和 public 修饰符，意味着它能够被全部的类访问，可是不能被再度继承；

3）类名：格式是“$ProxyN”，其中 N 是一个逐一递增的阿拉伯数字，表明 Proxy 类第 N 次生成的动态代理类，值得注意的一点是，并非每次调用 Proxy 的静态方法建立动态代理类都会使得 N 值增长，缘由是若是对同一组接口（包括接口排列的顺序相同）试图重复建立动态代理类，它会很聪明地返回先前已经建立好的代理类的类对象，而不会再尝试去建立一个全新的代理类，这样能够节省没必要要的代码重复生成，提升了代理类的建立效率。

4）类继承关系：该类的继承关系如图：

由图可见，Proxy 类是它的父类，这个规则适用于全部由 Proxy 建立的动态代理类。并且该类还实现了其所代理的一组接口，这就是为何它可以被安全地类型转换到其所代理的某接口的根本缘由。

接下来让咱们了解一下代理类实例的一些特色。每一个实例都会关联一个调用处理器对象，能够经过 Proxy 提供的静态方法 getInvocationHandler 去得到代理类实例的调用处理器对象。在代理类实例上调用其代理的接口中所声明的方法时，这些方法最终都会由调用处理器的 invoke 方法执行，此外，值得注意的是，代理类的根类 java.lang.Object 中有三个方法也一样会被分派到调用处理器的 invoke 方法执行，它们是 hashCode，equals 和 toString，可能的缘由有：一是由于这些方法为 public 且非 final 类型，可以被代理类覆盖；二是由于这些方法每每呈现出一个类的某种特征属性，具备必定的区分度，因此为了保证代理类与委托类对外的一致性，这三个方法也应该被分派到委托类执行。当代理的一组接口有重复声明的方法且该方法被调用时，代理类老是从排在最前面的接口中获取方法对象并分派给调用处理器，而不管代理类实例是否正在以该接口（或继承于该接口的某子接口）的形式被外部引用，由于在代理类内部没法区分其当前的被引用类型。

接着来了解一下被代理的一组接口有哪些特色。首先，要注意不能有重复的接口，以免动态代理类代码生成时的编译错误。其次，这些接口对于类装载器必须可见，不然类装载器将没法连接它们，将会致使类定义失败。再次，需被代理的全部非 public 的接口必须在同一个包中，不然代理类生成也会失败。最后，接口的数目不能超过 65535，这是 JVM 设定的限制。

最后再来了解一下异常处理方面的特色。从调用处理器接口声明的方法中能够看到理论上它可以抛出任何类型的异常，由于全部的异常都继承于 Throwable 接口，但事实是否如此呢？答案是否认的，缘由是咱们必须遵照一个继承原则：即子类覆盖父类或实现父接口的方法时，抛出的异常必须在原方法支持的异常列表以内。因此虽然调用处理器理论上讲可以，但实际上每每受限制，除非父接口中的方法支持抛 Throwable 异常。那么若是在 invoke 方法中的确产生了接口方法声明中不支持的异常，那将如何呢？放心，Java 动态代理类已经为咱们设计好了解决方法：它将会抛出 UndeclaredThrowableException 异常。这个异常是一个 RuntimeException 类型，因此不会引发编译错误。经过该异常的 getCause 方法，还能够得到原来那个不受支持的异常对象，以便于错误诊断。

五、动态代理的优势和美中不足

优势：

动态代理与静态代理相比较，最大的好处是接口中声明的全部方法都被转移到调用处理器一个集中的方法中处理（InvocationHandler.invoke）。这样，在接口方法数量比较多的时候，咱们能够进行灵活处理，而不须要像静态代理那样每个方法进行中转。在本示例中看不出来，由于invoke方法体内嵌入了具体的外围业务（记录任务处理先后时间并计算时间差），实际中能够相似

美中不足：

诚然，Proxy 已经设计得很是优美，可是仍是有一点点小小的遗憾之处，那就是它始终没法摆脱仅支持 interface 代理的桎梏，由于它的设计注定了这个遗憾。回想一下那些动态生成的代理类的继承关系图，它们已经注定有一个共同的父类叫 Proxy。Java 的继承机制注定了这些动态代理类们没法实现对 class 的动态代理，缘由是多继承在 Java 中本质上就行不通。

有不少条理由，人们能够否认对 class 代理的必要性，可是一样有一些理由，相信支持 class 动态代理会更美好。接口和类的划分，本就不是很明显，只是到了 Java 中才变得如此的细化。若是只从方法的声明及是否被定义来考量，有一种二者的混合体，它的名字叫抽象类。实现对抽象类的动态代理，相信也有其内在的价值。此外，还有一些历史遗留的类，它们将由于没有实现任何接口而今后与动态代理永世无缘。如此种种，不得不说是一个小小的遗憾。

更多阅读

跳槽能够，但请保持正确姿式！

react-native技术的优劣

金三银四跳槽季，阿里面试刚回来的总结—干货！

相信本身，没有作不到的，只有想不到的

微信公众号：终端研发部