Android 突破 DEX 文件的 64K 方法数限制

2016-10-26

随着安卓平台的不断发展与壮大，市场上大而全的应用比比皆是，产品需求的变更累积和UI交互的极致追求，除了 resources 文件的俱增，在 Android Project 中依赖的 Library 和自己写的 Java 代码也会越来越多。这些变化，除了会导致打包出的 APK 文件越来越大之外，当项目中java代码包含的方法数（method count）超出一个峰值时，编译过程中就会出现如下错误：

较早版本的编译系统中，错误内容如下：

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

而在新版编译系统中，是这样：

1
2
3

trouble writing output:
Too many field references: 131000; max is 65536.
You may try using --multi-dex option.

尽管在不同版本的编译系统中显示的错误内容不尽相同，但内容中都提到了一个具体的数字：65536，这个数字也是本文要讲到的核心内容：Android 64K Method Counts Limit 的峰值。详细信息，参考官网用户指南：Configure Apps with Over 64K Methods。

Android 64K Method Counts Limit

Android Project 经过编译打包，其中的Java代码（包括Library）转化为DEX格式的字节码文件，这是Android 5.0之前的 Dalvik 虚拟机决定的（5.0之后改为 ART 虚拟机），并且采用 short 类型引用 DEX 文件中的 method，这也为method数量的峰值大小埋下了隐患。short 类型能够表示的最大值是 65536，也就说单个 DEX 文件中最多只有 65536 个 method 能够得到引用，如果代码执行了超出部分的 method 引用，自然会报错，如 methodNotFound 等。1K 等于 1024，65536 刚好是 64K，为了便于称呼和使用，就将这个限制规则统称为 64K 方法数的引用限制。

拓展文章：由Android 65K方法数限制引发的思考

为了解决 64K 方法数限制的问题，我们可以在项目中使用 multidex 配置，当项目中的方法数（包括：Android framework，library 和我们自己写的代码）超过 64K 时，编译系统会自动编译出多个 DEX 文件。

Multidex Support

Android 5.0 之前，安卓系统采用的是 Dalvik 虚拟机，采用的是JIT技术（Just-in-time compilation，即时编译，运行时编译DEX字节码文件，这也是以前为什么安卓手机用户总是诟病Android系统比iOS系统运行卡顿的原因），限制每个APK文件只能包含一个 DEX 文件（即 classes.dex）。为了绕开这个限制，Google给我们提供了multidex support library 兼容包，帮助我们实现应用程序加载多个DEX文件，并且这个兼容包作为程序的主DEX文件，管理者其他DEX文件的访问。

注意：由于 Instant Run 机制利用的就是 multidex 原理，当项目中minSdkVersion参数设置为20或者更小，并且运行在 Android 4.4 (API 20) 或更低版本的设备中时，Instant Run将失效。

Android 5.0之后，安卓系统改用了ART虚拟机（Android RunTime），采用的是OAT技术（Ahead-of-time，预编译，在应用安装的时候扫描应用中的所有DEX文件，并编译成一个.oat格式的文件供安卓设备执行，所以相比Dalvik虚拟机下的应用，安装时间较长）。因此可以理解为，使用ART虚拟机下的安卓系统自动支持APK文件中多个DEX的加载。

注意：使用Instant Run时，如果项目中的minSdkVersion参数设为21或更高版本，Android Studio编译运行时会自动使应用支持multidex。但Instant Run仅仅作用于debug版本，我们依然需要给release版本配置multidex来避开64K方法数的限制。

Config for Multidex With Gradle

Android Gradle 插件在 Android SDK Build Tools 21.1 及更高版本的编译工具上支持multidex作为编译配置的一部分，所以确保我们的Android SDK Build Tools tools已经更新至21.1或更高版本，然后再来配置应用的multidex部分。

第一步，修改app/build.grale文件，使项目能够使用multidex：

android {
    compileSdkVersion 21
    buildToolsVersion "21.1.0"
    defaultConfig {
        ...
        // Enabling multidex support.
        multiDexEnabled true
    }
    ...
}
dependencies {
  compile 'com.android.support:multidex:1.0.0'
}

第二步，修改AndroidManifest.xml文件，引用MultiDexApplication类：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.yifeng.mdstudysamples">
    <application
        ...
        android:name="android.support.multidex.MultiDexApplication">
        ...
    </application>
</manifest>

有时候，你可能还需要改变一下 javaMaxHeapSize 的大小：

android {
    dexOptions {
        javaMaxHeapSize "4g"
    }
}

添加这些配置后，编译工具会构建出一个主 DEX 文件（classes.dex）和其他附属 DEX 文件（classes2.dex，classes3.dex 等，如果需要的话），编译系统会将他们打包到 Apk 文件中。

注意：一般我们会在项目中自定义一个继承自Application的类，此时就需要重写attachBaseContext()方法，并在该方法里面调用MultiDex.install(this)来支持multidex，可参考：MultiDexApplication

Optimizing Multidex Development Builds

multidex 配置下的应用，编译系统需要经过复杂的 DEX 分割运算，导致增加项目的编译时间，从而影响开发人员的开发效率。我们可以使用 productFlavors 构建开发环境和正式环境的不同 flavors 来优化 multidex 的长时间编译问题。

对于development flavor，设置 minSdkVersion 值为21，运行在Android 5.0以上版本的设备中，使用 ART-supported 格式生成 multidex 的速度要快得多。对于 release flavor，minSdkVersion 值则设为应用实际支持的版本，编译系统耗费较长的时间来生成适配多设备的multidex APK文件。如：

android {
    productFlavors {
        // Define separate dev and prod product flavors.
        dev {
            // dev utilizes minSDKVersion = 21 to allow the Android gradle plugin
            // to pre-dex each module and produce an APK that can be tested on
            // Android Lollipop without time consuming dex merging processes.
            minSdkVersion 21
        }
        prod {
            // The actual minSdkVersion for the application.
            minSdkVersion 14
        }
    }
          ...
    buildTypes {
        release {
            runProguard true
            proguardFiles getDefaultProguardFile('proguard-android.txt'),
                                                 'proguard-rules.pro'
        }
    }
}
dependencies {
  compile 'com.android.support:multidex:1.0.0'
}

这样，在开发阶段，使用 devDebug 类型的变种 app，取消混淆，支持 multidex，并且运行在 5.0 及以上版本的设备中，能够加快编译过程。有关 flavors 的信息，以前写过一篇文章：Android 利用Gradle实现app的环境分离，更多信息可以参考英文手册：Gradle Plugin User Guide，对应中文版译文：Gradle Android插件用户指南翻译。

strings count limit

前面我们说完单一 dex 文件的方法数限制，事实上，还有一个字符串数量限制。如果项目没有使用 multidex 支持的话，当 strings 超出一定限制，编译过程也会出错：

1 2	Dex: Error converting bytecode to dex: Cause: com.android.dex.DexIndexOverflowException: Cannot merge new index 65868 into a non-jumbo instruction!

不同项目编译过程中报错信息里的具体数字可能不同。Dex 文件中出现的 string 默认是 4 个字节即 16 位大小的 int 类型的数字引用使用的，即单个 Dex 文件最多只能引用 2^16 个 strings，当你的项目中出现超过这个最大数字的字符串引用，而又没有使用 multidex 支持，编译过程便会出错。

对于这种情况，除了使用 multidex，还有另外一种解决方案：jumboMode。这个模式允许单个 Dex 文件支持到 32 为大小的 strings 引用，即 2^32 的引用峰值。使用方法是，在工程 app 模块下 build.gradle 文件的 android 配置下添加：