前言#
之前我们已经学习了注解在运行时的使用，结合反射来实现了一个基本的数据库框架，网上有很多人都说反射是一个效率低下的操作行为，是不提倡的，所以这次来亲自验证一下。
正文#
这次的测试还是用之前的例子，看一下代码：
@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。
<h2>如何解决效率低下的问题</h2>
我们不排除在某些机型或者系统的情况下，反射的效率比我们测试的结果要糟糕的多，所以必须要解决这个问题。
如果并发非常的大，最简单有效的方法就是缓存，防止同一个类反射多次，造成效率低下的问题，例如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、如果是高并发量的操作，或者是循环量大的操作，效率还是会低一些，所以不能因此而忽略了优化。
有对反射更好的理解和优化建议，希望大家留言共同学习进步。
