实现基于注解（Annotation）的数据库框架（六）亲自验证反射的效率及解决办法

前言

之前我们已经学习了注解在运行时的使用，结合反射来实现了一个基本的数据库框架，网上有很多人都说反射是一个效率低下的操作行为，是不提倡的，所以这次来亲自验证一下。

正文

这次的测试还是用之前的例子，看一下代码：

@ContentView(value = R.layout.activity_main)
public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.e("lzp", "start setContentView:" + System.currentTimeMillis());
//        AnnotationUtils.injectObject(this);

        setContentView(R.layout.activity_main);
        Log.e("lzp", "start setContentView over:" + System.currentTimeMillis());
    }
}

我们先来看一下两种方式只运行一次的效率差，每种8组数据：

setContentView（）：164、125、221、264、219、242、285、289
平均时间：226.125

@ContentView()：307、244、238、225、230、231、235、253
平均时间：245.375

从以上两组数据对比，如果只是一次几乎没有什么太大的差别，回顾一下之前的上一篇的数据库框架，每次操作数据库只进行了一次反射，所以影响是很小的。

接下来测试一下100次的效率，还是每种8组数据：

setContentView（）：1050、1069、1066、1051、1213、1197、1058、1047
平均时间：1093.875

@ContentView()：1228、1080、1088、1075、1136、1076、1081、1080
平均时间：1105.5

从平均时间来看，跟只运行一次的差别并没有预期的成比增加，setContentView（）一般是在1050-1060之间，@ContentView()大概是在1080来回浮动。

我用的是android5.0系统，2g运行内存的真机测试，不管系统是否已经对反射进行了优化，或者是现在的运行内存的提高，缩小了两者的差别，最重要的是，我们已经亲自验证了反射确实效率要稍微低一些。

为什么会这样呢？仔细一想其实也可以理解，就好像一个已经包装好的快递，人家给你了直接能打开的地方，你偏要拿剪刀从其他剪开弄开他，肯定是多耗费一些力气，而且这违背了作者设计的初衷，所以反射一般是不受待见的，但是破坏者却觉得很high。

如何解决效率低下的问题

我们不排除在某些机型或者系统的情况下，反射的效率比我们测试的结果要糟糕的多，所以必须要解决这个问题。

如果并发非常的大，最简单有效的方法就是缓存，防止同一个类反射多次，造成效率低下的问题，例如Lrucache。

为了能看到明显的差距，我把循环次数加到100次，先贴出优化后的代码：

private static LruCache<String, Method> methodLruCache = new LruCache<>(10);
    private static LruCache<String, ContentView> annotationLruCache = new LruCache<>(10);

public static void injectObject(Object handler){

        // 拿到参数的Class类型
        Class<?> handleType = handler.getClass();
        // 获取Class类型上的ContentView注解
        String key = handleType.getCanonicalName();
        ContentView contentView = annotationLruCache.get(key);
        if (contentView == null){
            contentView = handleType.getAnnotation(ContentView.class);
            annotationLruCache.put(key, contentView);
        }
//        ContentView contentView = handleType.getAnnotation(ContentView.class);
        if (contentView != null){
            try {
                // 通过反射找到Class类型中的setContentView（int param）方法
                Method setContentViewMethod = methodLruCache.get("setContentView_method");
                if (setContentViewMethod == null){
                    setContentViewMethod = handleType.getMethod("setContentView", int.class);
                    methodLruCache.put("setContentView_method", setContentViewMethod);
                }
//                Method setContentViewMethod = handleType.getMethod("setContentView", int.class);
                // 调用setContentView（int param），第一个是操作的对象，第二个是方法的参数
                setContentViewMethod.invoke(handler, contentView.value());
            } catch (NoSuchMethodException e) {
                e.printStackTrace();
            } catch (InvocationTargetException e) {
                e.printStackTrace();
            } catch (IllegalAccessException e) {
                e.printStackTrace();
            }
        }
    }

代码中进行了两处修改，一个是contentView注解的缓存，一个是Methd的缓存，当然这种缓存策略是有问题，重点是看否是提高了效率：

优化前：9772、9694、9956、9849、9933、9747、9984、10254（这个数据不计算，差距太大）
平均时间：9847.85

优化后：9592、9621、9615、9466、9646、9649、9677、9545
平均时间：9601.375

总结

从测试结果上，可以总结出三点：

1、反射的效率确实比直接的方法调用，慢了一些。

2、android应该已经对反射机会进行了优化（至少是android 5.0），网上很早的帖子中描述的那么大的效率差已经缩短了很多。

3、如果是高并发量的操作，或者是循环量大的操作，效率还是会低一些，所以不能因此而忽略了优化。

有对反射更好的理解和优化建议，希望大家留言共同学习进步。