申明. 本文章轉(zhuǎn)載于網(wǎng)絡(luò), 本人僅用于自我學(xué)習(xí)以及需要的朋友參考

一、遭遇MultiDex

愉快地寫著Android代碼的總悟君往工程里引入了一個(gè)默默無(wú)聞的jar然后Run了一下， 經(jīng)過(guò)漫長(zhǎng)的等待AndroidStudio構(gòu)建失敗了。
于是總悟君帶著疑惑查看錯(cuò)誤信息。

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

看起來(lái)是：在試圖將 classes和jar塞進(jìn)一個(gè)Dex文件的過(guò)程中產(chǎn)生了錯(cuò)誤。

早期的Dex文件保存所有classes的方法個(gè)數(shù)的范圍在0~65535之間。業(yè)務(wù)一直在增長(zhǎng)，總悟君寫(copy)的代碼越來(lái)越長(zhǎng)引入的庫(kù)越來(lái)越多，超過(guò)這個(gè)范圍只是時(shí)間問題。
怎么解？？太陽(yáng)底下木有新鮮事，淡定先google一發(fā)，找找已經(jīng)踩過(guò)坑的小伙伴。

StackOverflow 的網(wǎng)友們對(duì)該問題表示情緒穩(wěn)定，談笑間拋出multiDex。
這是Android官網(wǎng)對(duì)當(dāng)初的短視行為給出的補(bǔ)丁方案。文檔說(shuō)，Dalvik Executable (DEX)文件的總方法數(shù)限制在65536以內(nèi)，其中包括Android framwork method， lib method (后來(lái)總悟君發(fā)現(xiàn)僅僅是Android 自己的框架的方法就已經(jīng)占用了1w多)，還有你的 code method ，所以請(qǐng)使用MultiDex。 對(duì)于5.0以下版本，請(qǐng)使用multidex support library (這個(gè)是我們的補(bǔ)丁包！build tools 請(qǐng)升級(jí)到21)。而5.0及以上版本，由于ART模式的存在，app第一次安裝之后會(huì)進(jìn)行一次預(yù)編譯(pre-compilation) ，如果這時(shí)候發(fā)現(xiàn)了classes(..N).dex文件的存在就會(huì)將他們最終合成為一個(gè).oat的文件，嗯看起來(lái)很厲害的樣子。
同時(shí)Google建議review代碼的直接或者間接依賴，盡可能減少依賴庫(kù)，設(shè)置proguard參數(shù)進(jìn)一步優(yōu)化去除無(wú)用的代碼。嗯，這兩個(gè)實(shí)施起來(lái)倒是很簡(jiǎn)單，但是治標(biāo)不治本，躲得過(guò)初一躲不過(guò)十五。
在Google給出這個(gè)解決方案之前，他們的開發(fā)人員先給了一個(gè)簡(jiǎn)陋簡(jiǎn)易版本的multiDex具體參看這里。（懷疑后來(lái)的官方解決方案就有這家伙參與）。簡(jiǎn)單地說(shuō)就是：1.先把你的app 的class 拆分成主次兩個(gè)dex。2.你的程序運(yùn)行起來(lái)后，自己把第二個(gè)dex給load進(jìn)來(lái)?？淳瓦@么簡(jiǎn)單！而且這就是個(gè)動(dòng)態(tài)加載模塊的框架！ 然而總悟君早已看穿Dalvik VM 這種動(dòng)態(tài)加載dex 的能力歸根結(jié)底還是因?yàn)閖ava 的classloader類加載機(jī)制。沿著這條道走，Android模塊動(dòng)態(tài)化加載，包括dex級(jí)別和apk級(jí)別的動(dòng)態(tài)化加載，各種玩法層出不窮。參見這里1、2、3、4、5、6。

二、天真的官方補(bǔ)丁方案

還是先解決打包問題，回頭再研究那些高深的動(dòng)態(tài)化加載技術(shù)。偷懶一下，考慮到投入產(chǎn)出比，決定使用Google官方的multiDex解決。(Google的補(bǔ)丁方案啊，不會(huì)再有坑了吧？后面才發(fā)現(xiàn)還是太天真)
該方案有兩步：

