运用动态代理来提高代码的灵活性

前言

本文会简单介绍下 Java 中动态代理模式的使用，然后着重分享下动态代理如何在提高代码灵活性方面大展身手。文中会列举两个实例，一个是在 MVP 中如何巧妙解决 Presenter 中频繁使用 if (getView() != null) { } 这种重复代码的问题；另一个是在项目中如何让多个 modules 间解耦更加灵活、更加纯粹的问题。

动态代理的基本使用

要使用动态代理，主要涉及到两个类，一个是 Proxy 类，一个是 InvocationHandler 类。在介绍如何使用之前，需要明确的是：动态代理的代理对象只能是 Interface，不能是 Class ，也不能是 abstract class。这是因为所有动态生成的代理类都继承自 Proxy。而 java 是单继承的，所以只有接口对象能被动态代理。

回到刚才介绍的两个类，Proxy 描述了一个代理对象，同时它提供了创建并实例化一个代理对象的静态方法。InvocationHandler 是一个代理对象的调用处理器，它只有一个 invoke 方法，所有被代理的对象的方法调用都会通过这个方法执行，我们的代理行为也就是在这个方法里面实现的。下面给出一个很简单的示例：

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public class DemonstrationProxy {

    interface A {
        void method();
    }


    static class AIpml implements A {

        @Override
        public void method() {
            System.out.println("method in AIpml");
        }
    }

    //动态代理对象
    static class AProxy implements InvocationHandler {
        
        //被代理的对象实例
        final Object origin;

        AProxy(Object origin) {
            this.origin = origin;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            System.out.println("start to invoke method " + method.getName() + " proxy is " + proxy.getClass().getCanonicalName());
            //执行实际对象的方法
            return method.invoke(origin, args);
        }
    }

    public static void main(String[] args) {
        final A a = new AIpml();
        final InvocationHandler handler = new AProxy(a);
        final A proxyA = (A) Proxy.newProxyInstance(a.getClass().getClassLoader(), a.getClass().getInterfaces(), handler);
        proxyA.method();
    }
}

编译运行后你将看到如下输出：

start to invoke method proxy is $Proxy0
method in AIpml

MVP 中如何精简不必要的代码

在 MVP 的开发模式中，Presenter 持有 View 的引用，当我们需要与 View 进行交互时，通过 getView() 方法获得 View 对象。为了避免内存泄漏，在不需要 Presenter 的时候（比如在 Activity 的 onDestroyed() 生命周期）将 View 对象置空。然而此时可能一些异步任务没有结束，当它们结束后，getView() 就会返回 null 。为了避免 NPE，通常的做法是在所有异步任务里需要访问 View 的地方，都要进行 if(getView() != null) { } 这样的检查。当你写了好几个 Presenter 之后，便会发现这是一件很烦的事情，不仅仅是因为每次要写同样的东西，还有就是：

It's always a bad sign when the else branch is missing.

关于这个问题，在 Medium 上也有讨论，上面也列出了一些解决方案。比如用 ThirtyInch 这个第三方 MVP 框架，它把所有对 View 的操作封装为一个个的 ViewAction，TiPresenter 内部会管理这些 ViewAction 的运行。只有在 View attach 到 Presenter 的时候，才会执行 ViewAction，否则会保留 ViewAction 直到 View 再次 attach 到 Presenter。还有就是用 WeakReference 或者 Optional 来管理 View 。对于第一个，算是一个不错的解决方案，但它作为一个框架，使用它有一定的引入成本，还有另一个弊端就是 Presenter 和 View 的生命周期绑定得更加紧密，增加了 ViewAction 的维护成本 。对于第二个方案，感觉像是转移话题一样，并没有解决什么根本问题。

其实这个问题的源头在于 getView() 方法是 nullable 的，如果该方法返回的 View 能确保非空，而且不存在内存泄漏问题，且无论是 View 处于哪种生命周期代码都能得到正确的调用，那么问题就解决了。

