前言
起因：项目使用的一直是multidex:1.0.3版本就想着版本低了要不要升级一下。惊喜就这么来了。
65536
当你的应用及其引用的库超过 65,536 个方法时，你会遇到构建错误，表明你的应用已达到 Android 构建 架构 的限制：
trouble writing output: Too many field references: 131000; max is 65536. You may try using --multi-dex option.
旧版本的构建系统报告了不同的错误，这表明存在相同的问题：
Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536
这两种错误情况都显示一个共同的数字：65536。这个数字表示单个 Dalvik 可执行文件 (DEX) 字节码文件中的代码可以调用的引用总数。本问介绍了如何通过启用称为multidex的应用程序配置来克服此限制，该配置允许你的应用程序构建和读取多个 DEX 文件。
关于 64K 参考限制
Android 应用 APK 文件包含 Dalvik 可执行文件 DEX 文件形式的可执行字节码文件，其中包含用于运行应用的编译代码。Dalvik Executable 规范将单个 DEX 文件中可以引用的方法总数限制为 65,536，包括 Android 框架方法、库方法和你自己代码中的方法。在计算机科学的上下文中，术语Kilo, K表示 1024（或 2^10）。由于 65,536 等于 64 X 1024，因此此限制称为64K 参考限制。
解决64K限制
对 Android 5.0 及更高版本的 Multidex 支持
Android 5.0（API 级别 21）及更高版本使用称为 ART 的运行时，该运行时本机支持从 APK 文件加载多个 DEX 文件。 ART 在应用安装时执行预编译，它会扫描 classesN.dex 文件并将它们编译成单个 .oat 文件以供 Android 设备执行。 因此，如果你的 minSdkVersion 为 21 或更高，则默认启用 multidex，并且你不需要 multidex 库。
注意： 当使用 Android Studio 运行你的应用程序时，构建会针对你部署到的目标设备进行优化。 这包括在目标设备运行 Android 5.0 及更高版本时启用 multidex。 由于此优化仅在使用 Android Studio 部署应用程序时应用，因此你可能仍需要为 multidex 配置发布版本以避免 64K 限制。
看到没，这里最好的解决办法就是设置minSdkVersion设置为 21 或更高。这样网上的一些什么
- multidex你遇到的坑
- multidex与你不得不说的秘密
- multidex原理及实现就和你没得关系了，当然你想了解也可以。
Android SDK 为 21 或更高的问题解决了，那Android SDK 低于 21 的呢。咱接着往下看喽。
Android 5.0 之前的 Multidex 支持
为你的应用程序配置 multidex
如果你的 minSdkVersion 设置为 21 或更高，则默认启用 multidex，你不需要 multidex 库。
但是，如果你的 minSdkVersion 设置为 20 或更低，那么你必须使用 multidex 库并对你的应用项目进行以下修改：
1.修改模块级 build.gradle 文件以启用 multidex 并添加 multidex 库作为依赖项，如下所示：
- 使用AndroidX
android { defaultConfig { ... minSdkVersion 15 targetSdkVersion 30 multiDexEnabled true } ... } dependencies { implementation "androidx.multidex:multidex:2.0.1" }
- 不使用AndroidX(已弃用)
android { defaultConfig { ... minSdkVersion 15 targetSdkVersion 30 multiDexEnabled true } ... } dependencies { implementation 'com.android.support:multidex:1.0.3' }
2.根据你是否覆盖 Application 类，执行以下操作之一：
- 如果你不覆盖 Application 类，请编辑你的清单文件以在 < application > 标记中设置 android:name，如下所示：
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.scc.demo"> <application android:name="androidx.multidex.MultiDexApplication" > ... </application> </manifest>
如果你确实覆盖了 Application 类，请将其更改为扩展 MultiDexApplication(非必须)，如下所示：
public class MyApplication extends MultiDexApplication { ... }
- 或者，如果你确实覆盖了 Application 类但无法更改基类，那么你可以覆盖 attachBaseContext() 方法和 callMultiDex.install(this) 以启用 multidex：
public class MyApp extends Application { @Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this); } }
注意： 在 MultiDex.install() 完成之前，不要通过反射或 JNI 执行 MultiDex.install() 或任何其他代码。 Multidex 跟踪不会跟随这些调用，导致 ClassNotFoundException 或由于 DEX 文件之间的类分区错误而导致验证错误。
现在，当你构建应用程序时，Android 构建工具会根据需要构建一个主要的 DEX 文件 (classes.dex) 和支持的 DEX 文件（classes2.dex、classes3.dex 等）。构建系统然后将所有 DEX 文件打包到你的 APK 中。
在运行时，multidex API 使用特殊的类加载器来搜索所有可用的 DEX 文件以查找你的方法（而不是仅在主 classes.dex 文件中搜索）。
multidex 库的限制
multidex 库有一些已知的限制，当你将其合并到应用程序构建配置中时，你应该注意并测试这些限制：
- 在启动期间将 DEX 文件安装到设备的数据分区上很复杂，如果辅助 DEX 文件很大，可能会导致应用程序无响应 (ANR) 错误。为避免此问题，请启用代码收缩以最小化 DEX 文件的大小并删除未使用的代码部分。
- 在 Android 5.0（API 级别 21）之前的版本上运行时，使用 multidex 不足以解决 linearalloc 限制（问题 78035）。此限制在 Android 4.0（API 级别 14）中有所增加，但这并没有完全解决。在低于 Android 4.0 的版本上，你可能会在达到 DEX 索引限制之前达到线性分配限制。因此，如果你的目标 API 级别低于 14，请在平台的这些版本上进行彻底测试*，因为你的应用程序可能在启动时或加载特定类组时出现问题。
代码缩减可以减少或可能消除这些问题。
在主 DEX 文件中声明所需的类
如果你收到 java.lang.NoClassDefFoundError，那么你必须通过在构建类型中使用 multiDexKeepFile 或 multiDexKeepProguard 属性声明它们，根据主 DEX 文件中的要求手动指定这些附加类。 如果某个类在 multiDexKeepFile 或 multiDexKeepProguard 文件中匹配，则该类将添加到主 DEX 文件中。
multiDexKeepFile 属性
你在multiDexKeepFile其中指定的文件应每行包含一个类，格式为com/example/MyClass.class. 例如，你可以创建一个如下所示的文件multidex-config.txt：
com/scc/MyClass.class com/scc/MyOtherClass.class
然后，你可以为构建类型声明该文件，如下所示：
android { buildTypes { release { multiDexKeepFile file('multidex-config.txt') ... } } }
注意： Gradle 读取相对于build.gradle文件的路径，因此如果multidex-config.txt与build.gradle文件位于同一目录中，则上述示例有效。
multiDexKeepProguard 属性
该multiDexKeepProguard文件使用与 Proguard 相同的格式，并支持整个 Proguard 语法。
你在multiDexKeepProguard其中指定的文件应包含 -keep 任何有效 ProGuard 语法中的选项。例如， -keep com.scc.MyClass.class。你可以创建一个名为的文件 multidex-config.pro，如下所示：
-keep class com.scc.MyClass -keep class com.scc.MyClassToo
如果要指定包中的所有类，文件如下所示：
-keep class com.scc.** { *; } // com.scc 包中的所有类
然后，你可以为构建类型声明该文件，如下所示：
android { buildTypes { release { multiDexKeepProguard file('multidex-config.pro') ... } } }
在开发版本中优化 multidex
为了减少更长的增量构建时间，使用 pre-dexing在构建之间重用 multidex 输出。Pre-dexing 依赖于仅在 Android 5.0（API 级别 21）及更高版本上可用的 ART 格式。如果你使用的是 Android Studio 2.3 及更高版本，则在将你的应用程序部署到运行 Android 5.0（API 级别 21）或更高版本的设备时，IDE 会自动使用此功能。
注意： 适用于 Gradle 3.0.0及更高版本的Android 插件包括进一步改进以优化构建速度，例如按类进行 dexing（以便仅对你修改的类进行重新索引）。一般来说，为了获得最佳的开发体验，你应该始终升级到 最新版本的 Android Studio和 Android 插件。
但是，如果你从命令行运行 Gradle 构建，则需要将 minSdkVersion 设置为 21 或更高以启用 pre-dexing。保留生产版本设置的一个有用策略是使用产品风格创建两个版本的应用程序 ：开发风格和发布风格，具有不同的值minSdkVersion，如下所示。
android { defaultConfig { ... multiDexEnabled true //最低 API 级别。 minSdkVersion 15 } productFlavors { dev { //(API 级别 21)或更高 . minSdkVersion 21 } prod { // 如果你已经为生产版本配置了 defaultConfig 块 // 你的应用程序，你可以将此块留空，Gradle 会使用其中的配置 // 代替 defaultConfig 块。 你仍然需要包括这种味道。 // 否则，所有变体都使用“dev”配置。 } } buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } } dependencies { implementation "androidx.multidex:multidex:2.0.1" }
避免 64K 限制
在配置应用以启用 64K 或更多方法引用之前，你应该采取措施减少应用代码调用的引用总数，包括应用代码定义的方法或包含的库。以下策略可以帮助你避免达到 DEX 参考限制：
- 检查你的应用程序的直接和传递依赖项 - 确保你在应用程序中包含的任何大型库依赖项的使用方式都超过添加到应用程序的代码量。一个常见的反模式是包含一个非常大的库，因为一些实用方法是有用的。减少你的应用程序代码依赖性通常可以帮助你避免 DEX 引用限制。
- 使用 R8 删除未使用的代码 -启用代码收缩以运行 R8 以用于你的发布版本。启用收缩可确保你不会随 APK 一起发送未使用的代码。
使用这些技术可能会帮助你避免在应用中启用 multidex，同时还可以减少 APK 的整体大小。
以上就是本文的全部内容，希望对大家学习Android multidex有所帮助和启发。