1、修改gradle腳本來(lái)產(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聲明修改

<?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。如果當(dāng)前代碼已經(jīng)繼承自其它Application沒辦法修改那也行，就重寫 Application的attachBaseContext()這個(gè)方法。

@Override
protected void attachBaseContext(Context base) {
    super.attachBaseContext(base);
    MultiDex.install(this);     

}

run一下，可以了！但是dex過(guò)程好像變慢了。。。

文檔還寫明了multiDex support lib 的局限。瞄一下是什么：
1、在應(yīng)用安裝到手機(jī)上的時(shí)候dex文件的安裝是復(fù)雜的(complex)有可能會(huì)因?yàn)榈诙€(gè)dex文件太大導(dǎo)致ANR。請(qǐng)用proguard優(yōu)化你的代碼。呵呵
2、使用了mulitDex的App有可能在4.0(api level 14)以前的機(jī)器上無(wú)法啟動(dòng)，因?yàn)镈alvik linearAlloc bug(Issue 22586) 。請(qǐng)多多測(cè)試自祈多福。用proguard優(yōu)化你的代碼將減少該bug幾率。呵呵
3、使用了mulitDex的App在runtime期間有可能因?yàn)镈alvik linearAlloc limit (Issue 78035) Crash。該內(nèi)存分配限制在 4.0版本被增大，但是5.0以下的機(jī)器上的Apps依然會(huì)存在這個(gè)限制。
4、主dex被dalvik虛擬機(jī)執(zhí)行時(shí)候，哪些類必須在主dex文件里面這個(gè)問題比較復(fù)雜。build tools 可以搞定這個(gè)問題。但是如果你代碼存在反射和native的調(diào)用也不保證100%正確。呵呵

感覺這就是個(gè)坑啊。補(bǔ)丁方案又引入一些問題。但是插件化方案要求對(duì)現(xiàn)有代碼有比較大的改動(dòng)，代價(jià)太大，而且動(dòng)態(tài)化加載框架意味著維護(hù)成本更高，會(huì)有更多潛在bug。所以先測(cè)試，遇到有問題的版本再解決。

三、啥？dexopt failed？

呵呵，部分低端2.3機(jī)型(話說(shuō)2.3版本的android機(jī)有高端機(jī)型么)安裝失??！INSTALL_FAILED_DEXOPT。這個(gè)就是前面說(shuō)的Issue 22586問題。

apk是一個(gè)zip壓縮包，dalvik每次加載apk都要從中解壓出class.dex文件，加載過(guò)程還涉及到dex的classes需要的雜七雜八的依賴庫(kù)的加載，真耗時(shí)間。于是Android決定優(yōu)化一下這個(gè)問題，在app安裝到手機(jī)之后，系統(tǒng)運(yùn)行dexopt程序?qū)ex進(jìn)行優(yōu)化，將dex的依賴庫(kù)文件和一些輔助數(shù)據(jù)打包成odex文件。存放在cache/dalvik_cache目錄下。保存格式為apk路徑 @ apk名 @ classes.dex。這樣以空間換時(shí)間大大縮短讀取/加載dex文件的過(guò)程。

那剛才那個(gè)bug是啥問題呢，原來(lái)dexopt程序的dalvik分配一塊內(nèi)存來(lái)統(tǒng)計(jì)你的app的dex里面的classes的信息，由于classes太多方法太多超過(guò)這個(gè)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= <value>用于控制每一個(gè)dex的最大方法個(gè)數(shù)，寫小一點(diǎn)可以產(chǎn)生好幾個(gè)dex。
踩過(guò)更多坑的FB的工程師表示這個(gè)linearAlloc的限制不僅僅在安裝時(shí)候的dexopt程序里7，還在你的app的dalvik rumtime里。（很顯然啊dvk vm的宿主進(jìn)程fork自于同一個(gè)母體?。榱吮硎緦?duì)這個(gè)坑的不滿以及對(duì)Google的產(chǎn)品表示遺憾，F(xiàn)B工程師Read The Fucking Source Code找到了一個(gè)hack方案。這個(gè)linearAlloc的size定義在c層而且是一個(gè)全局變量，他們通過(guò)對(duì)結(jié)構(gòu)體的size的計(jì)算成功覆蓋了該值的內(nèi)容，這里要特別感謝C語(yǔ)言的指針和內(nèi)存的設(shè)計(jì)。C的世界里，You Are The King of This World。當(dāng)然實(shí)際情況是大部分用戶用這把利刃割傷了自己。。。別問總悟君誰(shuí)是世界上最好的語(yǔ)言。。。

