<p>當(dāng)一個app的功能越來越復(fù)雜骡和,代碼量越來越多,也許有一天便會突然遇到下列現(xiàn)象:</p>
- 生成的apk在2.3以前的機器無法安裝件相,提示INSTALL_FAILED_DEXOPT
- 方法數(shù)量過多韵卤,編譯時出錯,提示:
Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536
<p>出現(xiàn)這種問題的原因是:</p>
- Android2.3及以前版本用來執(zhí)行dexopt(用于優(yōu)化dex文件)的內(nèi)存只分配了5M
- 一個dex文件最多只支持65536個方法着撩。
針對上述問題诅福,也出現(xiàn)了諸多解決方案匾委,使用的最多的是插件化,即將一些獨立的功能做成一個單獨的apk氓润,當(dāng)打開的時候使用DexClassLoader動態(tài)加載赂乐,然后使用反射機制來調(diào)用插件中的類和方法。這固然是一種解決問題的方案:但這種方案存在著以下兩個問題:</p>
- 插件化只適合一些比較獨立的模塊咖气;
- 必須通過反射機制去調(diào)用插件的類和方法挨措,因此,必須搭配一套插件框架來配合使用采章;
由于上述問題的存在运嗜,通過不斷研究,便有了dex分包的解決方案悯舟。簡單來說担租,其原理是將編譯好的class文件拆分打包成兩個dex,繞過dex方法數(shù)量的限制以及安裝時的檢查抵怎,在運行時再動態(tài)加載第二個dex文件中奋救。
faceBook曾經(jīng)遇到相似的問題,具體可參考:
https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920
文中有這么一段話:
However, there was no way we could break our app up this way--too many of our classes are accessed directly by the Android framework. Instead, we needed to inject our secondary dex files directly into the system class loader反惕。
文中說得比較簡單尝艘,我們來完善一下該方案:除了第一個dex文件(即正常apk包唯一包含的Dex文件),其它dex文件都以資源的方式放在安裝包中姿染,并在Application的onCreate回調(diào)中被注入到系統(tǒng)的ClassLoader背亥。因此,對于那些在注入之前已經(jīng)引用到的類(以及它們所在的jar),必須放入第一個Dex文件中悬赏。
下面通過一個簡單的demo來講述dex分包方案狡汉,該方案分為兩步執(zhí)行:
整個demo的目錄結(jié)構(gòu)是這樣,我打算將SecondActivity闽颇,MyContainer以及DropDownView放入第二個dex包中盾戴,其它保留在第一個dex包。
1.編譯時分包
整個編譯流程如下:
除了框出來的兩Target兵多,其它都是編譯的標準流程尖啡。而這兩個Target正是我們的分包操作。首先來看看spliteClasses target剩膘。
由于我們這里僅僅是一個demo,因此放到第二個包中的文件很少衅斩,就是上面提到的三個文件。分好包之后就要開始生成dex文件怠褐,首先打包第一個dex文件:
由這里將${classes}(該文件夾下都是要打包到第一個dex的文件)打包生成第一個dex矛渴。接著生成第二個dex,并將其打包到資資源文件中:
可以看到,此時是將${secclasses}中的文件打包生成dex具温,并將其加入ap文件(打包的資源文件)中蚕涤。到此,分包完畢铣猩,接下來揖铜,便來分析一下如何動態(tài)將第二個dex包注入系統(tǒng)的ClassLoader。
2.將dex分包注入ClassLoader
這里談到注入达皿,就要談到Android的ClassLoader體系天吓。
由上圖可以看出,在葉子節(jié)點上峦椰,我們能使用到的是DexClassLoader和PathClassLoader龄寞,通過查閱開發(fā)文檔,我們發(fā)現(xiàn)他們有如下使用場景:
- 關(guān)于PathClassLoader汤功,文檔中寫到: Android uses this class for its system class loader and for its application class loader(s),
由此可知物邑,Android應(yīng)用就是用它來加載; - DexClass可以加載apk,jar,及dex文件,但PathClassLoader只能加載已安裝到系統(tǒng)中(即/data/app目錄下)的apk文件滔金。
知道了兩者的使用場景色解,下面來分析下具體的加載原理,由上圖可以看到餐茵,兩個葉子節(jié)點的類都繼承BaseDexClassLoader中科阎,而具體的類加載邏輯也在此類中:
BaseDexClassLoader:
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
Class c = pathList.findClass(name, suppressedExceptions);
if (c == null) {
ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
for (Throwable t : suppressedExceptions) {
cnfe.addSuppressed(t);
}
throw cnfe;
}
return c;
}
由上述函數(shù)可知,當(dāng)我們需要加載一個class時忿族,實際是從pathList中去需要的锣笨,查閱源碼,發(fā)現(xiàn)pathList是DexPathList類的一個實例道批。ok错英,接著去分析DexPathList類中的findClass函數(shù),
DexPathList:
public Class findClass(String name, List<Throwable> suppressed) {
for (Element element : dexElements) {
DexFile dex = element.dexFile;
if (dex != null) {
Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
if (clazz != null) {
return clazz;
}
}
}
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
上述函數(shù)的大致邏輯為:遍歷一個裝在dex文件(每個dex文件實際上是一個DexFile對象)的數(shù)組(Element數(shù)組屹徘,Element是一個內(nèi)部類),然后依次去加載所需要的class文件衅金,直到找到為止噪伊。
看到這里,注入的解決方案也就浮出水面氮唯,假如我們將第二個dex文件放入Element數(shù)組中鉴吹,那么在加載第二個dex包中的類時,應(yīng)該可以直接找到惩琉。
帶著這個假設(shè)豆励,來完善demo。
在我們自定義的BaseApplication的onCreate中,我們執(zhí)行注入操作:
public String inject(String libPath) {
boolean hasBaseDexClassLoader = true;
try {
Class.forName("dalvik.system.BaseDexClassLoader");
} catch (ClassNotFoundException e) {
hasBaseDexClassLoader = false;
}
if (hasBaseDexClassLoader) {
PathClassLoader pathClassLoader = (PathClassLoader)sApplication.getClassLoader();
DexClassLoader dexClassLoader = new DexClassLoader(libPath, sApplication.getDir("dex", 0).getAbsolutePath(), libPath, sApplication.getClassLoader());
try {
Object dexElements = combineArray(getDexElements(getPathList(pathClassLoader)), getDexElements(getPathList(dexClassLoader)));
Object pathList = getPathList(pathClassLoader);
setField(pathList, pathList.getClass(), "dexElements", dexElements);
return "SUCCESS";
} catch (Throwable e) {
e.printStackTrace();
return android.util.Log.getStackTraceString(e);
}
}
return "SUCCESS";
}
這是注入的關(guān)鍵函數(shù)良蒸,分析一下這個函數(shù):
參數(shù)libPath是第二個dex包的文件信息(包含完整路徑技扼,我們當(dāng)初將其打包到了assets目錄下),然后將其使用DexClassLoader來加載(這里為什么必須使用DexClassLoader加載嫩痰,回顧以上的使用場景)剿吻,然后通過反射獲取PathClassLoader中的DexPathList中的Element數(shù)組(已加載了第一個dex包,由系統(tǒng)加載)串纺,以及DexClassLoader中的DexPathList中的Element數(shù)組(剛將第二個dex包加載進去)丽旅,將兩個Element數(shù)組合并之后,再將其賦值給PathClassLoader的Element數(shù)組纺棺,到此榄笙,注入完畢。
現(xiàn)在試著啟動app祷蝌,并在TestUrlActivity(在第一個dex包中)中去啟動SecondActivity(在第二個dex包中)茅撞,啟動成功。這種方案是可行杆逗。
但是使用dex分包方案仍然有幾個注意點:</p>
- 由于第二個dex包是在Application的onCreate中動態(tài)注入的乡翅,如果dex包過大,會使app的啟動速度變慢罪郊,因此蠕蚜,在dex分包過程中一定要注意,第二個dex包不宜過大悔橄。
- 由于上述第一點的限制靶累,假如我們的app越來越臃腫和龐大,往往會采取dex分包方案和插件化方案配合使用癣疟,將一些非核心獨立功能做成插件加載挣柬,核心功能再分包加載。
更多博文請到作者站點查看:
Cyning的博客:Cyning的博客