此时就轮到动态代理出场了，当 View 还没结束的时候，getView() 对象返回的是真实的 View 对象，而当 View 的生命周期结束后，getView() 对象只需要返回一个代理 View 即可，这样就确保了 getView() 不会返回一个空的对象，自然就不需要反复检查，而且代理对象并不会对真实的 View 有任何的影响，所以代码逻辑也不会有任何问题。

Talk is cheap. Show me the code.

public class AbsPresenter<View extends IView> implements IPresenter {

    private View mView;
    private Class<? extends IView> mViewClass;

    public AbsPresenter(@NonNull View iView) {
        this.mView = iView;
        this.mViewClass = iView.getClass();
        if (this.mViewClass.getInterfaces().length == 0) {
            throw new IllegalArgumentException("iView must implement IView interface");
        }
    }

    public void detach() {
        this.mView = null;
    }

    public @NonNull View getView() {
        if (mView == null) {
            return ViewProxy.newInstance(mViewClass);
        }
        return mView;
    }

    private static final class ViewProxy implements InvocationHandler {

        public static <View> View newInstance(Class<? extends IView> clazz) {
            return (View) Proxy.newProxyInstance(clazz.getClassLoader(), clazz.getInterfaces(), new ViewProxy());
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            Type type = method.getReturnType();
            if (type == boolean.class) {
                return false;
            } else if (type == int.class) {
                return 0;
            } else if (type == short.class) {
                return (short)0;
            } else if(type == char.class) {
                return (char)0;
            } else if (type == byte.class) {
                return (byte)0;
            } else if(type == long.class) {
                return 0L;
            } else if (type == float.class) {
                return 0f;
            } else if (type == double.class) {
                return 0D;
            } else {
                return null;
            }
        }
    }
}

这就是我在流利说项目里抽象出的 Presenter，主要展示了 getView() 方法是怎么利用动态代理保证返回值为非空。如此一来，就大可放心地在 Presenter 中使用 getView() 方法，而不用担心 NPE ，也不用担心内存泄漏，代码还能更干净，一举三得！

模块间结构如何更加灵活，更加精简

流利说项目里有很多代表不同功能的模块，为了将模块间解耦，我们在一个公共的模块中定义各个功能模块对外开放的接口，并在各自模块中实现。此外还需要一个类 (以下称作 ModuleProvider) 管理这些模块接口，它需要向外提供接口的 set 和 get 方法。在 Application 初始化的时候，通过反射将这些接口实例化，然后各个模块便可以通过 ModuleProvider 的 get 方法获取其他模块的接口。一切看起来既美好又和谐，可是这里有个问题，如果我正在开发 A 模块，为了更快的编译速度，我在 build.gradle 中去掉了 B 模块，ModuleProvider.getB() 将会返回为 null ，那么 A 模块中很多地方都会出现 NPE 。当然这可以通过判空解决，但显然很蠢，而且如此一来，代码岂不是解耦地不彻底？

一开始的做法是对于所有的接口都有一个默认的空实现，对应到上面的例子就是 ModuleProvider.getB() 会有两个不同的返回结果，一个是在 B 模块内对接口的实现，另一个是在公共模块的一个空实现 。如此一来，ModuleProvider.getB()方法就变成了这样：

public static B getB() {
    if (b == null) {
      b = new EmptyB();
    }
    return b;
  }

现在随意去掉不想要的模块也能愉快地敲代码了。

这样的实现看起来已经很不错了，可还是有优化的空间。问题在于每一个接口都有两个实现，每次要对接口作修改的时候，要同时维护两个实现类，而且其中一个实现并没有实际的作用，更多地是只想把精力放在模块中的实现上。这个时候动态代理又可以大显身手了。既然只是一个空实现，那么当模块不存在时返回一个接口的动态代理不就好了吗？最重要的是，现在不需要同时维护两个实现，可以集中精力在有意义的改动上。为此我在项目中提供了一个生成接口代理的工具类：

import com.xxx.xxx.annotations.SpecifyBooleanValue;
import com.xxx.xxx.annotations.SpecifyClassValue;
import com.xxx.xxx.annotations.SpecifyIntegerValue;
import com.xxx.xxx.annotations.SpecifyStringValue;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;


