其實你不知道MultiDex到底有多坑
遭遇MultiDex
愉快地寫著Android代碼的總悟君往工程里引入了一個默默無聞的jar然后Run了一下， 經過漫長的等待AndroidStudio構建失敗了。
于是總悟君帶著疑惑查看錯誤信息。
UNEXPECTED TOP-LEVEL EXCEPTION: java.lang.IllegalArgumentException: method ID not in [0, 0xffff]: 65536 at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.java:501) at com.android.dx.merge.DexMerger$IdMerger.mergeSorted(DexMerger.java:276) at com.android.dx.merge.DexMerger.mergeMethodIds(DexMerger.java:490) at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:167) at com.android.dx.merge.DexMerger.merge(DexMerger.java:188) at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:439) at com.android.dx.command.dexer.Main.runMonoDex(Main.java:287) at com.android.dx.command.dexer.Main.run(Main.java:230) at com.android.dx.command.dexer.Main.main(Main.java:199) at com.android.dx.command.Main.main(Main.java:103):Derp:dexDerpDebug FAILED
看起來是：在試圖將 classes和jar塞進一個Dex文件的過程中產生了錯誤。
早期的Dex文件保存所有classes的方法個數的范圍在0~65535之間。業務一直在增長，總悟君寫(copy)的代碼越來越長引入的庫越來越多，超過這個范圍只是時間問題。
怎么解？？太陽底下木有新鮮事，淡定先google一發，找找已經踩過坑的小伙伴。
StackOverflow 的網友們對該問題表示情緒穩定，談笑間拋出multiDex。
這是Android官網對當初的短視行為給出的補丁方案。文檔說，Dalvik Executable (DEX)文件的總方法數限制在65536以內，其中包括Android framwork method， lib method (后來總悟君發現僅僅是Android 自己的框架的方法就已經占用了1w多)，還有你的 code method ，所以請使用MultiDex。 對于5.0以下版本，請使用multidex support library (這個是我們的補丁包！build tools 請升級到21)。而5.0及以上版本，由于ART模式的存在，app第一次安裝之后會進行一次預編譯(pre-compilation) ，如果這時候發現了classes(..N).dex文件的存在就會將他們最終合成為一個.oat的文件，嗯看起來很厲害的樣子。
同時Google建議review代碼的直接或者間接依賴，盡可能減少依賴庫，設置proguard參數進一步優化去除無用的代碼。嗯，這兩個實施起來倒是很簡單，但是治標不治本，躲得過初一躲不過十五。 在Google給出這個解決方案之前，他們的開發人員先給了一個簡陋簡易版本的multiDex具體參看這里。（懷疑后來的官方解決方案就有這家伙參與）。簡單地說就是：1.先把你的app 的class 拆分成主次兩個dex。2.你的程序運行起來后，自己把第二個dex給load進來。看就這么簡單！而且這就是個動態加載模塊的框架！ 然而總悟君早已看穿Dalvik VM 這種動態加載dex 的能力歸根結底還是因為java 的classloader類加載機制。沿著這條道走，Android模塊動態化加載，包括dex級別和apk級別的動態化加載，各種玩法層出不窮。參見這里123456。
第一回合 天真的官方補丁方案
還是先解決打包問題，回頭再研究那些高深的動態化加載技術。偷懶一下咯考慮到投入產出比，決定使用Google官方的multiDex解決。(Google的補丁方案啊，不會再有坑了吧？后面才發現還是太天真) 該方案有兩步：
1.修改gradle腳本來產生多dex。
2.修改manifest 使用MulitDexApplication。
步驟1.在gradle腳本里寫上：
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. 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>
如果有自己的Application，繼承MulitDexApplication。如果當前代碼已經繼承自其它Application沒辦法修改那也行，就重寫 Application的attachBaseContext()這個方法。
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
} run一下，可以了！但是dex過程好像變慢了。。。
文檔還寫明了multiDex support lib 的局限。瞄一下是什么：
1.在應用安裝到手機上的時候dex文件的安裝是復雜的(complex)有可能會因為第二個dex文件太大導致ANR。請用proguard優化你的代碼。呵呵
2.使用了mulitDex的App有可能在4.0(api level 14)以前的機器上無法啟動，因為Dalvik linearAlloc bug(Issue 22586) 。請多多測試自祈多福。用proguard優化你的代碼將減少該bug幾率。呵呵
3.使用了mulitDex的App在runtime期間有可能因為Dalvik linearAlloc limit (Issue 78035) Crash。該內存分配限制在 4.0版本被增大，但是5.0以下的機器上的Apps依然會存在這個限制。
4.主dex被dalvik虛擬機執行時候，哪些類必須在主dex文件里面這個問題比較復雜。build tools 可以搞定這個問題。但是如果你代碼存在反射和native的調用也不保證100%正確。呵呵
感覺這就是個坑啊。補丁方案又引入一些問題。但是插件化方案要求對現有代碼有比較大的改動，代價太大，而且動態化加載框架意味著維護成本更高，會有更多潛在bug。所以先測試，遇到有問題的版本再解決。
第二回合 啥？dexopt failed？
呵呵，部分低端2.3機型(話說2.3版本的android機有高端機型么)安裝失敗！INSTALL_FAILED_DEXOPT。這個就是前面說的Issue 22586問題。
apk是一個zip壓縮包，dalvik每次加載apk都要從中解壓出class.dex文件，加載過程還涉及到dex的classes需要的雜七雜八的依賴庫的加載，真耗時間。于是Android決定優化一下這個問題，在app安裝到手機之后，系統運行dexopt程序對dex進行優化，將dex的依賴庫文件和一些輔助數據打包成odex文件。存放在cache/dalvik_cache目錄下。保存格式為apk路徑 @ apk名 @ classes.dex。這樣以空間換時間大大縮短讀取/加載dex文件的過程。
那剛才那個bug是啥問題呢，原來dexopt程序的dalvik分配一塊內存來統計你的app的dex里面的classes的信息，由于classes太多方法太多超過這個linearAlloc 的限制 。那減小dex的大小就可以咯。
gradle腳本如下：
android.applicationVariants.all {
variant ->
dex.doFirst{
dex->
if (dex.additionalParameters == null) {
dex.additionalParameters = []
}
dex.additionalParameters += '--set-max-idx-number=48000'
}
} --set-max-idx-number=
為FB的工程師的機智和務實精神點贊！然而總悟君不愿意花那么多精力實現FB的hack方法。（dvk虛擬機c層代碼在2.x 4.x 版本里有變更，找到那個內存地址太難，未必搞得定啊）我們有偷懶的解決方案，為了避免2.3機型runtime 的linearAlloclimit ,最好保持每一個dex體積<4M ,剛才的的value<=48000
好了 現在2.3的機器可以安裝run起來了！
第三回合 ANR的意思就是Application Not Responding
問題又來了！這次不僅僅是2.3 的機型！還有一些中檔配置的4.x系統的機型。問題現象是：第一次安裝后，點擊圖標，1s，2s，3s... 程序沒有任何反應就好像你沒點圖標一樣。
5s過去。。。程序ANR!
其實不僅僅總悟君的App存在這個問題，其他很多App也存在首次安裝運行后幾秒都無任何響應的現象或者最后ANR了。唯一的例外是美團App，點擊圖標立馬就出現界面。唉要不就算啦？反正就一次。。。不行，這可是產品給用戶的第一印象啊太重要了，而且美團搞得定就說明這問題有解決方案。
ANR了是不是局限1描述的現象？？不過也不重要...因為Google只是告訴你說第二個dex太大了導致的。并沒有進一步解釋根本原因。怎么辦？Google一發？搜索點擊圖標 然后ANR？怎么可能有解決方案嘛。ANR就意味著UI線程被阻塞了，老老實實查看log吧。
adb logcat -v time > log.txt
于是發現 是 install dex + dexopt 時間太長！
梳理一下流程：
安裝完app點擊圖標之后，系統木有發現對應的process，于是從該apk抽取classes.dex(主dex) 加載，觸發 一次dexopt。
App 的laucherActivity準備啟動 ，觸發Application啟動，
Application的 onattach（）方法調用，這時候MultiDex.install（）調用，classes2.dex 被install，再次觸發dexopt。
然后Applicaition onCreate（）執行。
然后 launcher Activity真的起來了。
這些必須在5s內完成不然就ANR給你看！
有點棘手。首先主dex是無論如何都繞不過加載和dexopt的。如果主dex比較小的話可以節省時間。主dex小就意味著后面的dex大啊，MultiDex.install（）是在主線程里做的，總時間又沒有實質性改變。install（） 能不能放到線程里做啊？貌似不行。。。如果異步化，什么時候install完成都不知道。這時候如果進程需要seconday.dex里的classes信息不就悲劇？主dex越小這個錯誤幾率就越大。要悲劇啊總悟君。
淡定，這次Google搜索MultiDex.install 。于是總悟君發現了美團多dex拆包方案。 讀完之后感覺看到勝利曙光。美團的主要思路是：精簡主dex+異步加載secondary.dex 。對異步化執行速度的不確定性，他們的解決方案是重寫Instrumentation execStartActivity 方法，hook跳轉Activity的總入口做判斷，如果當前secondary.dex 還沒有加載完成，就彈一個loading Activity等待加載完成，如果已經加載完成那最好不過了。不錯，RTFSC果然是王道。 可以試一試。
但是有幾個問題需要解決：
1.分析主dex需要的classes這個腳本比較難寫。。。Google文檔說過這個問題比較復雜， 而且buildTools 不是已經幫我們搞定了嗎？去瞄一下主dex的大小：8M 以及secondary.dex 3M 。 它是如何工作的？文檔說dx的時候，先依據manifest里注冊的組件生成一個 main-list，然后把這list里的classes所依賴的classes找出來，把他們打成classes.dex就是主dex。剩下的classes都放clsses2.dex(如果使用參數限制dex大小的話可能會有classe3.ex 等等） 。主dex至少含有main-list 的classes + 直接依賴classes ，使用mini-main-list參數可以僅僅包含剛才說的classes。
關于寫分析腳本的思路是：直接使用mini-main-list參數獲取build目錄下的main-list文件，這樣manifest聲明的類和他們的直接依賴類搞定的了，那后者的直接依賴類怎么解？這些在dvk runtime也是必須的classes。一個思路是解析class文件獲得該class的依賴類。還一個思路是自己使用Dexclassloader 加載dex，然后hook getClass()方法，調用一次就記錄一個。都挺折騰的。
2.由于歷史原因，總悟君在維護的App的manifest注冊的組件的那些類，承載業務太多，依賴很多三方jar，導致直接依賴類非常多，而且短時間內無法梳理精簡，沒辦法mini化主dex。
3.Application的啟動入口太多。Appication初始化未必是由launcher Activity的啟動觸發，還有可能是因為Service ，Receiver ，ContentProvider 的啟動。 靠攔截重寫Instrumentation execStartActivity 解決不了問題。要為 Service ，Receiver ，ContentProvider 分別寫基類，然后在oncreate()里判斷是否要異步加載secondary.dex。如果需要，彈出Loading Acitvity？用戶看到這個會感覺比較怪異。
結合自身App的實際情況來看美團的拆包方案雖然很美好然但是不能照搬啊。果然不能愉快地回家看動漫了。
第四回合 換一種思路
考慮到剛才說的2，3原因，先不要急著動手寫分析腳本。總悟君期望找到更好的方案。問題到現在變成了:既希望在Application的attachContext（）方法里同步加載secondary.dex，又不希望卡住UI線程。如果思路限制在線程異步化上，確實不可能實現。于是發現了微信開發團隊的這篇文章。該文章介紹了關于這一問題 FB/QQ/微信的解決方案。FB的解決思路特別贊，讓Launcher Activity在另外一個進程啟動！當然這個Launcher Activity就是用來load dex 的 ，load完成就啟動Main Activity。
微信這篇文章給出了一個非常重要的觀點：安裝完成之后第一次啟動時，是secondary.dex的dexopt花費了更多的時間。認識到這點非常重要，使得問題又轉化為：在不阻塞UI線程的前提下，完成dexopt，以后都不需要再次dexopt，所以可以在UI線程install dex 了！文章最后給了一個對FB方案的改進版。
仔細讀完感覺完全可行。
1.對現有代碼改動量最小。
2.該方案不關注Application被哪個組件啟動。Activity ，Service ，Receiver ，ContentProvider 都滿足。(有個問題要說明：如細心網友指出的那樣，新安裝還未啟動但是收到Receiver的場景下，會導致Load界面出現。這個場景實際出現幾率比較少，且僅出現一次。可以接受。)
3.該方案不限制 Application ，Activity ，Service ，Receiver ，ContentProvider 繼續新增業務。
于是總悟君實現了這篇文章最后介紹的改進版的方法，稍微有一點點擴充。
流程圖如下
上最終解決問題版的代碼！
在Application里面(這里不要再繼承自MultiApplication了，我們要手動加載Dex):
import java.util.Map;
import java.util.jar.Attributes;
import java.util.jar.JarFile;
import java.util.jar.Manifest;
public class App extends Application {
public static final String KEY_DEX2_SHA1 = "dex2-SHA1-Digest";
@Override
protected void attachBaseContext(Context base) {
super .attachBaseContext(base);
LogUtils.d( "loadDex", "App attachBaseContext ");
if (!quickStart() && Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP) {//>=5.0的系統默認對dex進行oat優化
if (needWait(base)){
waitForDexopt(base);
}
MultiDex.install (this );
} else {
return;
}
}
@Override
public void onCreate() {
super .onCreate();
if (quickStart()) {
return;
}
...
}
public boolean quickStart() {
if (StringUtils.contains( getCurProcessName(this), ":mini")) {
LogUtils.d( "loadDex", ":mini start!");
return true;
}
return false ;
}
//neead wait for dexopt ?
private boolean needWait(Context context){
String flag = get2thDexSHA1(context);
LogUtils.d( "loadDex", "dex2-sha1 "+flag);
SharedPreferences sp = context.getSharedPreferences(
PackageUtil.getPackageInfo(context). versionName, MODE_MULTI_PROCESS);
String saveValue = sp.getString(KEY_DEX2_SHA1, "");
return !StringUtils.equals(flag,saveValue);
}
/**
* Get classes.dex file signature
* @param context
* @return
*/
private String get2thDexSHA1(Context context) {
ApplicationInfo ai = context.getApplicationInfo();
String source = ai.sourceDir;
try {
JarFile jar = new JarFile(source);
Manifest mf = jar.getManifest();
Map<String, Attributes> map = mf.getEntries();
Attributes a = map.get("classes2.dex");
return a.getValue("SHA1-Digest");
} catch (Exception e) {
e.printStackTrace();
}
return null ;
}
// optDex finish
public void installFinish(Context context){
SharedPreferences sp = context.getSharedPreferences(
PackageUtil.getPackageInfo(context).versionName, MODE_MULTI_PROCESS);
sp.edit().putString(KEY_DEX2_SHA1,get2thDexSHA1(context)).commit();
}
public static String getCurProcessName(Context context) {
try {
int pid = android.os.Process.myPid();
ActivityManager mActivityManager = (ActivityManager) context
.getSystemService(Context. ACTIVITY_SERVICE);
for (ActivityManager.RunningAppProcessInfo appProcess : mActivityManager
.getRunningAppProcesses()) {
if (appProcess.pid == pid) {
return appProcess. processName;
}
}
} catch (Exception e) {
// ignore
}
return null ;
}
public void waitForDexopt(Context base) {
Intent intent = new Intent();
ComponentName componentName = new
ComponentName( "com.zongwu", LoadResActivity.class.getName());
intent.setComponent(componentName);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
base.startActivity(intent);
long startWait = System.currentTimeMillis ();
long waitTime = 10 * 1000 ;
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB_MR1 ) {
waitTime = 20 * 1000 ;//實測發現某些場景下有些2.3版本有可能10s都不能完成optdex
}
while (needWait(base)) {
try {
long nowWait = System.currentTimeMillis() - startWait;
LogUtils.d("loadDex" , "wait ms :" + nowWait);
if (nowWait >= waitTime) {
return;
}
Thread.sleep(200 );
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
} PackageUtil的方法
public static PackageInfo getPackageInfo(Context context){
PackageManager pm = context.getPackageManager();
try {
return pm.getPackageInfo(context.getPackageName(), 0);
} catch (PackageManager.NameNotFoundException e) {
LogUtils.e(e.getLocalizedMessage());
}
return new PackageInfo();
} 這里使用了classes(N).dex的方式保存了后面的dex而不是像微信目前的做法放到assest文件夾。前面有說到ART模式會將多個dex優化合并成oat文件。如果放置在asset里面就沒有這個好處了。
Launcher Activity 依然是原來的代碼里的WelcomeActivity。
在Application啟動的時候會檢測dexopt是否已經完成過，（檢測方式是查看sp文件是否有dex文件的SHA1-Digest記錄，這里要兩個進程讀取該sp,讀取模式是MODE_MULTI_PROCESS）。如果沒有就啟動LoadDexActivity(屬于：mini進程) 。否則就直接install dex ！對，直接install。通過日志發現，已經dexopt的dex文件再次install的時候 只耗費幾十毫秒。
LoadDexActivity 的邏輯比較簡單，啟動AsyncTask 來install dex 這時候會觸發dexopt 。
public class LoadResActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
requestWindowFeature(Window.FEATURE_NO_TITLE);
super .onCreate(savedInstanceState);
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN , WindowManager.LayoutParams.FLAG_FULLSCREEN );
overridePendingTransition(R.anim.null_anim, R.anim.null_anim);
setContentView(R.layout.layout_load);
new LoadDexTask().execute();
}
class LoadDexTask extends AsyncTask {
@Override
protected Object doInBackground(Object[] params) {
try {
MultiDex.install(getApplication());
LogUtils.d("loadDex" , "install finish" );
((App) getApplication()).installFinish(getApplication());
} catch (Exception e) {
LogUtils.e("loadDex" , e.getLocalizedMessage());
}
return null;
}
@Override
protected void onPostExecute(Object o) {
LogUtils.d( "loadDex", "get install finish");
finish();
System.exit( 0);
}
}
@Override
public void onBackPressed() {
//cannot backpress
} Manifest.xml 里面
<activity android:name= "com.zongwu.LoadResActivity" android:launchMode= "singleTask" android:process= ":mini" android:alwaysRetainTaskState= "false" android:excludeFromRecents= "true" android:screenOrientation= "portrait" /> <activity android:name= "com.zongwu.WelcomeActivity" android:launchMode= "singleTop" android:screenOrientation= "portrait"> <intent-filter > <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter > </activity>
替換Activity默認的出現動畫 R.anim.null_anim 文件的定義：
<set xmlns:android="http://schemas.android.com/apk/res/android"> <alpha android:fromAlpha="1.0" android:toAlpha="1.0" android:duration="550"/> </set>
如微信開發團隊的這篇文章所說，application啟動了LoadDexActivity之后，自身不再是前臺進程所以怎么hold 線程都不會ANR。
系統何時會對apk進行dexopt總悟君其實并沒有十分明白。通過查看安裝運行的日志發現，安裝的時候packageManagerService會對classes.dex 進行dexopt 。在調用MultiDex.install（）加載 secondary.dex的時候，也會進行一次dexopt 。 這背后的流程到底是怎樣的？dexopt是如何在另外一個進程執行的？如果是另外一個進程執行為何會阻塞主app的UI進程？ 官方文檔并沒有詳細介紹這個，那就RTFSC一探究竟吧.
源代碼跟蹤比較長，移步到這里看吧。
最終章碎碎念
-
MultiDex的問題難點在：要持續解決好幾個bug才能最終解決問題。進一步的，想要仔細分辨且解決這些bug，就必須持續探索一些關聯性的概念和原理
-
耗費了這么多時間來解決了Android系統的缺陷是不是有點略傷心。這不應該是Google給出一個比較徹底的解決方案嗎？
-
FB的工程師們腦洞好大。思考問題的方式很值得借鑒。
-
微信團隊的文章提到逆向了不少App。哈！總悟君感覺增長知識拓寬視野的新技能加強。
-
RTFSC是王道。
-
在查看log的過程中發現一個比較有趣的現象。在App的secondary.dex加載之前居然先加載了某數字公司的dex！(手機沒有root但是安裝了xx手機助手)再加上之前看到的錯誤堆棧里Android framework的調用堆棧之間也赫然有他們的代碼。總悟君惡意猜測該app利用了某種手段進行了提權，hook了系統框架代碼，將自己的代碼注入到了每一個應用app的進程里。嗯。。。有趣。。。
-
嗯今晚已經沒有時間看動漫了。。。
原文出處：http://zongwu233.github.io/the-touble-of-multidex/
來自： http://www.jcodecraeer.com//a/anzhuokaifa/androidkaifa/2015/1218/3789.html