轉(zhuǎn)載：tech.meituan.com/mt-android-auto-split-dex.html
概述
作為一個(gè)android開發(fā)者，在開發(fā)應(yīng)用時(shí)洒嗤，隨著業(yè)務(wù)規(guī)模發(fā)展到一定程度箫荡，不斷地加入新功能、添加新的類庫(kù)渔隶，代碼在急劇的膨脹羔挡，相應(yīng)的apk包的大小也急劇增加， 那么終有一天间唉，你會(huì)不幸遇到這個(gè)錯(cuò)誤：
生成的apk在android 2.3或之前的機(jī)器上無(wú)法安裝婉弹，提示INSTALL_FAILED_DEXOPT
方法數(shù)量過(guò)多，編譯時(shí)出錯(cuò)终吼，提示：
Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536
而問(wèn)題產(chǎn)生的具體原因如下：
無(wú)法安裝（Android 2.3 INSTALL_FAILED_DEXOPT）問(wèn)題镀赌，是由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是一個(gè)固定大小的緩沖區(qū)良姆。在應(yīng)用的安裝過(guò)程中，系統(tǒng)會(huì)運(yùn)行一個(gè)名為dexopt的程序?yàn)樵搼?yīng)用在當(dāng)前機(jī)型中運(yùn)行做準(zhǔn)備幔戏。dexopt使用LinearAlloc來(lái)存儲(chǔ)應(yīng)用的方法信息玛追。Android 2.2和2.3的緩沖區(qū)只有5MB，Android 4.x提高到了8MB或16MB闲延。當(dāng)方法數(shù)量過(guò)多導(dǎo)致超出緩沖區(qū)大小時(shí)痊剖，會(huì)造成dexopt崩潰。
超過(guò)最大方法數(shù)限制的問(wèn)題垒玲，是由于DEX文件格式限制陆馁，一個(gè)DEX文件中method個(gè)數(shù)采用使用原生類型short來(lái)索引文件中的方法，也就是4個(gè)字節(jié)共計(jì)最多表達(dá)65536個(gè)method合愈，field/class的個(gè)數(shù)也均有此限制叮贩。對(duì)于DEX文件，則是將工程所需全部class文件合并且壓縮到一個(gè)DEX文件期間佛析，也就是Android打包的DEX過(guò)程中益老， 單個(gè)DEX文件可被引用的方法總數(shù)（自己開發(fā)的代碼以及所引用的Android框架、類庫(kù)的代碼）被限制為65536寸莫；
插件化捺萌？ MultiDex？
解決這個(gè)問(wèn)題储狭，一般有下面幾種方案互婿，一種方案是加大Proguard的力度來(lái)減小DEX的大小和方法數(shù)捣郊，但這是治標(biāo)不治本的方案，隨著業(yè)務(wù)代碼的添加慈参，方法數(shù)終究會(huì)到達(dá)這個(gè)限制呛牲，一種比較流行的方案是插件化方案，另外一種是采用google提供的MultiDex方案驮配，以及google在推出MultiDex之前Android Developers博客介紹的通過(guò)自定義類加載過(guò)程娘扩， 再就是Facebook推出的為Android應(yīng)用開發(fā)的Dalvik補(bǔ)丁， 但facebook博客里寫的不是很詳細(xì)壮锻；我們?cè)诓寮桨干弦沧隽颂剿骱蛧L試琐旁，發(fā)現(xiàn)部署插件化方案，首先需要梳理和修改各個(gè)業(yè)務(wù)線的代碼猜绣，使之解耦灰殴，改動(dòng)的面和量比較巨大，通過(guò)一定的探討和分析掰邢，我們認(rèn)為對(duì)我們目前來(lái)說(shuō)采用MultiDex方案更靠譜一些牺陶，這樣我們可以快速和簡(jiǎn)潔的對(duì)代碼進(jìn)行拆分，同時(shí)代碼改動(dòng)也在可以接受的范圍內(nèi)辣之； 這樣我們采用了google提供的MultiDex方式進(jìn)行了開發(fā)掰伸。
插件化方案在業(yè)內(nèi)有不同的實(shí)現(xiàn)原理，這里不再一一列舉怀估，這里只列舉下Google為構(gòu)建超過(guò)65K方法數(shù)的應(yīng)用提供官方支持的方案：MultiDex狮鸭。
首先使用Android SDK Manager升級(jí)到最新的Android SDK Build Tools和Android Support Library。然后進(jìn)行以下兩步操作：
1.修改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'
}
2.讓應(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中添加以下聲明：
...
android:name="android.support.MultiDex.MultiDexApplication">
...
如果已經(jīng)有自己的Application，則讓其繼承MultiDexApplication即可.
Dex自動(dòng)拆包及動(dòng)態(tài)加載
MultiDex帶來(lái)的問(wèn)題
在第一版本采用MultiDex方案上線后春弥，在Dalvik下MultiDex帶來(lái)了下列幾個(gè)問(wèn)題：
在冷啟動(dòng)時(shí)因?yàn)樾枰惭bDEX文件呛哟，如果DEX文件過(guò)大時(shí)，處理時(shí)間過(guò)長(zhǎng)匿沛，很容易引發(fā)ANR（Application Not Responding）扫责；
采用MultiDex方案的應(yīng)用可能不能在低于Android 4.0 (API level 14) 機(jī)器上啟動(dòng)，這個(gè)主要是因?yàn)镈alvik linearAlloc的一個(gè)bug (Issue 22586);
采用MultiDex方案的應(yīng)用因?yàn)樾枰暾?qǐng)一個(gè)很大的內(nèi)存逃呼，在運(yùn)行時(shí)可能導(dǎo)致程序的崩潰鳖孤，這個(gè)主要是因?yàn)镈alvik linearAlloc 的一個(gè)限制(Issue 78035). 這個(gè)限制在 Android 4.0 (API level 14)已經(jīng)增加了, 應(yīng)用也有可能在低于 Android 5.0 (API level 21)版本的機(jī)器上觸發(fā)這個(gè)限制者娱；
而在ART下MultiDex是不存在這個(gè)問(wèn)題的，這主要是因?yàn)锳RT下采用Ahead-of-time (AOT) compilation技術(shù)苏揣，系統(tǒng)在APK的安裝過(guò)程中會(huì)使用自帶的dex2oat工具對(duì)APK中可用的DEX文件進(jìn)行編譯并生成一個(gè)可在本地機(jī)器上運(yùn)行的文件黄鳍，這樣能提高應(yīng)用的啟動(dòng)速度，因?yàn)槭窃诎惭b過(guò)程中進(jìn)行了處理這樣會(huì)影響應(yīng)用的安裝速度平匈，對(duì)ART感興趣的可以參考一下ART和Dalvik的區(qū)別.
MultiDex的基本原理是把通過(guò)DexFile來(lái)加載Secondary DEX框沟，并存放在BaseDexClassLoader的DexPathList中。
下面代碼片段是BaseDexClassLoader findClass的過(guò)程:
protected Class findClass(String name) throws ClassNotFoundException {
List suppressedExceptions = new ArrayList();
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;
}
下面代碼片段為怎么通過(guò)DexFile來(lái)加載Secondary DEX并放到BaseDexClassLoader的DexPathList中:
private static void install(ClassLoader loader, List 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 suppressedExceptions = new ArrayList();
expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList,
new ArrayList(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自動(dòng)拆包及動(dòng)態(tài)加載方案簡(jiǎn)介
通過(guò)查看MultiDex的源碼增炭，我們發(fā)現(xiàn)MultiDex在冷啟動(dòng)時(shí)容易導(dǎo)致ANR的瓶頸忍燥， 在2.1版本之前的Dalvik的VM版本中， MultiDex的安裝大概分為幾步隙姿，第一步打開apk這個(gè)zip包梅垄，第二步把MultiDex的dex解壓出來(lái)（除去Classes.dex之外的其他DEX，例如：classes2.dex输玷， classes3.dex等等)哎甲，因?yàn)閍ndroid系統(tǒng)在啟動(dòng)app時(shí)只加載了第一個(gè)Classes.dex，其他的DEX需要我們?nèi)斯みM(jìn)行安裝饲嗽，第三步通過(guò)反射進(jìn)行安裝炭玫，這三步其實(shí)都比較耗時(shí)， 為了解決這個(gè)問(wèn)題我們考慮是否可以把DEX的加載放到一個(gè)異步線程中貌虾，這樣冷啟動(dòng)速度能提高不少吞加，同時(shí)能夠減少冷啟動(dòng)過(guò)程中的ANR，對(duì)于Dalvik linearAlloc的一個(gè)缺陷(Issue 22586)和限制(Issue 78035)尽狠，我們考慮是否可以人工對(duì)DEX的拆分進(jìn)行干預(yù)衔憨，使每個(gè)DEX的大小在一定的合理范圍內(nèi)，這樣就減少觸發(fā)Dalvik linearAlloc的缺陷和限制袄膏； 為了實(shí)現(xiàn)這幾個(gè)目的践图，我們需要解決下面三個(gè)問(wèn)題：
在打包過(guò)程中如何產(chǎn)生多個(gè)的DEX包？
如果做到動(dòng)態(tài)加載沉馆，怎么決定哪些DEX動(dòng)態(tài)加載呢码党？
如果啟動(dòng)后在工作線程中做動(dòng)態(tài)加載，如果沒(méi)有加載完而用戶進(jìn)行頁(yè)面操作需要使用到動(dòng)態(tài)加載DEX中的class怎么辦斥黑？
我們首先來(lái)分析如何解決第一個(gè)問(wèn)題揖盘，在使用MultiDex方案時(shí)，我們知道BuildTool會(huì)自動(dòng)把代碼進(jìn)行拆成多個(gè)DEX包锌奴，并且可以通過(guò)配置文件來(lái)控制哪些代碼放到第一個(gè)DEX包中兽狭， 下圖是Android的打包流程示意圖：
為了實(shí)現(xiàn)產(chǎn)生多個(gè)DEX包，我們可以在生成DEX文件的這一步中， 在Ant或gradle中自定義一個(gè)Task來(lái)干預(yù)DEX產(chǎn)生的過(guò)程箕慧，從而產(chǎn)生多個(gè)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();
}
}
}
上一步解決了如何打包出多個(gè)DEX的問(wèn)題了，那我們?cè)撛趺丛摳鶕?jù)什么來(lái)決定哪些class放到Main DEX颠焦，哪些放到Secondary DEX呢（這里的Main DEX是指在2.1版本的Dalvik VM之前由android系統(tǒng)在啟動(dòng)apk時(shí)自己主動(dòng)加載的Classes.dex斩熊，而Secondary DEX是指需要我們自己安裝進(jìn)去的DEX，例如：Classes2.dex, Classes3.dex等）蒸健， 這個(gè)需要分析出放到Main DEX中的class依賴座享，需要確保把Main DEX中class所有的依賴都要放進(jìn)來(lái)，否則在啟動(dòng)時(shí)會(huì)發(fā)生ClassNotFoundException, 這里我們的方案是把Service似忧、Receiver渣叛、Provider涉及到的代碼都放到Main DEX中，而把Activity涉及到的代碼進(jìn)行了一定的拆分盯捌，把首頁(yè)Activity淳衙、Laucher Activity、歡迎頁(yè)的Activity饺著、城市列表頁(yè)Activity等所依賴的class放到了Main DEX中箫攀，把二級(jí)、三級(jí)頁(yè)面的Activity以及業(yè)務(wù)頻道的代碼放到了Secondary DEX中幼衰，為了減少人工分析class的依賴所帶了的不可維護(hù)性和高風(fēng)險(xiǎn)性靴跛，我們編寫了一個(gè)能夠自動(dòng)分析Class依賴的腳本， 從而能夠保證Main DEX包含class以及他們所依賴的所有class都在其內(nèi)渡嚣，這樣這個(gè)腳本就會(huì)在打包之前自動(dòng)分析出啟動(dòng)到Main DEX所涉及的所有代碼梢睛，保證Main DEX運(yùn)行正常。
隨著第二個(gè)問(wèn)題的迎刃而解识椰，我們來(lái)到了比較棘手的第三問(wèn)題绝葡，如果我們?cè)诤笈_(tái)加載Secondary DEX過(guò)程中，用戶點(diǎn)擊界面將要跳轉(zhuǎn)到使用了在Secondary DEX中class的界面腹鹉， 那此時(shí)必然發(fā)生ClassNotFoundException, 那怎么解決這個(gè)問(wèn)題呢藏畅，在所有的Activity跳轉(zhuǎn)代碼處添加判斷Secondary DEX是否加載完成？這個(gè)方法可行功咒，但工作量非常大愉阎； 那有沒(méi)有更好的解決方案呢？我們通過(guò)分析Activity的啟動(dòng)過(guò)程航瞭，發(fā)現(xiàn)Activity是由ActivityThread 通過(guò)Instrumentation來(lái)啟動(dòng)的诫硕，我們是否可以在Instrumentation中做一定的手腳呢？通過(guò)分析代碼ActivityThread和Instrumentation發(fā)現(xiàn)刊侯，Instrumentation有關(guān)Activity啟動(dòng)相關(guān)的方法大概有：execStartActivity、newActivity等等锉走，這樣我們就可以在這些方法中添加代碼邏輯進(jìn)行判斷這個(gè)Class是否加載了滨彻，如果加載則直接啟動(dòng)這個(gè)Activity藕届，如果沒(méi)有加載完成則啟動(dòng)一個(gè)等待的Activity顯示給用戶，然后在這個(gè)Activity中等待后臺(tái)Secondary DEX加載完成亭饵，完成后自動(dòng)跳轉(zhuǎn)到用戶實(shí)際要跳轉(zhuǎn)的Activity休偶；這樣在代碼充分解耦合，以及每個(gè)業(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;
}
實(shí)際應(yīng)用中我們還遇到另外一個(gè)比較棘手的問(wèn)題八秃， 就是Field的過(guò)多的問(wèn)題碱妆，F(xiàn)ield過(guò)多是由我們目前采用的代碼組織結(jié)構(gòu)引入的，我們?yōu)榱朔奖愣鄻I(yè)務(wù)線昔驱、多團(tuán)隊(duì)并發(fā)協(xié)作的情況下開發(fā)疹尾，我們采用的aar的方式進(jìn)行開發(fā)，并同時(shí)在aar依賴鏈的最底層引入了一個(gè)通用業(yè)務(wù)aar骤肛，而這個(gè)通用業(yè)務(wù)aar中包含了很多資源纳本，而ADT14以及更高的版本中對(duì)Library資源處理時(shí)，Library的R資源不再是static final的了腋颠，詳情請(qǐng)查看google官方說(shuō)明繁成，這樣在最終打包時(shí)Library中的R沒(méi)法做到內(nèi)聯(lián)，這樣帶來(lái)了R field過(guò)多的情況淑玫，導(dǎo)致需要拆分多個(gè)Secondary DEX巾腕，為了解決這個(gè)問(wèn)題我們采用的是在打包過(guò)程中利用腳本把Libray中R field（例如ID、Layout混移、Drawable等）的引用替換成常量祠墅，然后刪去Library中R.class中的相應(yīng)Field。
總結(jié)
上面就是我們?cè)谑褂肕ultiDex過(guò)程中進(jìn)化而來(lái)的DEX自動(dòng)化拆包的方案歌径， 這樣我們就可以通過(guò)腳本控制來(lái)進(jìn)行自動(dòng)化的拆分DEX毁嗦，然后在運(yùn)行時(shí)自由的加載Secondary DEX，既能保證冷啟動(dòng)速度回铛，又能減少運(yùn)行時(shí)的內(nèi)存占用狗准。
