65535代碼的含義html
隨着應用不斷迭代和業務線的擴展,應用愈來愈大(好比集成了各類第三方sdk或者公共支持的jar包,項目耦合性高,重複做用的類愈來愈多),應用中的Dex 文件方法數超過了最大值65536的上限,簡單來講,應用爆棚了。java
65535錯誤出現緣由android
在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有一個問題,DexOpt會把每個類的方法id檢索起來,存在一個鏈表結構裏面。可是這個鏈表的長度是用一個short類型來保存的,致使了方法id的數目不可以超過65536個。當一個項目足夠大的時候,顯然這個方法數的上限是不夠的。儘管在新版本的Android系統中,DexOpt修復了這個問題,可是咱們仍然須要對低版本的Android系統作兼容。ide
經常使用的解決方法工具
雖然Google解決了應用總方法數限制的問題,但並不意味着開發者能夠任意擴大項目規模。Multidex仍有一些限制:測試
避免應用過大、方法過多仍然是Android開發者要注意的問題。Mihai Parparita的開源項目dex-method-counts能夠用於統計APK中每一個包的方法數量。優化
一般開發者本身的代碼很難達到這樣的方法數量限制,但隨着第三方類庫的加入,方法數就會迅速膨脹。所以選擇合適的類庫對Android開發者來講尤其重要。spa
開發者應該避免使用Google Guava這樣的類庫,它包含了13000多個方法。儘可能使用專爲移動應用設計的Lite/Android版本類庫,或者使用小類庫替換大類庫,例如用Google-gson替換Jackson JSON。而對於Google Protocol Buffers這樣的數據交換格式,其標準實現會自動生成大量的方法。採用Square Wire的實現則能夠很好地解決此問題。.net
相關資料
1.MutiDex文檔 https://developer.android.com/reference/android/support/multidex/MultiDex.html
2. http://blog.osom.info/2014/10/multi-dex-to-rescue-from-infamous-65536.html
3.附android -support-mutidex.jar下載地址: http://download.csdn.net/detail/t12x3456/8143383