在Android系統中，一個App的所有代碼都在一個Dex文件里面。Dex是一個類似Jar的存儲了多有Java編譯字節碼的歸檔文件。因為Android系統使用Dalvik虛擬機，所以需要把使用Java Compiler編譯之后的class文件轉換成Dalvik能夠執行的class文件。這里需要強調的是，Dex和Jar一樣是一個歸檔文件，里面仍然是Java代碼對應的字節碼文件。當Android系統啟動一個應用的時候，有一步是對Dex進行優化，這個過程有一個專門的工具來處理，叫DexOpt。DexOpt的執行過程是在第一次加載Dex文件的時候執行的。這個過程會生成一個ODEX文件，即Optimised Dex。執行ODex的效率會比直接執行Dex文件的效率要高很多。 但是在早期的Android系統中，DexOpt的LinearAlloc存在着限制: Android 2.2和2.3的緩沖區只有5MB，Android 4.x提高到了8MB或16MB。當方法數量過多導致超出緩沖區大小時，會造成dexopt崩潰,導致無法安裝.
另外由於DEX文件格式限制，一個DEX文件中method個數采用使用原生類型short來索引文件中的方法，也就是4個字節共計最多表達65536個method，field/class的個數也均有此限制。對於DEX文件，則是將工程所需全部class文件合並且壓縮到一個DEX文件期間，也就是Android打包的DEX過程中， 單個DEX文件可被引用的方法總數被限制為65536（自己開發以及所引用的Android Framework和第三方類庫的代碼）.
解決辦法 可以引入： compile 'com.android.support:multidex:1.+' 修改Application extends MultiDexApplication； 最后在build.gradle defaultConfig中加入：
defaultConfig { multiDexEnabled true }