背景：
剛剛通過MultiDex 解決了Android 65535 的坑，怎么又出現(xiàn)了這個問題？ MultiDex 是官方的解決方案難道還有問題？
先來說下MultiDex 是怎么回事
分兩步：
1.修改gradle腳本來產(chǎn)生多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聲明修改為MultiDexApplication
如果有自己的Application，繼承MulitDexApplication。如果當前代碼已經(jīng)繼承自其它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優(yōu)化你的代碼。呵呵
2.使用了mulitDex的App有可能在4.0(api level 14)以前的機器上無法啟動，因為Dalvik linearAlloc bug(Issue 22586) 。請多多測試自祈多福。用proguard優(yōu)化你的代碼將減少該bug幾率。呵呵
3.使用了mulitDex的App在runtime期間有可能因為Dalvik linearAlloc limit (Issue 78035) Crash。該內(nèi)存分配限制在 4.0版本被增大，但是5.0以下的機器上的Apps依然會存在這個限制。
4.主dex被dalvik虛擬機執(zhí)行時候，哪些類必須在主dex文件里面這個問題比較復雜。build tools 可以搞定這個問題。但是如果你代碼存在反射和native的調(diào)用也不保證100%正確。呵呵
感覺這就是個坑啊。補丁方案又引入一些問題。但是插件化方案要求對現(xiàn)有代碼有比較大的改動，代價太大，而且動態(tài)化加載框架意味著維護成本更高，會有更多潛在bug。所以先測試，遇到有問題的版本再解決。
4.0 系統(tǒng) ANR 了 ？
問題又來了！這次不僅僅是2.3 的機型！還有一些中檔配置的4.x系統(tǒng)的機型。問題現(xiàn)象是：第一次安裝后，點擊圖標，1s，2s，3s... 程序沒有任何反應就好像你沒點圖標一樣。
5s過去。。。程序ANR!
其實不僅僅總悟君的App存在這個問題，其他很多App也存在首次安裝運行后幾秒都無任何響應的現(xiàn)象或者最后ANR了。唯一的例外是美團App，點擊圖標立馬就出現(xiàn)界面。唉要不就算啦？反正就一次。。。不行，這可是產(chǎn)品給用戶的第一印象啊太重要了，而且美團搞得定就說明這問題有解決方案。
ANR了是不是局限1描述的現(xiàn)象？？不過也不重要...因為Google只是告訴你說第二個dex太大了導致的。并沒有進一步解釋根本原因。怎么辦？Google一發(fā)？搜索點擊圖標 然后ANR？怎么可能有解決方案嘛。ANR就意味著UI線程被阻塞了，老老實實查看log吧。
adb logcat -v time > log.txt
于是發(fā)現(xiàn) 是 install dex + dexopt 時間太長！
梳理一下流程：
安裝完app點擊圖標之后，系統(tǒng)木有發(fā)現(xiàn)對應的process，于是從該apk抽取classes.dex(主dex) 加載，觸發(fā) 一次dexopt。
App 的laucherActivity準備啟動 ，觸發(fā)Application啟動，
Application的 onattach（）方法調(diào)用，這時候MultiDex.install（）調(diào)用，classes2.dex 被install，再次觸發(fā)dexopt。
然后Applicaition onCreate（）執(zhí)行。
然后 launcher Activity真的起來了。
這些必須在5s內(nèi)完成不然就ANR給你看！
有點棘手。首先主dex是無論如何都繞不過加載和dexopt的。如果主dex比較小的話可以節(jié)省時間。主dex小就意味著后面的dex大啊，MultiDex.install（）是在主線程里做的，總時間又沒有實質(zhì)性改變。install（） 能不能放到線程里做啊？貌似不行。。。如果異步化，什么時候install完成都不知道。這時候如果進程需要seconday.dex里的classes信息不就悲劇？主dex越小這個錯誤幾率就越大。要悲劇啊總悟君。
淡定，這次Google搜索MultiDex.install 。于是總悟君發(fā)現(xiàn)了美團多dex拆包方案。 讀完之后感覺看到勝利曙光。美團的主要思路是：精簡主dex+異步加載secondary.dex 。對異步化執(zhí)行速度的不確定性，他們的解決方案是重寫Instrumentation execStartActivity 方法，hook跳轉Activity的總入口做判斷，如果當前secondary.dex 還沒有加載完成，就彈一個loading Activity等待加載完成，如果已經(jīng)加載完成那最好不過了。不錯，RTFSC果然是王道。 可以試一試。
但是有幾個問題需要解決：
1.分析主dex需要的classes這個腳本比較難寫。。。Google文檔說過這個問題比較復雜， 而且buildTools 不是已經(jīng)幫我們搞定了嗎？去瞄一下主dex的大?。?M 以及secondary.dex 3M 。 它是如何工作的？文檔說dx的時候，先依據(jù)manifest里注冊的組件生成一個 main-list，然后把這list里的classes所依賴的classes找出來，把他們打成classes.dex就是主dex。剩下的classes都放clsses2.dex(如果使用參數(shù)限制dex大小的話可能會有classe3.ex 等等） 。主dex至少含有main-list 的classes + 直接依賴classes ，使用mini-main-list參數(shù)可以僅僅包含剛才說的classes。
關于寫分析腳本的思路是：直接使用mini-main-list參數(shù)獲取build目錄下的main-list文件，這樣manifest聲明的類和他們的直接依賴類搞定的了，那后者的直接依賴類怎么解？這些在dvk runtime也是必須的classes。一個思路是解析class文件獲得該class的依賴類。還一個思路是自己使用Dexclassloader 加載dex，然后hook getClass()方法，調(diào)用一次就記錄一個。都挺折騰的。
2.由于歷史原因，總悟君在維護的App的manifest注冊的組件的那些類，承載業(yè)務太多，依賴很多三方jar，導致直接依賴類非常多，而且短時間內(nèi)無法梳理精簡，沒辦法mini化主dex。
3.Application的啟動入口太多。Appication初始化未必是由launcher Activity的啟動觸發(fā)，還有可能是因為Service ，Receiver ，ContentProvider 的啟動。 靠攔截重寫Instrumentation execStartActivity 解決不了問題。要為 Service ，Receiver ，ContentProvider 分別寫基類，然后在oncreate()里判斷是否要異步加載secondary.dex。如果需要，彈出Loading Acitvity？用戶看到這個會感覺比較怪異。
結合自身App的實際情況來看美團的拆包方案雖然很美好然但是不能照搬啊。果然不能愉快地回家看動漫了。
相關資料
MultiDex中出現(xiàn)的main dex capacity exceeded解決之道
...
