APP编译报最大方法数超65k解决方案总结

shiskyer

于 2017-04-20 16:56:41 发布

阅读量732

点赞数

文章标签： android android开发分包拆包解决方案

本文链接：https://blog.youkuaiyun.com/shiskyer/article/details/70271785

版权

本文总结了Android应用因方法数超过65536导致的编译问题及其解决方案。主要原因是DexOpt优化限制和Dalvik bytecode的内存限制。谷歌通过提供multidex支持库解决了这一问题，允许将应用代码拆分为多个dex文件。在配置方面，需更新Build Tools版本，启用multiDexEnabled，并在build.gradle中添加multidex依赖。在运行时，可能遇到找不到类的问题，需通过maindexlist.txt指定主dex包含的类。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、出现条件

新开发的应用一般不用担心，一般长期的应用功能增加，当你去掉一些未使用的import和library 使用ProGuard去掉一些未使用的代码之后，仍然避免不了应用方法数量超过65536时，编译时回报这个提示：

二、产生的原因

首先，这是谷歌的锅。

1、DexOpt优化的限制：当Android 系统安装一个应用的时候，有一步是对Dex进行优化，这个过程有一个叫“DexOpt”的工具来处理。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件，即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。但是在早期的Android系统中，DexOpt会把每一个类的方法id检索起来，存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的，导致了方法id的数目不能够超过65536个（方法包括：引用的Android Framework方法 library的方法我们自己书写代码的方法）。当一个项目足够大的时候，显然这个方法数的上限是不够的。尽管在新版本的Android系统中，DexOpt修复了这个问题，但是我们仍然需要对低版本的Android系统做兼容。

2、dalvik bytecode的限制：