因為後兩個參數是 optional 參數，所以理論上只需給 dx 加上“--multi-dex”參數即可生成出 classes.dex、classes2.dex、classes3.dex等。

這裡我們指定了--main-dex-list 參數，將指定的class合並到classes.dex中，看看main-dex-rule.txt的內容：

這裡我們將程序的MyApplication類和入口Activity以及需要加載dex的這三個類合並到主dex中，因為這三個是初始化時機最早的，而且也是加載後面subdex類的重要類，所以必須放到主dex中。不然程序都運行不起來的。當然也要注意內部類的情況，也要進行添加的。

好了，我們運行build之後，發現有一個問題，就是我們只看到了一個dex，那就是classes.dex。為什麼會這樣呢？

再看 dx 的參數，main-dex-list 和 minimal-main-dex 只會影響到主 dex 中包含的文件，不會影響到從 dex 是否生成，所以應該是其他原因造成的。
查不到資料，分析源代碼就是解決問題的不二法門。於是我把 dx.jar 反編譯了一下，通過分析，找到了下面的幾行關鍵代碼：

顯然，dx 進行多 dex 打包時，默認每個 dex 中方法數最大為65536。而查看當前應用 dex 的方法數，一共只有51392（方法數沒超標，主要是 LinearAlloc 超標），沒有達到65536，所以打包的時候只有一個 dex。
再繼續分析代碼，發現下面一段關鍵代碼：

這說明 dx 有一個隱藏的參數：--set-max-idx-number，這個參數可以用於設置 dx 打包時每個 dex 最大的方法數，但是此參數並未在 dx 的 Usage 中列出（坑爹啊！）。

我們在 ant 腳本中把這個參數設置上，暫時設置每個 dex 的方法數最大為：2000，然後在編譯：

好吧，這下出來了兩個dex了，這裡我可以發現，沒有classes1.dex的，下標是從2開始的，這個需要注意的。

這裡我們可以用IDA查看dex文件：

classes.dex：

classes2.dex：

看來是成功了，那麼下面我們在繼續看，現在有了兩個dex文件，下面如何編譯成apk文件呢？

我們之前知道這時候可以在使用apkbuilder命令將我們編譯完的：resource.arsc，asset，dex文件打包成apk文件。

但是這裡遇到一個蛋疼問題來了:

apkbuilder命令支持的參數中，只能包含一個dex文件，說白了就是只能打入一個dex文件。

這下蛋疼了，該怎麼辦呢？這裡當時急需驗證結果，先簡單弄了一下，也算是一個小技巧，直接使用WinRar軟件直接把subdex導進去：

然後在單獨簽名apk，運行，可以了，心情也是很好的，但是感覺這個不能自動化呀。太黑了，所以得想個辦法，想到了ZipFile這個類，我們可以解壓apk,然後將subdex添加進去，然後把這部分功能打包成一個可執行的jar,然後在build.xml中運行即可。這個也是個方法，但是還是感覺不好，有點繁瑣。思前想後，最後找到了一個好辦法，也是一個很重要的知識點，那就是使用aapt命令來進行操作，我們在之前可能知道aapt命令用來編譯資源文件的，其實他還有一個重要的用途就是可以編輯apk文件：

可以看到，我們可以刪除apk中的一個文件，或者是添加一個文件，好的，方法終於找到了，下面就直接操作吧，首先我們單獨用命令來操作一下看看效果：

成功了，接下來我們在來看看apk文件：

尼瑪，發現還不對，這裡有一個坑，就是我們沒看到classes2.dex，而看到了一個目錄結構，哦，想想應該明白了，aapt命令在添加或者刪除的時候，文件的路徑必須明確，不能是絕對路徑，而是相對路徑，這個相對就要相對apk的跟目錄，我們現在想把classes2.dex放到apk的根目錄下面，那麼就應該直接是classes2.dex，我們可以將dex和apk放到一個目錄下面來進行操作：

這時候我們在來看一下apk文件：

好吧，成功了，所以這裡我們需要注意的是subdex的路徑。

下面我們繼續來看build.xml腳本內容，看看在拆包成功之後，如何打包成apk中：

	
	
		
			
		
	



 
	
	
	  
	
	  
		  
		  
		${dexfile} is not handle  
		  
	  
		${dexfile} is handle
	
		
		
		
	
	  
	 
	 
  



	
	 
		 
			 
		 
	 
 

