Java 64k以上方法非多索引调试解决方案

我遇到了标题中提到的问题，我的应用程序达到了64k方法引用限制。经过搜索，我意识到了

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'
        }
    }

我的想法是在调试时使用最小化，就像在发布时一样。从长远来看，此修复会给我带来任何问题吗？另外，是否可以使用不同的规则进行调试

---

谢谢。

我的想法是在调试时使用最小化，就像在发布时一样。

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

您是否也使用minifyEnabled true进行调试，以绕过调试版本上的64k？

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

从长远来看，此修复会给我带来任何问题吗？

不，如果您提供了正确的Proguard规则，您的应用程序应该完全正常。Proguard可能会让人望而生畏，但随着Android Studio的新发布，以及网上数不清的Proguard文章，你应该会没事的。在应用Proguard时，您应该明确了解的一些常见情况有：

• 应用规则以保护基于反射的代码
• 应用规则以保护Kotlin枚举数
• 查看每个库，确保转到它们的github API页面，并确保应用了任何特定于库的规则。一些流行的示例库包括Glide和Koin

另外，是否可以使用不同的规则进行调试？

---

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

很抱歉，但我想确保我正确理解了这一点。您是否也使用

minifyEnabled true

进行调试，以绕过调试版本上的64k？另外，我想了解proguard规则行。我知道proguard规则。pro是文件名，但我不理解“proguard android.txt”部分。如果我要为调试创建单独的规则，我的行应该像

proguardFiles getDefaultProguardFile（'proguard-android.txt'），'proguard debug rules.pro'

（例如）保持“proguard android.txt”不变？谢谢。是的，正如您指定的，您只需创建一个新的proguard-debug-rules.pro文件。然而，我这样做的方式只是在调试和发布版本中来回移动时，在Proguard规则中注释掉/推荐回来（例如打开/关闭模糊处理）。我编辑了这篇文章以回答您评论中的第一个问题谢谢您提供的信息。关于调试

minifyEnabled true

选项。我有点困惑。您说过您只在最后阶段调试测试中使用它。你每天都做些什么？我的意思是，如果您达到64k限制，您将无法在设备上调试应用程序，除非您通过正常方式或使用

minifyEnabled true

或使用

multidex

选项减少方法。您可能没有执行日常调试，或者我遗漏了什么？这对我来说无关紧要，因为我正在构建的应用程序的最小sdk高于21，默认情况下启用了multidex。缩小（ing）您的开发版本使您的构建时间越来越长，因为您的应用程序变得越来越复杂/模块化，因为您的模块有多个缩小进程在运行。但是，加快构建时间超出了这个问题的范围，并且有许多在线资源，例如“我已经了解到，启用multidex在API21之前的设备上调试时会出现问题”-什么问题？这很好，谢谢你的回复。我是从另一个问题上读到的。他们还提到，

multidex

降低了API21之前的设备的速度。请问您的产品是否使用multidex？当然可以

minifyEnabled

意味着每次构建都要等待几分钟。对发展来说似乎很糟糕。谢谢你的信息。你让我想了想。现在，我正在考虑使用multidex进行调试。使用multidex进行调试是否比使用

minifyEnabled true

更快？