方法數超了65535 無法安裝的解決方案

錯誤：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超限