1、遍歷bin目錄下所有的dex文件

2、將dex文件先拷貝到項目的根目錄下面，因為我們的腳本文件是在根目錄下面，運行腳本的時候也是在根目錄下面，所以需要把dex文件拷貝到這裡，不然會發生上面說到的問題，不能使用絕對路徑，而是相對路徑來添加dex文件。

3、因為apk默認的話是包含了classes.dex文件，所以這裡需要過濾classes.dex文件，對其他的dex文件進行aapt命令進行添加。
 

但是這裡當時還遇到了一個問題，就是在ant腳本中如何使用循環，正則表達式，條件判斷等標簽：

具體標簽不說了，主要說明一下如何使用這些標簽？因為默認情況下，這些標簽是不能用的，所以需要導入jar包？

這時候我們還需要把：ant-contrib-1.0b3.jar 放到ant的lib目錄下面，默認是沒有這個jar的。關於這個jar，網上很多，自行下載即可

這時候我們就可以運行build.xml腳本了。

上面就介紹完了使用腳本拆包，以及如何將多個dex打包成apk.

下面來看一下代碼如何實現：

代碼中我們定義了四個Activity：

MainActivity是我們的入口Activity，SecondaryDexEx是動態加載的核心類

首先如何從apk中獲取dex文件：

ZipFile apkFile = null;
try {
	apkFile = new ZipFile(appContext.getApplicationInfo().sourceDir);
} catch (Exception e) {
	Log.i("multidex", "create zipfile error:"+Log.getStackTraceString(e));
	return;
}

Log.i("multidex", "zipfile:"+apkFile.getName());

File filesDir = appContext.getDir("odex", Context.MODE_PRIVATE);
Log.i("multidex", "filedir:"+filesDir.getAbsolutePath());
for(int i = 0 ; i < SUB_DEX_NUM; i ++){
	String possibleDexName = buildDexFullName(i);
	Log.i("multidex", "proname:"+possibleDexName);
	ZipEntry zipEntry = apkFile.getEntry(possibleDexName);
	Log.i("multidex", "entry:"+zipEntry);
	if(zipEntry == null) {
		break;
	}
	msLoadedDexList.add(new LoadedDex(filesDir,possibleDexName,zipEntry));
}

接下來我們獲取到了所有的subdex之後，然後就可以動態加載了，需要把我們的dex加載到系統中，這裡主要就是使用反射技術合並dexList即可。

/**
 * 這裡需要注入DexClassLoader
 * 因為GDT內部點擊廣告是去下載App,是啟動一個DownloadService去下載App
 * 所以這裡需要這麼做，不然會報異常
 * @param loader
 */
private static void inject(DexClassLoader loader, Context ctx){
	PathClassLoader pathLoader = (PathClassLoader) ctx.getClassLoader();
	try {
		Object dexElements = combineArray(
				getDexElements(getPathList(pathLoader)),
				getDexElements(getPathList(loader)));
		Object pathList = getPathList(pathLoader);
		setField(pathList, pathList.getClass(), "dexElements", dexElements);
	} catch (Exception e) {
		Log.i("multidex", "inject dexclassloader error:" + Log.getStackTraceString(e));
	}
}

private static Object getPathList(Object baseDexClassLoader)
		throws IllegalArgumentException, NoSuchFieldException, IllegalAccessException, ClassNotFoundException {
	return getField(baseDexClassLoader, Class.forName("dalvik.system.BaseDexClassLoader"), "pathList");
}

private static Object getField(Object obj, Class cl, String field)
		throws NoSuchFieldException, IllegalArgumentException, IllegalAccessException {
	Field localField = cl.getDeclaredField(field);
	localField.setAccessible(true);
	return localField.get(obj);
}

private static Object getDexElements(Object paramObject)
		throws IllegalArgumentException, NoSuchFieldException, IllegalAccessException {
	return getField(paramObject, paramObject.getClass(), "dexElements");
}
private static void setField(Object obj, Class cl, String field,
		Object value) throws NoSuchFieldException,
		IllegalArgumentException, IllegalAccessException {

	Field localField = cl.getDeclaredField(field);
	localField.setAccessible(true);
	localField.set(obj, value);
}