為FB的工程師的機(jī)智和務(wù)實(shí)精神點(diǎn)贊！然而總悟君不愿意花那么多精力實(shí)現(xiàn)FB的hack方法。（dvk虛擬機(jī)c層代碼在2.x 4.x 版本里有變更，找到那個(gè)內(nèi)存地址太難，未必搞得定啊）我們有偷懶的解決方案，為了避免2.3機(jī)型runtime 的linearAlloclimit ,最好保持每一個(gè)dex體積<4M ,剛才的的value<=48000

好了 現(xiàn)在2.3的機(jī)器可以安裝run起來(lái)了！

四、ANR的意思就是Application Not Responding

問題又來(lái)了！這次不僅僅是2.3 的機(jī)型！還有一些中檔配置的4.x系統(tǒng)的機(jī)型。問題現(xiàn)象是：第一次安裝后，點(diǎn)擊圖標(biāo)，1s，2s，3s… 程序沒有任何反應(yīng)就好像你沒點(diǎn)圖標(biāo)一樣。

5s過(guò)去。。。程序ANR!

其實(shí)不僅僅總悟君的App存在這個(gè)問題，其他很多App也存在首次安裝運(yùn)行后幾秒都無(wú)任何響應(yīng)的現(xiàn)象或者最后ANR了。唯一的例外是美團(tuán)App，點(diǎn)擊圖標(biāo)立馬就出現(xiàn)界面。唉要不就算啦？反正就一次。。。不行，這可是產(chǎn)品給用戶的第一印象啊太重要了，而且美團(tuán)搞得定就說(shuō)明這問題有解決方案。

ANR了是不是局限1描述的現(xiàn)象？？不過(guò)也不重要…因?yàn)镚oogle只是告訴你說(shuō)第二個(gè)dex太大了導(dǎo)致的。并沒有進(jìn)一步解釋根本原因。怎么辦？Google一發(fā)？搜索點(diǎn)擊圖標(biāo) 然后ANR？怎么可能有解決方案嘛。ANR就意味著UI線程被阻塞了，老老實(shí)實(shí)查看log吧。

adb logcat -v time > log.txt

于是發(fā)現(xiàn) 是 install dex + dexopt 時(shí)間太長(zhǎng)！

梳理一下流程：
安裝完app點(diǎn)擊圖標(biāo)之后，系統(tǒng)木有發(fā)現(xiàn)對(duì)應(yīng)的process，于是從該apk抽取classes.dex(主dex) 加載，觸發(fā) 一次dexopt。

App 的laucherActivity準(zhǔn)備啟動(dòng) ，觸發(fā)Application啟動(dòng)，

Application的 onattach（）方法調(diào)用，這時(shí)候MultiDex.install（）調(diào)用，classes2.dex 被install，再次觸發(fā)dexopt。

然后Applicaition onCreate（）執(zhí)行。

然后 launcher Activity真的起來(lái)了。

這些必須在5s內(nèi)完成不然就ANR給你看！

有點(diǎn)棘手。首先主dex是無(wú)論如何都繞不過(guò)加載和dexopt的。如果主dex比較小的話可以節(jié)省時(shí)間。主dex小就意味著后面的dex大啊，MultiDex.install（）是在主線程里做的，總時(shí)間又沒有實(shí)質(zhì)性改變。install（） 能不能放到線程里做?。棵菜撇恍?。。。如果異步化，什么時(shí)候install完成都不知道。這時(shí)候如果進(jìn)程需要seconday.dex里的classes信息不就悲?。恐鱠ex越小這個(gè)錯(cuò)誤幾率就越大。要悲劇啊總悟君。
淡定，這次Google搜索MultiDex.install 。于是總悟君發(fā)現(xiàn)了美團(tuán)多dex拆包方案。 讀完之后感覺看到勝利曙光。美團(tuán)的主要思路是：精簡(jiǎn)主dex+異步加載secondary.dex 。對(duì)異步化執(zhí)行速度的不確定性，他們的解決方案是重寫Instrumentation execStartActivity 方法，hook跳轉(zhuǎn)Activity的總?cè)肟谧雠袛啵绻?dāng)前secondary.dex 還沒有加載完成，就彈一個(gè)loading Activity等待加載完成，如果已經(jīng)加載完成那最好不過(guò)了。不錯(cuò)，RTFSC果然是王道。
可以試一試。

