前言#
之前我們已經(jīng)學(xué)習(xí)了注解在運行時的使用，結(jié)合反射來實現(xiàn)了一個基本的數(shù)據(jù)庫框架，網(wǎng)上有很多人都說反射是一個效率低下的操作行為，是不提倡的，所以這次來親自驗證一下。
正文#
這次的測試還是用之前的例子，看一下代碼：
@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組數(shù)據(jù)：
setContentView（）：164、125、221、264、219、242、285、289
平均時間：226.125@ContentView()：307、244、238、225、230、231、235、253
平均時間：245.375
從以上兩組數(shù)據(jù)對比，如果只是一次幾乎沒有什么太大的差別，回顧一下之前的上一篇的數(shù)據(jù)庫框架，每次操作數(shù)據(jù)庫只進(jìn)行了一次反射，所以影響是很小的。
接下來測試一下100次的效率，還是每種8組數(shù)據(jù)：
setContentView（）：1050、1069、1066、1051、1213、1197、1058、1047
平均時間：1093.875@ContentView()：1228、1080、1088、1075、1136、1076、1081、1080
平均時間：1105.5
從平均時間來看，跟只運行一次的差別并沒有預(yù)期的成比增加，setContentView（）一般是在1050-1060之間，@ContentView()大概是在1080來回浮動。
我用的是android5.0系統(tǒng)，2g運行內(nèi)存的真機(jī)測試，不管系統(tǒng)是否已經(jīng)對反射進(jìn)行了優(yōu)化，或者是現(xiàn)在的運行內(nèi)存的提高，縮小了兩者的差別，最重要的是，我們已經(jīng)親自驗證了反射確實效率要稍微低一些。
為什么會這樣呢？仔細(xì)一想其實也可以理解，就好像一個已經(jīng)包裝好的快遞，人家給你了直接能打開的地方，你偏要拿剪刀從其他剪開弄開他，肯定是多耗費一些力氣，而且這違背了作者設(shè)計的初衷，所以反射一般是不受待見的，但是破壞者卻覺得很high。
<h2>如何解決效率低下的問題</h2>
我們不排除在某些機(jī)型或者系統(tǒng)的情況下，反射的效率比我們測試的結(jié)果要糟糕的多，所以必須要解決這個問題。
如果并發(fā)非常的大，最簡單有效的方法就是緩存，防止同一個類反射多次，造成效率低下的問題，例如Lrucache。
為了能看到明顯的差距，我把循環(huán)次數(shù)加到100次，先貼出優(yōu)化后的代碼：
private static LruCache<String, Method> methodLruCache = new LruCache<>(10);
private static LruCache<String, ContentView> annotationLruCache = new LruCache<>(10);
public static void injectObject(Object handler){
// 拿到參數(shù)的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);
// 調(diào)用setContentView（int param），第一個是操作的對象，第二個是方法的參數(shù)
setContentViewMethod.invoke(handler, contentView.value());
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
}
}
代碼中進(jìn)行了兩處修改，一個是contentView注解的緩存，一個是Methd的緩存，當(dāng)然這種緩存策略是有問題，重點是看否是提高了效率：
優(yōu)化前：9772、9694、9956、9849、9933、9747、9984、10254（這個數(shù)據(jù)不計算，差距太大）
平均時間：9847.85優(yōu)化后：9592、9621、9615、9466、9646、9649、9677、9545
平均時間：9601.375
總結(jié)#
從測試結(jié)果上，可以總結(jié)出三點：
1、反射的效率確實比直接的方法調(diào)用，慢了一些。
2、android應(yīng)該已經(jīng)對反射機(jī)會進(jìn)行了優(yōu)化（至少是android 5.0），網(wǎng)上很早的帖子中描述的那么大的效率差已經(jīng)縮短了很多。
3、如果是高并發(fā)量的操作，或者是循環(huán)量大的操作，效率還是會低一些，所以不能因此而忽略了優(yōu)化。
有對反射更好的理解和優(yōu)化建議，希望大家留言共同學(xué)習(xí)進(jìn)步。