private static Object combineArray(Object arrayLhs, Object arrayRhs) {
	Class localClass = arrayLhs.getClass().getComponentType();
	int i = Array.getLength(arrayLhs);
	int j = i + Array.getLength(arrayRhs);
	Object result = Array.newInstance(localClass, j);
	for (int k = 0; k < j; ++k) {
		if (k < i) {
			Array.set(result, k, Array.get(arrayLhs, k));
		} else {
			Array.set(result, k, Array.get(arrayRhs, k - i));
		}
	}
	return result;
}

在MyApplication中的attachBaseContext方法中調用loadSecondaryDex方法即可：

跑完之後，我們看一下bin目錄下多了一個成功的apk文件：

我們安裝運行，結果如下：

看到了，我們首先啟動的是MainActivity入口，然後我們依次點擊btn進入不同的Activity。結果運行正常，同時我們也可以查看一下日志，獲取dex和加載dex是正常的。

到這裡我們的心情很激動，終於搞定了拆包，遇到一些問題，但是我們都解決了。哈哈~~

項目下載：http://download.csdn.net/detail/jiangwei0910410003/9452599

五、梳理流程

下面我們來總結一下我們做的哪些工作：

1、首先我們使用腳本進行自動拆包，得到兩個dex文件。

2、因為apkbuilder命令在打apk包的時候，只能包含一個dex文件，所以我們需要在使用aapt命令添加其他的subdex文件

3、得到應用程序的apk文件，然後得到所有的dex文件，在使用DexClassLoader進行subdex的加載。

但是關於我們之前說到的拆包的第二個技術，手動拆包這裡就沒有介紹了，其實很簡單，就是在ant腳本中進行分類copy文件就好了，得到了多個dex之後，同樣使用aapt命令添加到apk中就可以了。

六、知識點概要

學習到了哪些知識點：

1、更加深入的了解了ant腳本的語法

2、學習到了使用dx命令來進行自動拆包

3、復習了DexClassLoader的用法

七、遇到的錯誤

我們在這個過程中可能會遇到一些錯誤，最多的就是：ClassNotFound和NotDefClass這兩個錯誤，這個處理很簡單的，我們查看是哪個類，然後用IDA查看每個dex文件是否包含了這個類，如果沒有，那說明沒有將這個類歸類進去

八、性能分析

在冷啟動時因為需要加載多個DEX文件，如果DEX文件過大時，處理時間過長，很容易引發ANR（Application Not Responding）；
采用MultiDex方案的應用可能不能在低於Android 4.0 (API level 14) 機器上啟動，這個主要是因為Dalvik linearAlloc的一個bug (Issue 22586);采用MultiDex方案的應用因為需要申請一個很大的內存，在運行時可能導致程序的崩潰，這個主要是因為Dalvik linearAlloc 的一個限制(Issue 78035). 這個限制在 Android 4.0 (API level 14)已經增加了, 應用也有可能在低於 Android 5.0 (API level 21)版本的機器上觸發這個限制。

Dex分包後，如果是啟動時同步加載，對應用的啟動速度會有一定的影響，但是主要影響的是安裝後首次啟動。這是因為安裝後首次啟動時，Android系統會對加載的從dex做Dexopt並生成ODEX，而 Dexopt 是比較耗時的操作，所以對安裝後首次啟動速度影響較大。在非安裝後首次啟動時，應用只需加載 ODEX，這個過程速度很快，對啟動速度影響不大。同時，從dex 的大小也直接影響啟動速度，即從dex越小則啟動越快。

九、總結

關於Android中的拆包技術網上已經有很多案例和解釋了，但是大部分都是理論知識，沒有說到細節的，更沒有什麼demo。所以這篇文章就主要詳細介紹了分包的技術點以及用一個demo來進行案例分析，更加深入的了解了拆包技術，本文中雖然用到了是ant腳本進行編譯的，但是同樣可以使用gradle來進行編譯，只要理解了原理，其實都是命令在操作的，和腳本沒有任何關系的。從此我們也不會在感覺拆包技術多不覺明歷了。其實就是那麼回事。