public class EmptyModuleProxy implements InvocationHandler {

    public static <T> T newInstance(Class<T> clazz) {
        return (T) Proxy.newProxyInstance(clazz.getClassLoader(), new Class[]{clazz}, new EmptyModuleProxy());
    }

   @Override
   public Object invoke(Object o, Method method, Object[] objects) throws Throwable {
       final SpecifyClassValue specifyClassValue = method.getAnnotation(SpecifyClassValue.class);
       if (specifyClassValue != null) return specifyClassValue.returnValue();
       final SpecifyIntegerValue specifyIntegerValue = method.getAnnotation(SpecifyIntegerValue.class);
       if (specifyIntegerValue != null) return specifyIntegerValue.returnValue();
       final SpecifyStringValue specifyStringValue = method.getAnnotation(SpecifyStringValue.class);
       if(specifyStringValue != null) return specifyStringValue.returnValue();
       final SpecifyBooleanValue specifyBooleanValue = method.getAnnotation(SpecifyBooleanValue.class);
       if(specifyBooleanValue != null) return specifyBooleanValue.returnValue();
       return defaultValueByType(method.getReturnType());
   }

   private Object defaultValueByType(Class type) {
       if (type == boolean.class) {
           return false;
       } else if (type == int.class) {
           return 0;
       } else if (type == short.class) {
           return (short)0;
       } else if(type == char.class) {
           return (char)0;
       } else if (type == byte.class) {
           return (byte)0;
       } else if(type == long.class) {
           return 0L;
       } else if (type == float.class) {
           return 0f;
       } else if (type == double.class) {
           return 0D;
       } else {
           return null;
       }
   }
}

这样一来ModuleProvider.getB() 方法就变成这样：

public static B getB() {
    if (b == null) {
      b = EmptyModuleProxy.newInstance(B.class);
    }
    return b;
  }

至此，通过动态代理完美地解决了问题。注意到 EmptyModuleProxy 中还有很多注解，这是因为当一些模块没有引入的时候，希望它的某些接口能返回一些指定的值以方便测试，所以额外定义了一些注解来解决这个问题。比如 B 接口里面定义了一个 getBoolean() 方法，默认返回的是 false ，但实际上我希望在没有引入 B 模块的时候返回 true。那么 B 接口就可以做如下声明：

public interface B {

    @SpecifyBooleanValue(returnValue = true)
    Class<?> getBoolean();
}

总结

通过 MVP 和模块间解耦这两个实际项目中的例子，能够充分地说明动态代理技术的运用，能够给我们的代码带来很多灵活性，让一些实现变得更加简洁、也更加优雅。当然动态代理能带给我们的不仅仅是灵活性。比如 Retrofit 就通过动态代理将我们声明的各种 Service 接口转换为一个个的 ServiceMethod ，然后交给 OkHttp 执行具体的网络操作，从而让网络请求变得如此优雅自然。所以说合理地运用这项技术，能让你把代码敲地更嗨！

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 204,189评论 6赞 478
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,577评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,857评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,703评论 1赞 276
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,705评论 5赞 366
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,620评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,995评论 3赞 396
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,656评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,898评论 1赞 298
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,639评论 2赞 321
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,720评论 1赞 330
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,395评论 4赞 319
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,982评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,953评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,195评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 44,907评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,472评论 2赞 342

推荐阅读更多精彩内容

  • Android - 收藏集
    Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 171,424评论 25赞 707
  • 面向对象的用电信息数据交换协议
    国家电网公司企业标准（Q/GDW）- 面向对象的用电信息数据交换协议 - 报批稿：20170802 前言： 排版 ...
    庭说阅读 10,858评论 6赞 13
  • 择一世长安80
    简书连载风云录蔷薇小说目录择一世长安专题择一世长安【目录】 文丨蔷薇下的阳光 上一章丨《第八十章：小捣蛋》 前情提...
    蔷薇下的阳光阅读 776评论 6赞 14