但是有幾個(gè)問題需要解決：
1、分析主dex需要的classes這個(gè)腳本比較難寫。。。Google文檔說(shuō)過(guò)這個(gè)問題比較復(fù)雜， 而且buildTools 不是已經(jīng)幫我們搞定了嗎？去瞄一下主dex的大?。?M 以及secondary.dex 3M 。 它是如何工作的？文檔說(shuō)dx的時(shí)候，先依據(jù)manifest里注冊(cè)的組件生成一個(gè) main-list，然后把這list里的classes所依賴的classes找出來(lái)，把他們打成classes.dex就是主dex。剩下的classes都放clsses2.dex(如果使用參數(shù)限制dex大小的話可能會(huì)有classe3.ex 等等） 。主dex至少含有main-list 的classes + 直接依賴classes ，使用mini-main-list參數(shù)可以僅僅包含剛才說(shuō)的classes。

關(guān)于寫分析腳本的思路是：直接使用mini-main-list參數(shù)獲取build目錄下的main-list文件，這樣manifest聲明的類和他們的直接依賴類搞定的了，那后者的直接依賴類怎么解？這些在dvk runtime也是必須的classes。一個(gè)思路是解析class文件獲得該class的依賴類。還一個(gè)思路是自己使用Dexclassloader 加載dex，然后hook getClass()方法，調(diào)用一次就記錄一個(gè)。都挺折騰的。

2、由于歷史原因，總悟君在維護(hù)的App的manifest注冊(cè)的組件的那些類，承載業(yè)務(wù)太多，依賴很多三方j(luò)ar，導(dǎo)致直接依賴類非常多，而且短時(shí)間內(nèi)無(wú)法梳理精簡(jiǎn)，沒辦法mini化主dex。

3、Application的啟動(dòng)入口太多。Appication初始化未必是由launcher Activity的啟動(dòng)觸發(fā)，還有可能是因?yàn)镾ervice ，Receiver ，ContentProvider 的啟動(dòng)。 靠攔截重寫Instrumentation execStartActivity 解決不了問題。要為 Service ，Receiver ，ContentProvider 分別寫基類，然后在oncreate()里判斷是否要異步加載secondary.dex。如果需要，彈出Loading Acitvity？用戶看到這個(gè)會(huì)感覺比較怪異。

結(jié)合自身App的實(shí)際情況來(lái)看美團(tuán)的拆包方案雖然很美好然但是不能照搬啊。果然不能愉快地回家看動(dòng)漫了。

五、換一種思路

考慮到剛才說(shuō)的2，3原因，先不要急著動(dòng)手寫分析腳本?？偽蚓谕业礁玫姆桨?。問題到現(xiàn)在變成了:既希望在Application的attachContext（）方法里同步加載secondary.dex，又不希望卡住UI線程。如果思路限制在線程異步化上，確實(shí)不可能實(shí)現(xiàn)。于是發(fā)現(xiàn)了微信開發(fā)團(tuán)隊(duì)的這篇文章。該文章介紹了關(guān)于這一問題 FB/QQ/微信的解決方案。FB的解決思路特別贊，讓Launcher Activity在另外一個(gè)進(jìn)程啟動(dòng)！當(dāng)然這個(gè)Launcher Activity就是用來(lái)load dex 的 ，load完成就啟動(dòng)Main Activity。
微信這篇文章給出了一個(gè)非常重要的觀點(diǎn)：安裝完成之后第一次啟動(dòng)時(shí)，是secondary.dex的dexopt花費(fèi)了更多的時(shí)間。認(rèn)識(shí)到這點(diǎn)非常重要，使得問題又轉(zhuǎn)化為：在不阻塞UI線程的前提下，完成dexopt，以后都不需要再次dexopt，所以可以在UI線程install dex 了！文章最后給了一個(gè)對(duì)FB方案的改進(jìn)版。

仔細(xì)讀完感覺完全可行。

1、對(duì)現(xiàn)有代碼改動(dòng)量最小。

2、該方案不關(guān)注Application被哪個(gè)組件啟動(dòng)。Activity ，Service ，Receiver ，ContentProvider 都滿足。(有個(gè)問題要說(shuō)明：如細(xì)心網(wǎng)友指出的那樣，新安裝還未啟動(dòng)但是收到Receiver的場(chǎng)景下，會(huì)導(dǎo)致Load界面出現(xiàn)。這個(gè)場(chǎng)景實(shí)際出現(xiàn)幾率比較少，且僅出現(xiàn)一次?？梢越邮?。)

3、該方案不限制 Application ，Activity ，Service ，Receiver ，ContentProvider 繼續(xù)新增業(yè)務(wù)。

