Dexopt失败的一个非常大的APK（乱序method_idx）时dex.force.jumbo =真 [英] Dexopt failed on a very big APK (Out-of-order method_idx) when dex.force.jumbo=true
问题描述
我有一个多，大，第三方jar文件（如Android的库）一个非常大的Android项目。
我相信我已经打了地塞米松的最大的方法限制数量（通过Eclipse编译）：
I have a very big Android project with a multiple, big, 3rd party jars (as Android Libraries).
I believe I've hit a Dex's max number of method limitation (compiling via eclipse):
[二零一二年十一月十八日2点28分45秒 - 在文件中查找]霉素处理classes.dex ...
[2012年11月18日2时28分48秒 - 地塞米松装载机]无法执行DEX：不能合并新的索引66774到非巨型指令
[2012年11月18日2时28分48秒 - 在文件中查找]转换为的Dalvik格式失败：无法执行DEX：不能合并新的索引66774到非巨型指导！
[2012-11-18 02:28:45 - Find In Files] Dx processing classes.dex...
[2012-11-18 02:28:48 - Dex Loader] Unable to execute dex: Cannot merge new index 66774 into a non-jumbo instruction!
[2012-11-18 02:28:48 - Find In Files] Conversion to Dalvik format failed: Unable to execute dex: Cannot merge new index 66774 into a non-jumbo instruction!
拍摄的SDK工具21（平台工具16）的优势，因此，我编辑我的主要项目project.properties设置 dex.force.jumbo = TRUE 。
让我的标志生成APK。但我无法正确安装（物理和仿真器一样）。似乎有一个DEX优化失败：
Taking advantage of SDK tools 21 (platform tools 16), I therefore, edited my main project project.properties to set dex.force.jumbo=true.
The flag allowed to me generate the APK. But I couldn't install it properly (on physical and emulator alike). There seems to be a dex optimizer failure:
11-18 20：11：05.338：I / PackageManager（103）：运行dexopt上：com.mypackage.myapp <BR>
11-18 20：11：08.577：E / dalvikvm（868）：乱序method_idx：0x2ae0然后为0x1
11-18 20：11：08.577：E / dalvikvm（868）：问题与项目1544 @偏移0xf7ae24
11-18 20：11：08.577：E / dalvikvm（868）：2006年款型交换失败
11-18 20：11：08.577：E / dalvikvm（868）：错误：字节交换+验证失败
11-18 20：11：08.597：E / dalvikvm（868）：优化失败
11-18 20：11：08.597：W / INSTALLD（39）：DexInv：--- END/data/app/com.mypackage.myapp-1.apk'---状态=为0xFF00，进程失败
11-18 20：11：08.597：E / INSTALLD（39）：dexopt失败的/data/dalvik-cache/data@app@com.mypackage.myapp-1.apk@classes.dexRES = 65280
11-18 20：11：08.697：W / PackageManager（103）：包无法安装在/data/app/com.mypackage.myapp-1.apk
11-18 20：11：09.018：D / dalvikvm（103）：GC_EXPLICIT释放1698K，免费13％17034K / 19463K，暂停7毫秒+ 135ms
11-18 20：11：09.068：D / AndroidRuntime（780）：关闭虚拟机
11-18 20:11:05.338: I/PackageManager(103): Running dexopt on: com.mypackage.myapp
11-18 20:11:08.577: E/dalvikvm(868): Out-of-order method_idx: 0x2ae0 then 0x1
11-18 20:11:08.577: E/dalvikvm(868): Trouble with item 1544 @ offset 0xf7ae24
11-18 20:11:08.577: E/dalvikvm(868): Swap of section type 2006 failed
11-18 20:11:08.577: E/dalvikvm(868): ERROR: Byte swap + verify failed
11-18 20:11:08.597: E/dalvikvm(868): Optimization failed
11-18 20:11:08.597: W/installd(39): DexInv: --- END '/data/app/com.mypackage.myapp-1.apk' --- status=0xff00, process failed
11-18 20:11:08.597: E/installd(39): dexopt failed on '/data/dalvik-cache/data@app@com.mypackage.myapp-1.apk@classes.dex' res = 65280
11-18 20:11:08.697: W/PackageManager(103): Package couldn't be installed in /data/app/com.mypackage.myapp-1.apk
11-18 20:11:09.018: D/dalvikvm(103): GC_EXPLICIT freed 1698K, 13% free 17034K/19463K, paused 7ms+135ms
11-18 20:11:09.068: D/AndroidRuntime(780): Shutting down VM
我是想用 dex.force.jumbo 标记的目的它不适合，或者是这个错误未predictable？
如果是这样，有没有更好的策略来生成包括班一个非常大的一些项目/方法？
Am I trying to use the dex.force.jumbo flag for a purpose it was not intended for, or is this error unpredictable?
If so, is there a better strategy to generate a project that includes a very big number of classes/methods?
推荐答案
64k的方法限制是地塞米松格式的限制（它使用2个字节来查找的方法）。
Nandeesh评论的指出，巨型解决字符串而已，而不是方法。
The 64K methods limit is a Dex format limitation (it uses 2 bytes to lookup a method).
Nandeesh comment's points out that jumbo solves string only, not methods.
替代我试过/考虑（括号自己，他们都吸）：
1. 自己动手 - 扔掉最胖的第三方库，并写了自己的功能的确切部位。这是我最后走，因为我意识到我在内的很多code一个小功能的方法。
2. <一href="http://android-developers.blogspot.co.il/2011/07/custom-class-loading-in-dalvik.html">Custom类加载在Dalvik的 - 编译一个单独的地塞米松，并加载它在运行时。缺点：笨重，需要反思
。
3. code修剪 - 打开详细的类加载，运行应用程序，并尝试删除第三方库，或者说并没有真正使用的库的部分。缺点：耗时，容易出错的类被动态加载
。
4. 分割并同意 - 在一个单独的进程（服务）套餐的第三方库。这项服务将提供第三方库的功能。执行从主程序这项服务电话。
Alternatives I tried/considered (brace yourselves, they all suck):
1. Do It Yourself - Throw away the fattest 3rd party libraries and write the exact parts of its functionality yourself. This is the approach I ended up taking, as I realized I'm including a lot of code for a small functionality.
2. Custom class loading in Dalvik - Compile a separate Dex and load it on runtime. Cons: cumbersome, requires reflection.
3. Code Pruning - Turn on verbose class loading, run the app and try to remove 3rd party libraries, or parts of the library that are not really used. Cons: time consuming, error prone as classes are dynamically loaded.
4. Divide And Concur - Package 3rd party libraries in a separate process (a service). This service will provide the 3rd party libraries functionality. Perform calls on this service from your main program.
我相信这是一个情况下的 640K应该足够任何人或没办法才会有这种每2电话在Dalvik的早期的一部分，这个星球的设计团队。
I believe that it's a case of 640k ought to be enough for anybody OR No way will have this on every 2nd phone in the planet on the part of Dalvik's early design team.
如果您想了解更多或者干脆哭出来负荷谷歌，我已经创造了这个缺陷：<一href="http://$c$c.google.com/p/android/issues/detail?id=40409">http://$c$c.google.com/p/android/issues/detail?id=40409
If you want to read more or simply cry out load to Google, I've created this defect: http://code.google.com/p/android/issues/detail?id=40409
这篇关于Dexopt失败的一个非常大的APK（乱序method_idx）时dex.force.jumbo =真的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
