隨著業務擴張，程式碼量越來越大，apk中單個dex方法數超過65K，就需要dex分包，Google官方推出了MultiDex來解決65K的問題，區分不同的Android虛擬機器，會有一些問題。

Dalvik上，使用JIT(just in time)，應用執行時，需要先將dex轉換成os上可以執行的機器碼，在此過程中，還會對dex檔案進行優化(dexopt)，因此在應用第一次啟動時，會經歷這些過程，apk解壓->dexopt->載入dex->位元組碼轉換->啟動，在載入dex過程中，安裝第二個dex之後的dex涉及到io操作，在dex載入完成之前，應用需要一直等待，此過程耗時較長，如果dex檔案過大，還會造成ANR；

ART上，使用oat(Ahead of time)，在應用安裝時，dex就會被解壓優化完成，轉換成可執行的機器碼，之後應用在啟動時，只需要載入機器碼即可，所以不會出現啟動ANR的問題。

為了解決Dalvik上冷啟動慢的問題，通常的方法是自定義第二個dex的載入流程，常用方案有以下幾種：

方案

原理

接入技術難度

優點

不足

風險

方案

原理

接入技術難度

優點

不足

風險

Google MultiDex

第一個啟動的程序的主執行緒上解壓安裝，同步執行，dex全部安裝完成之後，啟動應用

最簡單

dex載入完成之後，應用才真正開始執行，不會出現NoClassDefFoundError

啟動慢

dex檔案過大時，在低配裝置上可能會出現ANR、黑屏

微信/QQ

1、將dex檔案放在assets資料夾下，載入前校驗md5(官方沒校驗)；

2、四大元件的直接間接依賴都直接放在主dex中；

3、判斷是否已經dexopt，若已經dexopt，即放在attachBaseContext載入，反之放於地球中用執行緒載入（若判斷revision改變，即將dex以及dexopt目錄清空。只需簡單判斷兩個目錄dex名稱、數量是否與配置檔案的一致）

最複雜，需要自己寫指令碼掃描依賴集，以及自定義dex載入過程

啟動不會發生ANR，比Google的MultiDex更快

太過複雜，每次都需重新掃描依賴集，而且使用的是比較大的間接依賴集

無

Facebook

1、使用自己開源的buck進行dex分包；

2、將載入Dex的邏輯放於單獨的nodex程序，這是一個非常簡單、輕量級的程序。它沒有任何的ContentProvider，只有有限的幾個Activity、Service；

3、將啟動LauncherActivity放在nodex程序，啟動時在nodex程序中安裝dex，主程序一直等待，dex安裝完成之後，啟動應用；

比Google的MultiDex稍複雜一些

依賴集非常簡單，同時首次載入Dex時也不會卡死

啟動主程序之前，必須先啟動nodex程序，額外增加了啟動時間(大約幾百毫秒)

無

美團

1、使用gradle外掛進行分包，編譯期生成dex檔案時，將入口Activity直接依賴的類放入主dex中；

2、多dex安裝時，先載入主dex，啟動應用，後續dex非同步安裝，安裝完成之後，提供回撥方法；

3、hook Activity的啟動過程，如果在非同步載入dex期間就引用了未載入的類進行Activity跳轉，啟動一個Loading的頁面，直到所有dex載入完成；

接入很簡單，但是需要徹底解耦，否則主dex的方法數很容易超過65K，編譯不通過

啟動時間最快

有內部RD支援，方便定位問題

需要程式碼高度解耦，要改動業務程式碼

容易出現NoClassDefFoundError