介绍
代理模式也称为委托模式，是一种结构性设计模式。
说到代理，可能大部分人都会有一种陌生又熟悉的感觉，日常生活中好像都能遇到，比如代理上网，招商代理，商务代理等；但又说不出个具体的一二三来；代理这个事情如果我们换个角度，从委托者的角色出发，我们找代理上网，是因为我们在访问某些网站时存在困难，需要有个角色来间接的帮我们实现这个功能；我们找商务代理，可能是因为许多事我们不在行或者其他原因，需要找专业的中间人来帮我们做事。因此，日常生活中我们更多扮演的是委托人的角色，代理以一种中间人的角色，帮我们是处理我们无能为力的事情。
如果从写代码的角度出发，当我们遇到以下场景：
- 无法直接访问某个对象
- 不想直接访问某个对象
- 访问某个对象存在困难
的时候，我们就可以通过一个代理，通过它来间接访问真正的对象。
定义及UML图
定义：
为目标对象提供一种代理，客户端通过代理去访问目标对象。
UML 图
从代理模式的UML 类图中，我们可以得到如下结论：
- 代理对象和委托对象需要实现相同的接口（抽象类）
- 代理对象持有委托对象的引用
可以看到，代理模式非常简洁，总共就三个角色，包括抽象主题，委托者和代理者，下面用代码简单实现一下基础的代理模式。
public interface Subject {
void doSomething();
}
public class RealSubject implements Subject {
@Override
public void doSomething() {
System.out.println("This is real doSomeThing");
}
}
public class ProxySubject implements Subject {
private Subject mSubject;
// 代理类持有委托类的引用
public ProxySubject(Subject realSubject) {
mSubject = realSubject;
}
@Override
public void doSomething() {
mSubject.doSomething();
}
}
public class Client {
public static void main(String[] args) {
//创建委托类
Subject mRealSubject=new RealSubject();
//创建代理类
ProxySubject mProxy = new ProxySubject(mRealSubject);
//由代理类去做具体的操作
mProxy.doSomething();
}
}
可以看到RealSubject和ProxySubject都实现了接口Subject。在客户端使用ProxySubject的实例调用doSomething方法，而不是使用RealSubject的实例来实现。
你可能会好奇，这么做的意义是什么呢？直接用RealSubject的实例来调用doSomething方法不也可以吗？何必多此一举。试想，如果现在有很多个委托类，他们各自的实现都不同，客户端只关心doSomething 的调用，而不关心具体的实现，这样代理类就可以在其内部屏蔽委托类之间的差异了，这也是客户端不想关注的事情。这么说可能有点晕，下面就通过Android源码中的实现来感受一下。
Android 中的代理模式
平时写代码的时候，可能感觉代理模式没怎么遇到过。其实不然，甚至可以说代理模式是我们最常用到的一种设计模式。这里就来看看几乎天天都在使用的AppCompatActivity。
最早的时候，我们创建自己的Activity都是直接继承android.app.Activity。后来随着Android版本的升级，我们创建的Activity会继承AppCompatActivity。这里的Compat其实就是Compatible(兼容)的缩写，那么他是怎么实现兼容的呢。
onCreate
onCreate()方法是整个Activity生命周期的开始。AppCompatActivity又是怎么实现他的呢。
AppCompatActivity-onCreate()
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
final AppCompatDelegate delegate = getDelegate();
delegate.installViewFactory();
delegate.onCreate(savedInstanceState);
……
}
可以看到这里他并没具体去实现onCreate,而是使用一个AppCompatDelegate实例的onCreate()方法去实现。继续看getDelegate 的实现。
AppCompatActivity-getDelegate()
@NonNull
public AppCompatDelegate getDelegate() {
if (mDelegate == null) {
mDelegate = AppCompatDelegate.create(this, this);
}
return mDelegate;
}
可以看到这个实例创建是在AppCompatDelegate类中。接着看create的实现
AppCompatDelegate-create()
public static AppCompatDelegate create(Activity activity, AppCompatCallback callback) {
return create(activity, activity.getWindow(), callback);
}
private static AppCompatDelegate create(Context context, Window window,
AppCompatCallback callback) {
if (Build.VERSION.SDK_INT >= 24) {
return new AppCompatDelegateImplN(context, window, callback);
} else if (Build.VERSION.SDK_INT >= 23) {
return new AppCompatDelegateImplV23(context, window, callback);
} else if (Build.VERSION.SDK_INT >= 14) {
return new AppCompatDelegateImplV14(context, window, callback);
} else if (Build.VERSION.SDK_INT >= 11) {
return new AppCompatDelegateImplV11(context, window, callback);
} else {
return new AppCompatDelegateImplV9(context, window, callback);
}
}
可以看到，这里就不同的Android版本，分别返回了不同的AppCompatDelegate。如果去看源码（这里的源码分析不是重点，就不贴出了，直接给出结论），我们会发现，从
AppCompatDelegateImplN到AppCompatDelegateImplV9，是子类到父类的关系，之间是依次继承。而AppCompatDelegateImplV9又继承自AppCompatDelegateImplBase（抽象类），而这个AppCompatDelegateImplBase则是继承自AppCompatDelegate。
到这里，结合一开始我们所说的代理模式的内容，我们很容易总结出以下结论：
- AppCompatDelegate 同时兼顾了抽象主题和代理类的角色
- AppCompatDelegateImplN，AppCompatDelegateImplV23等这些都是委托类，他们都继承自AppCompatDelegate方法。
通过AppCompatDelegate.java(点击可直接查看)的源码，我们可以发现，这个抽象类内部定义了一系列和 Activity 相关的抽象方法，包括Activity生命周期函数，setContentView，setSupportActionBar等。我们知道，子类通过继承父类，可以扩展（spuer)或直接覆盖父类的方法实现。 AppCompatDelegateImplV9 这个类是AppCompatDelegate的具体实现，之后的版本，就可以通过继承AppCompatDelegateImplV9来扩展或修改一些方法实现，通过AppCompatDelegate 在create方法中创建不同的委托类来完成不同的实现，而我们原先写好的代码也不会被破坏，可以看到Android源码对Activity兼容这个事做的非常巧妙。AppCompatDelegate主要是对ActionBar的兼容及夜间模式的处理做了一些方便开发者实现的处理；这里就不再具体分析了。
当然，代理模式这个几乎找不到缺点的设计模式，在Android源码中的应用也是比较广泛，基本上关于兼容性的实现，都会用到以上思路，比如NotificationCompatImpl几乎使用了和AppCompatDelegate同样的思路，实现了在手机通知栏中实现不同的通知样式。除了兼容性的处理，另外一个比较经典的实现就是Binder了，作为跨进程通信的核心理念，Binder巧妙的使用了代理模式，处理了我们无法在不同应用之间共享和传递数据的问题。关于Binder的分析，网上真的太多了，这里就不再赘述了，有兴趣的同学可以看看这篇代理模式在Binder中的使用.
动态代理
以上的分析中，委托类是由我们直接创建好的；现实中可能还有这样一种场景，委托类并不是在程序编译的时候创建，而是在运行的过程中通过Java的反射机制动态的进行创建，这样的代理模式成为动态代理，对应的之前我们所说的就是静态代理了。
其实，动态代理的实现没有什么可说的，说白了都是模板代码，Java为开发者提供了InvocationHandler,实现该接口重写其invoke 方法即可。
还是以之前的Subject为例
public interface Subject {
void doSomething();
}
public class RealSubject implements Subject {
@Override
public void doSomething() {
System.out.println("This is real doSomeThing");
}
}
public class DynamicProxyHandler implements InvocationHandler {
private Object mObject;
public DynamicProxyHandler(Object object) {
mObject = object;
}
@Override
public Object invoke(Object o, Method method, Object[] objects) throws Throwable {
return method.invoke(mObject, objects);
}
}
public class MainClass {
public static void main(String[] args) {
// 委托类
Subject mRealSubject = new RealSubject();
// 委托类classLoader
ClassLoader mClassLoader = mRealSubject.getClass().getClassLoader();
// 委托类对应的ProxyHandler
DynamicProxyHandler mProxyHandler = new DynamicProxyHandler(mRealSubject);
Class[] mClasses = new Class[]{Subject.class};
// 代理类
Subject proxySubject = (Subject) Proxy.newProxyInstance(mClassLoader, mClasses, mProxyHandler);
// 代理类调用方法
proxySubject.doSomething();
}
}
这里可以看到，DynamicProxyHandler内部持有的并不是一个具体的对象，而是Object类，而在其invoke方法中，又会根据具体的Object对象及参数调用其对应的方法。这样当我们在客户端调用时，完全是根据委托类通过Proxy.newProxyInstance方法动态的创建代理类。在上面的代码中，我们是通过委托类RealSubject动态的创建了一个代理类，通过代理类调用抽象主题中定义好的方法，实际上就会调用委托类中的具体实现。而在Java中，我们可以通过反射机制，动态的创建类及其实例，因此，我们便可以在运行时通过不同的委托类，更灵活的创建代理类，从而实现不同的功能。
关于动态代理，这篇十分钟理解Java之动态代理分析的非常好，有兴趣的同学可以再看看。
在Android中，关于动态代理的使用，最经典的莫过于这几年最火热的Retrofit了。这里可以简单看一下。
public interface GitHubService {
@GET("users/{user}/repos")
Call<List<Repo>> listRepos(@Path("user") String user);
}
GitHubService service = retrofit.create(GitHubService.class);
Call<List<Repo>> repos = service.listRepos("octocat");
上面的实现，现在大家应该很熟悉了，当我们用Retrofit实例，调用其create方法时，到底发生了什么呢？
public <T> T create(final Class<T> service) {
Utils.validateServiceInterface(service);
if (validateEagerly) {
eagerlyValidateMethods(service);
}
return (T) Proxy.newProxyInstance(service.getClassLoader(), new Class<?>[] { service },
new InvocationHandler() {
private final Platform platform = Platform.get();
@Override public Object invoke(Object proxy, Method method, @Nullable Object[] args)
throws Throwable {
// If the method is a method from Object then defer to normal invocation.
if (method.getDeclaringClass() == Object.class) {
return method.invoke(this, args);
}
if (platform.isDefaultMethod(method)) {
return platform.invokeDefaultMethod(method, service, proxy, args);
}
ServiceMethod<Object, Object> serviceMethod =
(ServiceMethod<Object, Object>) loadServiceMethod(method);
OkHttpCall<Object> okHttpCall = new OkHttpCall<>(serviceMethod, args);
return serviceMethod.callAdapter.adapt(okHttpCall);
}
});
}
可以看到，这里就是一个典型的动态代理实现，通过serviceMethod.callAdapter.adapt返回了一个service对象的代理对象，在上面的例子里，就是返回了一个GitHubService的代理对象，这样我们就可以通过这样一个对象去调用GitHubService中定义好的各种网络请求，而不用在使用的时候再去决定是POST请求还是GET请求,参数是放在Body里还是params里，因为Retrofit 通过把反射注解和动态代理的巧妙结合，屏蔽了复杂的参数拼接操作，把所有我们需要对OKHttp的进行传递的参数，动态的帮我们传递了，一旦在接口中定义好了使用方式，就可以非常方便的获取到okhttp中最关键的Call了，有了Call我们就可以通过execute或者是enqueue发起网络请求了。
总结
以上就是对代理模式的分析，总的来说代理模式的结构非常简单；包括抽象主题，委托类，代理类三个核心角色，从大的方向上可以分为静态代理和动态代理两大类；通过静态代理的方式，在开发迭代的过程中，为实现兼容性提供了一种非常友好的实现思路；在日常开发中，如果我们使用的对象之间有着强烈的耦合，可是思考一下是否可以通过代理模式解耦；同时，当我们需要扩展某个类的部分功能时，但又不想去破坏原有的功能或者是根本无法修改时，我们可以考虑代理模式，但也要明白，通过代理模式我们能做的也只能是功能扩展，想要更新委托类中已经实现的内容他是无能为力的。
动态代理，可以根据运行时的委托类动态的生成代理类，这样就减轻了代理类的负担，避免在编码阶段就具体的委托类再做各种判断了。
代理模式很简单，也很实用，但不要忘记代理类和委托类需要实现功能的接口或抽象类，不要忽略了这一点。
好了，关于代理模式的分析就到这里了
