Android應用方法數65536的限制問題

随着應用程式功能不斷的豐富，總有一天你會遇到一個異常：

Conversion to Dalvik format failed:Unable toexecute dex: method ID not in [0, 0xffff]: 65536

那麼讓我們看一下為什麼會引起這種錯誤:

        在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系統做相容.

下面我來向大家介紹兩種主流的解決方案，一種是以微信為代表的，将一些功能做成插件，動态加載，另一種方案是以facebook為代表的分包方案，将一個apk中的dex檔案分割成多個dex檔案，然後動态的去加載dex檔案。其實這兩種方案的核心思想是一樣的，插件是把未來要開發的新功能做成apk和dex動态加載，而分包方案是将已經完成的功能分成多個dex檔案動态加載，其實我個人覺得插件方案比分包方案更好的解決了65k的問題，因為插件方案不僅能夠解決65k問題，還能讓我們的應用體積減小，而分包隻能解決65k的問題。

對于分包方案有兩種方法：一種是基于gradle建構Android項目，一種是基于Ant建構Android項目。具體這裡不再介紹，網上有很多相關資料，這裡僅作記錄。

參考連結：

1. http://blog.csdn.net/t12x3456/article/details/40837287

2. http://www.tuicool.com/articles/bEFNJj