时间戳

首页 > 解决方案 > 超过 64k 方法非 Multidex 调试解决方案

java - 超过 64k 方法非 Multidex 调试解决方案

问题描述

我遇到了标题中提到的问题，即我的应用程序达到了 64k 方法引用限制。搜索SO后，我意识到DEX文件的限制。我的问题仅与调试模式有关。在发布时，我只有一小部分方法，所以没有问题。

我希望能够在无需打开multidex的情况下调试我的应用程序。我看到人们建议multidex仅在调试时启用。不过，我已经读过multidex在 API21 之前的设备上调试时启用会出现问题。所以，我试图避免它。

我正在测试以下内容：

    buildTypes {
        debug {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        release {
            debuggable false
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

我的想法是在发布时使用最小化调试。从长远来看，此修复程序会导致我出现任何问题吗？另外，是否可以使用不同的规则进行调试？

谢谢。

标签： javaandroid

解决方案

My idea is to use minimification on debug as I do release.

是的，只需缩小您的应用程序。这将大大减少库方法的数量。这就是包括我在内的许多公司减少我们的 App Bundle 的大小和方法数量的原因。只需将 minifyEnabled 设置为 true，就像您在指定的 gradle 文件上设置的那样。

Do you use minifyEnabled true for debug, too, to bypass the 64k on debug builds?

当您将 minifyEnabled 设置为 true 时，您并没有绕过 64k，而是从构建中消除了所有不使用的方法。如果您正在对发布的调试版本进行一些最终测试，我只会将其设置为 true。这是因为如果在调试版本中始终将 minifyEnabled 值设置为 true，您的构建时间将会非常长

Will this fix cause me any issues in the long run?

不，如果您提供正确的 Proguard 规则，您的应用程序应该完全没问题。Proguard 可能会让人望而生畏，但随着 Android Studio 的新版本以及网上无数的 Proguard 文章，你应该会没事的。在应用 Proguard 时您绝对应该考虑的一些常见情况是：

  • 应用规则来保护基于反射的代码
  • 应用规则来保护您的 Kotlin 枚举器
  • 查看您的每个库并确保您访问他们的 github API 页面并确保您正在应用任何库特定规则。一些流行的示例库包括 Glide 和 Koin

Also, is it possible to use different rules for debug?

我假设您的意思是您是否可以应用不同的 Proguard 规则进行调试。是的，您可以看到您可以指定要从中提取规则的 proguard 规则文件，只需创建一个包含要应用于调试模式的规则的新文件

推荐阅读