前言
之前我们已经学习了注解在运行时的使用,结合反射来实现了一个基本的数据库框架,网上有很多人都说反射是一个效率低下的操作行为,是不提倡的,所以这次来亲自验证一下。
正文
这次的测试还是用之前的例子,看一下代码:
@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、如果是高并发量的操作,或者是循环量大的操作,效率还是会低一些,所以不能因此而忽略了优化。
有对反射更好的理解和优化建议,希望大家留言共同学习进步。