于是總悟君實(shí)現(xiàn)了這篇文章最后介紹的改進(jìn)版的方法，稍微有一點(diǎn)點(diǎn)擴(kuò)充。

六、解決方法

上最終解決問題版的代碼！

在Application里面(這里不要再繼承自MultiApplication了，我們要手動(dòng)加載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的系統(tǒng)默認(rèn)對(duì)dex進(jìn)行oat優(yōu)化
            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 ;//實(shí)測(cè)發(fā)現(xiàn)某些場(chǎng)景下有些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文件夾。前面有說(shuō)到ART模式會(huì)將多個(gè)dex優(yōu)化合并成oat文件。如果放置在asset里面就沒有這個(gè)好處了。

Launcher Activity 依然是原來(lái)的代碼里的WelcomeActivity。

在Application啟動(dòng)的時(shí)候會(huì)檢測(cè)dexopt是否已經(jīng)完成過(guò)，（檢測(cè)方式是查看sp文件是否有dex文件的SHA1-Digest記錄，這里要兩個(gè)進(jìn)程讀取該sp,讀取模式是MODE_MULTI_PROCESS）。如果沒有就啟動(dòng)LoadDexActivity(屬于：mini進(jìn)程) 。否則就直接install dex ！對(duì)，直接install。通過(guò)日志發(fā)現(xiàn)，已經(jīng)dexopt的dex文件再次install的時(shí)候 只耗費(fèi)幾十毫秒。

LoadDexActivity 的邏輯比較簡(jiǎn)單，啟動(dòng)AsyncTask 來(lái)install dex 這時(shí)候會(huì)觸發(fā)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èn)的出現(xiàn)動(dòng)畫 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>

如微信開發(fā)團(tuán)隊(duì)的這篇文章所說(shuō)，application啟動(dòng)了LoadDexActivity之后，自身不再是前臺(tái)進(jìn)程所以怎么hold 線程都不會(huì)ANR。

系統(tǒng)何時(shí)會(huì)對(duì)apk進(jìn)行dexopt總悟君其實(shí)并沒有十分明白。通過(guò)查看安裝運(yùn)行的日志發(fā)現(xiàn)，安裝的時(shí)候packageManagerService會(huì)對(duì)classes.dex 進(jìn)行dexopt 。在調(diào)用MultiDex.install（）加載 secondary.dex的時(shí)候，也會(huì)進(jìn)行一次dexopt 。 這背后的流程到底是怎樣的？dexopt是如何在另外一個(gè)進(jìn)程執(zhí)行的？如果是另外一個(gè)進(jìn)程執(zhí)行為何會(huì)阻塞主app的UI進(jìn)程？ 官方文檔并沒有詳細(xì)介紹這個(gè)，那就RTFSC一探究竟吧.

源代碼跟蹤比較長(zhǎng)，移步到這里看吧。

七、最終章碎碎念

• MultiDex的問題難點(diǎn)在：要持續(xù)解決好幾個(gè)bug才能最終解決問題。進(jìn)一步的，想要仔細(xì)分辨且解決這些bug，就必須持續(xù)探索一些關(guān)聯(lián)性的概念和原理
• 耗費(fèi)了這么多時(shí)間來(lái)解決了Android系統(tǒng)的缺陷是不是有點(diǎn)略傷心。這不應(yīng)該是Google給出一個(gè)比較徹底的解決方案嗎？
• FB的工程師們腦洞好大。思考問題的方式很值得借鑒。
• 微信團(tuán)隊(duì)的文章提到逆向了不少App。哈！總悟君感覺增長(zhǎng)知識(shí)拓寬視野的新技能加強(qiáng)。
• RTFSC是王道。
• 在查看log的過(guò)程中發(fā)現(xiàn)一個(gè)比較有趣的現(xiàn)象。在App的secondary.dex加載之前居然先加載了某數(shù)字公司的dex！(手機(jī)沒有root但是安裝了xx手機(jī)助手)再加上之前看到的錯(cuò)誤堆棧里Android framework的調(diào)用堆棧之間也赫然有他們的代碼?？偽蚓龕阂獠聹y(cè)該app利用了某種手段進(jìn)行了提權(quán)，hook了系統(tǒng)框架代碼，將自己的代碼注入到了每一個(gè)應(yīng)用app的進(jìn)程里。嗯。。。有趣。。。

嗯今晚已經(jīng)沒有時(shí)間看動(dòng)漫了。。。