【文章摘要】既然手Q的方法数已经大大超过了「65536」的上限，如果不做处理的话，肯定在一些手机上无法安装了。与手Q类似的「重量级」应用都会面临相同的问题。那，该怎么办呢？

用过Excel的同学应该都知道，在Office2003上，一个sheet的最大行数是65536行，如果你要处理的数据总量超过了这个范围，只能将数据拆分到多张sheet中。好在微软在Office 2007中解决了这个问题。

当然，今天要讲的「65536」并不是Excel中的「65536」，而是早期的Android系统给应用开发者留下来的一个坑，一个天坑！欲知此坑多深，且听我慢慢道来。

在一个Apk文件中，程序猿起早贪黑码出来的代码会被放在一个名为Class.dex的文件中。

Android系统为了优化应用程序在不同机型上的运行效率，Apk在安装过程中会对Class.dex文件做特定的优化，生成一个优化后的odex文件。应用程序启动时会加载odex文件执行。然而，在早期的Android系统中，一个odex文件只能存储65536个java方法（不知道「方法」为何？请点这里），如果Class.dex中的总方法数超过这个上限，会因为无法生成对应的odex文件而在一些机器上将无法安装！Office2003上的悲剧竟然在这里重演！

有的同学可能会说，上限是6W多，不会那么容易超过的。然而事实恰恰相反，我们来看看手Q总共有多少方法数：

知道程序猿们每天都在干什么了吧？他们一天到晚在生产「方法」。

既然手Q的方法数已经大大超过了「65536」的上限，如果不做处理的话，肯定在一些手机上无法安装了。与手Q类似的「重量级」应用都会面临相同的问题。那，该怎么办呢？

天下的道理总是相通的。当在Office2003上遇到65536的行数上限问题后，我们会很自然的想到建立多个sheet处理海量数据。同理，针对Android平台的「65536」问题，把一些方法从Class.dex中剥离出来放到另一个dex文件中好像是个靠谱的做法。不要把所有鸡蛋放在一个篮子里，因为篮子已经装不下了！

在Android L发布时，谷歌针对这个问题提出了一个「解决方案」，那就是Multi-Dex。利用这种方式生成的Apk文件，其中除了Class.dex外，还会有Class1.dex、Class2.dex、...等若干dex，并保证每个dex文件中的方法数都小于「65536」。

说到这里，也许你会觉得问题被圆满解决了，然而，当你真正使用这个方案规避「65536」问题时，会发现谷歌刚把你从这个坑里拉出来，又把你推进了另一个坑里。

正如前文所说，Apk在安装的过程中会对Class.dex文件做优化，生成对应的odex文件，而使用了Multi-Dex方案的Apk程序在安装过程中也完全遵守了这一过程：安装时只对Class.dex文件做优化，Class1.dex、Class2.dex、...等若干dex只有在程序首次启动时才会进行优化！这种策略直接带来的问题就是漫长的安装耗时被转移到了应用的首次启动，甚至导致用户首次使用应用时出现「应用程序无响应」的提示！

Android初期的系统工程师可能完全没有预计到，在Android平台上，应用复杂度的增长会如此之快，竟然将Class.dex文件的方法数上限限制在了「65536」的范围内，如今提供的Multi-Dex方案也无法让Android开发者从无尽的「精简方法数」斗争中解脱出来，作为一个Android程序猿，我只想说「天长地久有时尽，此恨绵绵无绝期」！