Unable to execute dex: method ID not in [0, 0xffff

一、使用動態加載技術時，通常須要用到這兩個類加載器：

• PathClassLoader - 只能加載已經安裝的apk，即/data/app目錄下的apk。
• DexClassLoader - 能加載手機中未安裝的apk、jar、dex，只要能在找到對應的路徑。

http://blog.csdn.net/u010687392/article/details/47121729

二、開發時提早編譯多個dex

原理：

第一步將項目中的代碼提早生成jar包，最好是不常改動的代碼。 將第三方jar包和第1步中生成的jar包，cmd執行SDK中的dx.bat命令，將jar包編譯生成dex文件，好比v4.dex，v7.dex，map.dex等，最好一類功能或模塊對應一個dex，而後將這些dex文件放進assets文件夾中。

將以上生成dex的jar包，作成編譯環境Library。相似於android.jar，這個Library只參與主項目代碼編譯，不參與項目打包。這樣項目就不會報錯，能正常編譯運行。 最後同第一種方案，手動加載assets文件中的dex文件，須要用到一個MultiDex.java文件的API。 優勢： 能很大程度上解決65534的問題，且因爲預先編譯dex，因此項目在開發期間編譯運行效率能提升不少。

缺點： 打包生成的apk體積依然龐大，且只能拆分項目裏的公共模塊和第三方jar包，因此對於業務和開發者龐大的項目來講，全部人在一個項目裏開發協做起來依然存在問題，並且res資源文件依舊是個難以拆分的問題。

http://xybcoder.github.io/2016/04/27/Multidex%E8%A7%A3%E5%86%B3%E6%96%B9%E6%B3%95%E6%95%B0%E8%B6%8A%E7%95%8C/

三、微信加載方案

首次加載在地球中頁中, 並用線程去加載（可是 5.0 以前加載 dex 時仍是會掛起主線程一段時間（不是全程都掛起））。

dex 形式

微信是將包放在 assets 目錄下的，在加載 Dex 的代碼時，實際上傳進去的是 zip，在加載前須要驗證 MD5，確保所加載的 Dex 沒有被篡改。

dex 類分包規則

分包規則即將全部 Application、ContentProvider 以及全部 export 的 Activity、Service 、Receiver 的間接依賴集都必須放在主 dex。

加載 dex 的方式

加載邏輯這邊主要判斷是否已經 dexopt，若已經 dexopt，即放在 attachBaseContext 加載，反之放於地球中用線程加載。怎麼判斷？由於在微信中，若判斷 revision 改變，即將 dex 以及 dexopt 目錄清空。只需簡單判斷兩個目錄 dex 名稱、數量是否與配置文件的一致。

總的來講，這種方案用戶體驗較好，缺點在於太過複雜，每次都需從新掃描依賴集，並且使用的是比較大的間接依賴集。

http://yydcdut.com/2016/03/20/split-dex/