Android 应用打破 65K 方法数限制

近日， Android Developers 在 Google+ 上宣布了新的Multidex 支持库，为方法总数超过65K 的Android 应用提供了官方支持。

如果你是一名幸运的 Android 应用开发者，正在开发一个前景广阔的应用，不断地加入新功能、添加新的类库，那么终有一天，你会不幸遇到这个错误：

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

这个错误是 Android 应用的方法总数限制造成的。Android 平台的 Java 虚拟机 Dalvik 在执行 DEX 格式的 Java 应用程序时，使用原生类型 short 来索引 DEX 文件中的方法。这意味着单个 DEX 文件可被引用的方法总数被限制为 65536。通常 APK 包含一个 classes.dex 文件，因此 Android 应用的方法总数不能超过这个数量，这包括 Android 框架、类库和你自己开发的代码。

这个问题可以通过将一个 DEX 文件分拆成多个 DEX 文件解决。Facebook 介绍了为 Android 应用开发的 Dalvik 补丁；Android Developers 博客介绍了通过自定义类加载过程的方法来解决此问题。但这些方法有些复杂而且并不优雅。

随着新的MultiDex 支持库发布，Google 正式为解决此问题提供官方支持。构建超过65K 方法数的应用介绍了如何使用Gradle 构建多DEX 应用。

首先使用 Android SDK Manager 升级到最新的 Android SDK Build Tools 和 Android Support Library R21。然后进行以下两步操作：

1. 修改 Gradle 配置文件，启用 MultiDex 并包含 MultiDex 支持：

android { compileSdkVersion 21 buildToolsVersion "21.1.0"

defaultConfig {
    ...
    minSdkVersion 14
    targetSdkVersion 21
    ...

    // Enabling multidex support.
    multiDexEnabled true
}
...
}

dependencies { compile 'com.android.support:multidex:1.0.0' } 

2. 让应用支持多 DEX 文件。在 MultiDexApplication JavaDoc 中描述了三种可选方法：

• 在 AndroidManifest.xml 的 application 中声明 android.support.multidex.MultiDexApplication；
• 如果你已经有自己的 Application 类，让其继承 MultiDexApplication；
• 如果你的 Application 类已经继承自其它类，你不想 / 能修改它，那么可以重写 attachBaseContext() 方法：

@Override 
protected void attachBaseContext(Context base) {
    super.attachBaseContext(base); MultiDex.install(this);
}

经过以上步骤，你的应用已经可以实现多个 DEX 文件了。当应用构建时，构建工具会分析哪些类必须放在第一个 DEX 文件，哪些类可以放在附加的 DEX 文件中。当它创建了第一个 DEX 文件（classes.dex）后，如果有必要会继续创建附加的 DEX 文件，如 classes2.dex, classes3.dex。Multidex 的支持类库将被包含在应用的第一个 DEX 文件中，帮助实现对其它 DEX 文件的访问。

文中还介绍了在开发多 DEX 应用时，通过设置 productFlavors 提高开发效率以及多 DEX 应用的测试方法。

Android 5.0 和更高版本使用名为 ART 的运行时，它原生支持从 APK 文件加载多个 DEX 文件。在应用安装时，它会执行预编译，扫描 classes(..N).dex 文件然后将其编译成单个.oat 文件用于执行。了解更多关于ART 的信息。

虽然 Google 解决了应用总方法数限制的问题，但并不意味着开发者可以任意扩大项目规模。Multidex 仍有一些限制：

1. DEX 文件安装到设备的过程非常复杂，如果第二个 DEX 文件太大，可能导致应用无响应。此时应该使用 ProGuard 减小 DEX 文件的大小。
2. 由于 Dalvik linearAlloc 的 Bug ，应用可能无法在 Android 4.0 之前的版本启动，如果你的应用要支持这些版本就要多执行测试。
3. 同样因为 Dalvik linearAlloc 的限制，如果请求大量内存可能导致崩溃。Dalvik linearAlloc 是一个固定大小的缓冲区。在应用的安装过程中，系统会运行一个名为 dexopt 的程序为该应用在当前机型中运行做准备。dexopt 使用 LinearAlloc 来存储应用的方法信息。Android 2.2 和 2.3 的缓冲区只有 5MB，Android 4.x 提高到了 8MB 或 16MB。当方法数量过多导致超出缓冲区大小时，会造成 dexopt 崩溃。
4. Multidex 构建工具还不支持指定哪些类必须包含在首个 DEX 文件中，因此可能会导致某些类库（例如某个类库需要从原生代码访问 Java 代码）无法使用。

避免应用过大、方法过多仍然是 Android 开发者要注意的问题。Mihai Parparita 的开源项目 dex-method-counts 可以用于统计 APK 中每个包的方法数量。

通常开发者自己的代码很难达到这样的方法数量限制，但随着第三方类库的加入，方法数就会迅速膨胀。因此选择合适的类库对 Android 开发者来说尤为重要。

开发者应该避免使用 Google Guava 这样的类库，它包含了 13000 多个方法。尽量使用专为移动应用设计的 Lite/Android 版本类库，或者使用小类库替换大类库，例如用 Google-gson 替换 Jackson JSON。而对于 Google Protocol Buffers 这样的数据交换格式，其标准实现会自动生成大量的方法。采用 Square Wire 的实现则可以很好地解决此问题。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。