Android应用方法数65536的限制问题

作为一名Android开发者，相信你对Android方法数不能超过65K的限制应该有所耳闻，随着应用程序功能不断的丰富，总有一天你会遇到一个异常：

Conversion to Dalvik format failed:Unable toexecute dex: method ID not in [0, 0xffff]: 65536

那么让我们看一下为什么会引起这种错误:

        在Android系统中，一个App的所有代码都在一个Dex文件里面。Dex是一个类似Jar的存储了多有Java编译字节码的归档文件。因为Android系统使用Dalvik虚拟机，所以需要把使用Java Compiler编译之后的class文件转换成Dalvik能够执行的class文件。这里需要强调的是，Dex和Jar一样是一个归档文件，里面仍然是Java代码对应的字节码文件。当Android系统启动一个应用的时候，有一步是对Dex进行优化，这个过程有一个专门的工具来处理，叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件，即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。但是在早期的Android系统中，DexOpt有一个问题，也就是这篇文章想要说明并解决的问题。DexOpt会把每一个类的方法id检索起来，存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的，导致了方法id的数目不能够超过65536个。当一个项目足够大的时候，显然这个方法数的上限是不够的。尽管在新版本的Android系统中，DexOpt修复了这个问题，但是我们仍然需要对低版本的Android系统做兼容.

下面我来向大家介绍两种主流的解决方案，一种是以微信为代表的，将一些功能做成插件，动态加载，另一种方案是以facebook为代表的分包方案，将一个apk中的dex文件分割成多个dex文件，然后动态的去加载dex文件。其实这两种方案的核心思想是一样的，插件是把未来要开发的新功能做成apk和dex动态加载，而分包方案是将已经完成的功能分成多个dex文件动态加载，其实我个人觉得插件方案比分包方案更好的解决了65k的问题，因为插件方案不仅能够解决65k问题，还能让我们的应用体积减小，而分包只能解决65k的问题。

对于分包方案有两种方法：一种是基于gradle构建Android项目，一种是基于Ant构建Android项目。具体这里不再介绍，网上有很多相关资料，这里仅作记录。

参考链接：

1. http://blog.csdn.net/t12x3456/article/details/40837287

2. http://www.tuicool.com/articles/bEFNJj