錯誤：Conversion to Dalvik format failed:Unable toexecute dex: method ID not in [0, 0xffff]: 65536
作爲一名Android開發者，相信你對Android方法數不能超過65K的限制應該有所耳聞，隨着應用程序功能不斷的豐富，總有一天你會遇到一個異常
解決這個問題很簡單，我們只需要在Project.proterty中配置一句話就Ok啦，dex.force.jumbo=true 。
是的，加入了這句話，確實可以讓你的應用通過編譯，但是在一些2.3系統的機器上很容易出現 INSTALL_FAILED_DEXOPT異常
至於適配2.3的系統誰還去做這種事。。。。
錯誤原因：（有些傻逼面試官會問的）
1、Android系統中，一個Dex文件中存儲方法id用的是short類型數據，所以導致你的dex中方法不能超過65k
2、在2.3系統之前，虛擬機內存只分配了5M
這還涉及兩種編程方式的學習：
一種 是以微信爲代表的，將一些功能做成插件，動態加載，
另一種 方案是以facebook爲代表的分包方案，將一個apk中的dex文件分割成多個dex文件，然後動態的去加載dex文件。
其實這兩種方案的核心思想是一樣的，插件是把未來要開發的新功能做成apk和dex動態加載，而分包方案是將已經完成的功能分成多個dex文件動態加載，其實我個人覺得插件方案比分包方案更好的解決了65k的問題，因爲插件方案不僅能夠解決65k問題，還能讓我們的應用體積減小，而分包只能解決65k的問題。
插件發有個人寫的可以學習一下：http://blog.csdn.net/yuanzeyao/article/details/38565345 .
分包發極其複雜：Android分包MultiDex原理詳解
2.3版本之前dalvik虛擬機的內存只有5M,所以無論是插件方案還是分包方案在某些手機上還是會遇到該問題。
畢竟我們僅僅是減少了每個dex中包的數量，但是方法總數是沒有減少的，所以解決此問題的根本方法就是修改虛擬機內存至8M,這個需求在Java層是無法實現，但是可以在c層實現，具體實現流程可以參考開源項目：
https://github.com/viilaismonster/LinearAllocFix.git
開源項目的使用方法： Hack Dalvik VM解決Android 2.3 DEX/LinearAllocHdr超限