Android為什麼要設計成要改設置才能讓自己的程序超過65536個函數？

01-13

android - Unable to execute dex: method ID not in [0, 0xffff]: 65536

65K Methods 問題的 root cause 在於 Dalvik bytecode 的限制

並不是 @張鵬所提到的 dexopt（dexopt 是在安裝 apk 時調用的，而不是在打包 apk）

除了 Method之外 Field 和 Class 同樣也存在 65K 問題

http://source.android.com/devices/tech/dalvik/dex-format.html

美團就遇到了 65K Field 問題：http://tech.meituan.com/mt-android-auto-split-dex.html

65536 個 method 看起來很多，然而開發者為了使兼容舊版本的 Android 不可避免的需要使用各種 Android Support Library，單看用 Design support library 需要引入的 method 數量：

在加上需要引入各種第三方 SDK，所以留給自己的 method 一般也就在 2w 左右

Google 官方提供的 Mutlidex 和國內各種插件化方案在 Android 5.0 以下都是通過 ClassLoader 載入第二個或多個 dex 文件。

這個坑給應用開發者帶來了兩難的局面：

Google 官方的 Mutlidex library 14年發布至今基本沒有更新過，介紹頁面上滿滿的都是 known issue（aka. bug）http://developer.android.com/intl/zh-cn/tools/building/multidex.html 唯一的優點是在 Android 5.0 以後的系統可以在安裝時自動將多個 dex 文件預編譯成一個 oat 文件，算是徹底終結了這個坑
國內的各種插件化方案，在Android 5.0 以前的版本一般有不錯的效果，但 5.0 之後卻沒法享受預編譯帶來的性能提升

簡言之：

這好像是第二次回答輪子哥 @vczh 提的問題了 o??((??? ?????? ??)???)?o?

Update：

之前的理解有偏差，已改正

Ref：由Android 65K方法數限制引發的思考

文中統計 method 數量用的是 Methods Count

一開始看錯問題了，修改一下。

編譯後安卓的方法都存放在dex文件里，dex會被DexOpt這個程序odex化。dexopt會把dex里的每個方法的id保存到一個鏈表中，而這個鏈表的長度卻是用short類型保存的。這樣的話，方法的ID就最多只能有66535個了，項目大了就可能會不夠用。

解決辦法詳見http://developer.android.com/intl/zh-cn/tools/building/multidex.html

VS2013裡面的C++不是也要改設置才能讓tuple支持超過5個模板參數嗎？

這個問題在我印象中只存在於你想兼容Android 2.3及更低版本的時候（我查證之後再來修改）。原因也簡單，某個版本之前的dexOpt在索引方法的時候用了兩位元組整數來索引，所以過了65535就爆了。

谷歌官方給出的解決方案是把類打包到多個dex（相當於jar的東西）裡面，然後通過特定的ClassLoader來保證幾個dex協調運轉，官方還出了個multi-dex庫來做這個事情。

因為一開始設計時沒想到會做這麼大0 0，然而為了兼容不好直接改限制

65535有倆道坎，一個是打包的時候dex階段，另一個是dexopt。第一道坎是為了防止你邁不過去第二道坎。原因大家都知道是short，但是app程序員一般控制不了dexopt，所以大家用黑科技(multidex,插件化)繞過的是第一道坎

大概。。。

因為一開始的時候。。。

沒有想過會超過65536。。。

吧。