概述
作為一個android開發(fā)者旦棉，在開發(fā)應(yīng)用時，隨著業(yè)務(wù)規(guī)模發(fā)展到一定程度禾蚕，不斷地加入新功能您朽、添加新的類庫，代碼在急劇的膨脹换淆，相應(yīng)的apk包的大小也急劇增加哗总， 那么終有一天，你會不幸遇到這個錯誤：
- 生成的apk在android 2.3或之前的機器上無法安裝倍试，提示INSTALL_FAILED_DEXOPT
- 方法數(shù)量過多讯屈，編譯時出錯，提示：
Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536
而問題產(chǎn)生的具體原因如下：
無法安裝（Android 2.3 INSTALL_FAILED_DEXOPT）問題县习，是由dexopt的LinearAlloc限制引起的涮母，在Android版本不同分別經(jīng)歷了4M/5M/8M/16M限制，目前主流4.2.x系統(tǒng)上可能都已到16M躁愿， 在Gingerbread或者以下系統(tǒng)LinearAllocHdr分配空間只有5M大小的叛本， 高于Gingerbread的系統(tǒng)提升到了8M。Dalvik linearAlloc是一個固定大小的緩沖區(qū)彤钟。在應(yīng)用的安裝過程中来候，系統(tǒng)會運行一個名為dexopt的程序為該應(yīng)用在當(dāng)前機型中運行做準(zhǔn)備。dexopt使用LinearAlloc來存儲應(yīng)用的方法信息样勃。Android 2.2和2.3的緩沖區(qū)只有5MB吠勘，Android 4.x提高到了8MB或16MB。當(dāng)方法數(shù)量過多導(dǎo)致超出緩沖區(qū)大小時峡眶，會造成dexopt崩潰剧防。
超過最大方法數(shù)限制的問題，是由于DEX文件格式限制辫樱，一個DEX文件中method個數(shù)采用使用原生類型short來索引文件中的方法峭拘，也就是4個字節(jié)共計最多表達(dá)65536個method，field/class的個數(shù)也均有此限制。對于DEX文件鸡挠，則是將工程所需全部class文件合并且壓縮到一個DEX文件期間辉饱，也就是Android打包的DEX過程中， 單個DEX文件可被引用的方法總數(shù)（自己開發(fā)的代碼以及所引用的Android框架拣展、類庫的代碼）被限制為65536彭沼；
插件化？ MultiDex备埃？
解決這個問題姓惑，一般有下面幾種方案，一種方案是加大Proguard的力度來減小DEX的大小和方法數(shù)按脚，但這是治標(biāo)不治本的方案于毙，隨著業(yè)務(wù)代碼的添加，方法數(shù)終究會到達(dá)這個限制辅搬，一種比較流行的方案是插件化方案唯沮，另外一種是采用google提供的MultiDex方案，以及google在推出MultiDex之前Android Developers博客介紹的通過自定義類加載過程堪遂， 再就是Facebook推出的為Android應(yīng)用開發(fā)的Dalvik補丁介蛉， 但facebook博客里寫的不是很詳細(xì)；我們在插件化方案上也做了探索和嘗試蚤氏，發(fā)現(xiàn)部署插件化方案甘耿，首先需要梳理和修改各個業(yè)務(wù)線的代碼，使之解耦竿滨，改動的面和量比較巨大佳恬，通過一定的探討和分析，我們認(rèn)為對我們目前來說采用MultiDex方案更靠譜一些于游，這樣我們可以快速和簡潔的對代碼進(jìn)行拆分毁葱，同時代碼改動也在可以接受的范圍內(nèi)； 這樣我們采用了google提供的MultiDex方式進(jìn)行了開發(fā)贰剥。
插件化方案在業(yè)內(nèi)有不同的實現(xiàn)原理倾剿，這里不再一一列舉，這里只列舉下Google為構(gòu)建超過65K方法數(shù)的應(yīng)用提供官方支持的方案：MultiDex蚌成。
首先使用Android SDK Manager升級到最新的Android SDK Build Tools和Android Support Library前痘。然后進(jìn)行以下兩步操作：
- 修改Gradle配置文件，啟用MultiDex并包含MultiDex支持：
android {
compileSdkVersion 21 buildToolsVersion "21.1.0"
defaultConfig {
...
minSdkVersion 14
targetSdkVersion 21
...
// Enabling MultiDex support.
MultiDexEnabled true
}
...
}
dependencies {
compile 'com.android.support:MultiDex:1.0.0'
}
- 讓應(yīng)用支持多DEX文件担忧。在官方文檔中描述了三種可選方法：
在AndroidManifest.xml的application中聲明android.support.MultiDex.MultiDexApplication芹缔；
如果你已經(jīng)有自己的Application類，讓其繼承MultiDexApplication瓶盛；
如果你的Application類已經(jīng)繼承自其它類最欠，你不想/能修改它示罗，那么可以重寫attachBaseContext()方法：
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
并在Manifest中添加以下聲明：
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.android.MultiDex.myapplication">
<application
...
android:name="android.support.MultiDex.MultiDexApplication">
...
</application>
</manifest>
如果已經(jīng)有自己的Application，則讓其繼承MultiDexApplication即可.
Dex自動拆包及動態(tài)加載
MultiDex帶來的問題
- 在第一版本采用MultiDex方案上線后芝硬，在Dalvik下MultiDex帶來了下列幾個問題：
在冷啟動時因為需要安裝DEX文件蚜点，如果DEX文件過大時，處理時間過長拌阴，很容易引發(fā)ANR（Application Not Responding）绍绘； - 采用MultiDex方案的應(yīng)用可能不能在低于Android 4.0 (API level 14) 機器上啟動，這個主要是因為Dalvik linearAlloc的一個bug (Issue 22586);
- 采用MultiDex方案的應(yīng)用因為需要申請一個很大的內(nèi)存迟赃，在運行時可能導(dǎo)致程序的崩潰脯倒，這個主要是因為Dalvik linearAlloc 的一個限制(Issue 78035). 這個限制在 Android 4.0 (API level 14)已經(jīng)增加了, 應(yīng)用也有可能在低于 Android 5.0 (API level 21)版本的機器上觸發(fā)這個限制；
而在ART下MultiDex是不存在這個問題的捺氢，這主要是因為ART下采用Ahead-of-time (AOT) compilation技術(shù)，系統(tǒng)在APK的安裝過程中會使用自帶的dex2oat工具對APK中可用的DEX文件進(jìn)行編譯并生成一個可在本地機器上運行的文件剪撬，這樣能提高應(yīng)用的啟動速度摄乒，因為是在安裝過程中進(jìn)行了處理這樣會影響應(yīng)用的安裝速度，對ART感興趣的可以參考一下ART和Dalvik的區(qū)別.
MultiDex的基本原理是把通過DexFile來加載Secondary DEX残黑，并存放在BaseDexClassLoader的DexPathList中馍佑。
下面代碼片段是BaseDexClassLoader findClass的過程:
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;
}
下面代碼片段為怎么通過DexFile來加載Secondary DEX并放到BaseDexClassLoader的DexPathList中:
private static void install(ClassLoader loader, List<File> additionalClassPathEntries, File optimizedDirectory)
throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException {
/* The patched class loader is expected to be a descendant of
* dalvik.system.BaseDexClassLoader. We modify its
* dalvik.system.DexPathList pathList field to append additional DEX
* file entries.
*/
Field pathListField = findField(loader, "pathList");
Object dexPathList = pathListField.get(loader);
ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList, new ArrayList<File>(additionalClassPathEntries), optimizedDirectory, suppressedExceptions));
try {
if (suppressedExceptions.size() > 0) {
for (IOException e : suppressedExceptions) {
//Log.w(TAG, "Exception in makeDexElement", e);
}
Field suppressedExceptionsField = findField(loader, "dexElementsSuppressedExceptions");
IOException[] dexElementsSuppressedExceptions = (IOException[]) suppressedExceptionsField.get(loader);
if (dexElementsSuppressedExceptions == null) {
dexElementsSuppressedExceptions = suppressedExceptions.toArray( new IOException[suppressedExceptions.size()]);
} else {
IOException[] combined = new IOException[suppressedExceptions.size() + dexElementsSuppressedExceptions.length];
suppressedExceptions.toArray(combined);
System.arraycopy(dexElementsSuppressedExceptions, 0, combined, suppressedExceptions.size(), dexElementsSuppressedExceptions.length);
dexElementsSuppressedExceptions = combined;
}
suppressedExceptionsField.set(loader, dexElementsSuppressedExceptions);
}
} catch(Exception e) {
}
}
Dex自動拆包及動態(tài)加載方案簡介
通過查看MultiDex的源碼，我們發(fā)現(xiàn)MultiDex在冷啟動時容易導(dǎo)致ANR的瓶頸梨水， 在2.1版本之前的Dalvik的VM版本中拭荤， MultiDex的安裝大概分為幾步，第一步打開apk這個zip包疫诽，第二步把MultiDex的dex解壓出來（除去Classes.dex之外的其他DEX舅世，例如：classes2.dex， classes3.dex等等)奇徒，因為android系統(tǒng)在啟動app時只加載了第一個Classes.dex雏亚，其他的DEX需要我們?nèi)斯みM(jìn)行安裝，第三步通過反射進(jìn)行安裝摩钙，這三步其實都比較耗時罢低， 為了解決這個問題我們考慮是否可以把DEX的加載放到一個異步線程中，這樣冷啟動速度能提高不少胖笛，同時能夠減少冷啟動過程中的ANR网持，對于Dalvik linearAlloc的一個缺陷(Issue 22586)和限制(Issue 78035)，我們考慮是否可以人工對DEX的拆分進(jìn)行干預(yù)长踊，使每個DEX的大小在一定的合理范圍內(nèi)功舀，這樣就減少觸發(fā)Dalvik linearAlloc的缺陷和限制； 為了實現(xiàn)這幾個目的之斯，我們需要解決下面三個問題：
- 在打包過程中如何產(chǎn)生多個的DEX包日杈？
- 如果做到動態(tài)加載遣铝，怎么決定哪些DEX動態(tài)加載呢？
- 如果啟動后在工作線程中做動態(tài)加載莉擒，如果沒有加載完而用戶進(jìn)行頁面操作需要使用到動態(tài)加載DEX中的class怎么辦酿炸？
我們首先來分析如何解決第一個問題，在使用MultiDex方案時涨冀，我們知道BuildTool會自動把代碼進(jìn)行拆成多個DEX包填硕，并且可以通過配置文件來控制哪些代碼放到第一個DEX包中， 下圖是Android的打包流程示意圖：
為了實現(xiàn)產(chǎn)生多個DEX包鹿鳖，我們可以在生成DEX文件的這一步中扁眯， 在Ant或gradle中自定義一個Task來干預(yù)DEX產(chǎn)生的過程，從而產(chǎn)生多個DEX翅帜，下圖是在ant和gradle中干預(yù)產(chǎn)生DEX的自定task的截圖:
tasks.whenTaskAdded { task ->
if (task.name.startsWith('proguard') && (task.name.endsWith('Debug') || task.name.endsWith('Release'))) {
task.doLast {
makeDexFileAfterProguardJar();
}
task.doFirst {
delete "${project.buildDir}/intermediates/classes-proguard";
String flavor = task.name.substring('proguard'.length(), task.name.lastIndexOf(task.name.endsWith('Debug') ? "Debug" : "Release"));
generateMainIndexKeepList(flavor.toLowerCase());
}
} else if (task.name.startsWith('zipalign') && (task.name.endsWith('Debug') || task.name.endsWith('Release'))) {
task.doFirst {
ensureMultiDexInApk();
}
}
}
上一步解決了如何打包出多個DEX的問題了姻檀，那我們該怎么該根據(jù)什么來決定哪些class放到Main DEX，哪些放到Secondary DEX呢（這里的Main DEX是指在2.1版本的Dalvik VM之前由android系統(tǒng)在啟動apk時自己主動加載的Classes.dex涝滴，而Secondary DEX是指需要我們自己安裝進(jìn)去的DEX绣版，例如：Classes2.dex, Classes3.dex等）， 這個需要分析出放到Main DEX中的class依賴歼疮，需要確保把Main DEX中class所有的依賴都要放進(jìn)來杂抽，否則在啟動時會發(fā)生ClassNotFoundException, 這里我們的方案是把Service、Receiver韩脏、Provider涉及到的代碼都放到Main DEX中缩麸，而把Activity涉及到的代碼進(jìn)行了一定的拆分，把首頁Activity赡矢、Laucher Activity杭朱、歡迎頁的Activity、城市列表頁Activity等所依賴的class放到了Main DEX中济竹，把二級痕檬、三級頁面的Activity以及業(yè)務(wù)頻道的代碼放到了Secondary DEX中，為了減少人工分析class的依賴所帶了的不可維護(hù)性和高風(fēng)險性送浊，我們編寫了一個能夠自動分析Class依賴的腳本梦谜， 從而能夠保證Main DEX包含class以及他們所依賴的所有class都在其內(nèi)，這樣這個腳本就會在打包之前自動分析出啟動到Main DEX所涉及的所有代碼袭景，保證Main DEX運行正常唁桩。
隨著第二個問題的迎刃而解，我們來到了比較棘手的第三問題耸棒，如果我們在后臺加載Secondary DEX過程中荒澡，用戶點擊界面將要跳轉(zhuǎn)到使用了在Secondary DEX中class的界面， 那此時必然發(fā)生ClassNotFoundException, 那怎么解決這個問題呢与殃，在所有的Activity跳轉(zhuǎn)代碼處添加判斷Secondary DEX是否加載完成单山？這個方法可行碍现，但工作量非常大； 那有沒有更好的解決方案呢米奸？我們通過分析Activity的啟動過程昼接，發(fā)現(xiàn)Activity是由ActivityThread 通過Instrumentation來啟動的，我們是否可以在Instrumentation中做一定的手腳呢悴晰？通過分析代碼ActivityThread和Instrumentation發(fā)現(xiàn)慢睡，Instrumentation有關(guān)Activity啟動相關(guān)的方法大概有：execStartActivity、newActivity等等铡溪，這樣我們就可以在這些方法中添加代碼邏輯進(jìn)行判斷這個Class是否加載了漂辐，如果加載則直接啟動這個Activity，如果沒有加載完成則啟動一個等待的Activity顯示給用戶棕硫，然后在這個Activity中等待后臺Secondary DEX加載完成髓涯，完成后自動跳轉(zhuǎn)到用戶實際要跳轉(zhuǎn)的Activity；這樣在代碼充分解耦合哈扮，以及每個業(yè)務(wù)代碼能夠做到顆粮吹剩化的前提下，我們就做到Secondary DEX的按需加載了灶泵， 下面是Instrumentation添加的部分關(guān)鍵代碼：
public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode) {
ActivityResult activityResult = null;
String className;
if (intent.getComponent() != null) {
className = intent.getComponent().getClassName();
} else {
ResolveInfo resolveActivity = who.getPackageManager().resolveActivity(intent, 0);
if (resolveActivity != null && resolveActivity.activityInfo != null) {
className = resolveActivity.activityInfo.name;
} else {
className = null;
}
}
if (!TextUtils.isEmpty(className)) {
boolean shouldInterrupted = !MeituanApplication.isDexAvailable();
if (MeituanApplication.sIsDexAvailable.get() || mByPassActivityClassNameList.contains(className)) {
shouldInterrupted = false;
}
if (shouldInterrupted) {
Intent interruptedIntent = new Intent(mContext, WaitingActivity.class);
activityResult = execStartActivity(who, contextThread, token, target, interruptedIntent, requestCode);
} else {
activityResult = execStartActivity(who, contextThread, token, target, intent, requestCode);
}
} else {
activityResult = execStartActivity(who, contextThread, token, target, intent, requestCode);
}
return activityResult;
}
public Activity newActivity(Class<?> clazz, Context context, IBinder token, Application application, Intent intent, ActivityInfo info, CharSequence title, Activity parent, String id, Object lastNonConfigurationInstance)
throws InstantiationException, IllegalAccessException {
String className = "";
Activity newActivity = null;
if (intent.getComponent() != null) {
className = intent.getComponent().getClassName();
}
boolean shouldInterrupted = !MeituanApplication.isDexAvailable();
if (MeituanApplication.sIsDexAvailable.get() || mByPassActivityClassNameList.contains(className)) {
shouldInterrupted = false;
}
if (shouldInterrupted) {
intent = new Intent(mContext, WaitingActivity.class); newActivity = mBase.newActivity(clazz, context, token, application, intent, info, title, parent, id, lastNonConfigurationInstance);
} else {
newActivity = mBase.newActivity(clazz, context, token, application, intent, info, title, parent, id, lastNonConfigurationInstance);
}
return newActivity;
}
實際應(yīng)用中我們還遇到另外一個比較棘手的問題， 就是Field的過多的問題对途，F(xiàn)ield過多是由我們目前采用的代碼組織結(jié)構(gòu)引入的赦邻，我們?yōu)榱朔奖愣鄻I(yè)務(wù)線、多團(tuán)隊并發(fā)協(xié)作的情況下開發(fā)实檀，我們采用的aar的方式進(jìn)行開發(fā)惶洲，并同時在aar依賴鏈的最底層引入了一個通用業(yè)務(wù)aar，而這個通用業(yè)務(wù)aar中包含了很多資源膳犹，而ADT14以及更高的版本中對Library資源處理時恬吕，Library的R資源不再是static final的了，詳情請查看google官方說明须床，這樣在最終打包時Library中的R沒法做到內(nèi)聯(lián)铐料，這樣帶來了R field過多的情況，導(dǎo)致需要拆分多個Secondary DEX豺旬，為了解決這個問題我們采用的是在打包過程中利用腳本把Libray中R field（例如ID钠惩、Layout、Drawable等）的引用替換成常量族阅，然后刪去Library中R.class中的相應(yīng)Field篓跛。
總結(jié)
上面就是我們在使用MultiDex過程中進(jìn)化而來的DEX自動化拆包的方案， 這樣我們就可以通過腳本控制來進(jìn)行自動化的拆分DEX坦刀，然后在運行時自由的加載Secondary DEX愧沟，既能保證冷啟動速度蔬咬，又能減少運行時的內(nèi)存占用。
