1

由于我在我的应用程序中使用了许多依赖项，因此我达到了 65k 方法限制（我达到了 76k 方法）。我在 android.developer 上读过 proguard 用于缩小代码。

那么 - proguard 是只缩小我的应用程序代码还是缩小我的依赖项的代码？使用 proguard 压缩代码时，我是否需要警惕某些事情？我怎么做？

我的 Gradle 构建：

apply plugin: 'com.android.application'

android {
compileSdkVersion 21
buildToolsVersion "21.1.2"

defaultConfig {
    applicationId "some.Path"
    minSdkVersion 15
    targetSdkVersion 21
    versionCode 1
    versionName "1.0"
}

packagingOptions {
    exclude 'META-INF/DEPENDENCIES'
    exclude 'META-INF/NOTICE'
    exclude 'META-INF/NOTICE.txt'
    exclude 'META-INF/LICENSE'
    exclude 'META-INF/LICENSE.txt'
}

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

configurations {
compile.exclude group:  'org.apache.xmlbeans'
}

repositories {
maven { url "https://jitpack.io" }
}

dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:appcompat-v7:21.0.3'
compile 'com.github.PhilJay:MPAndroidChart:v2.1.0'
compile 'com.opencsv:opencsv:3.4'
compile 'org.apache.poi:poi:3.12'
compile 'org.apache.poi:poi-ooxml:3.12'
}
4

6 回答 6

14

TL; DR：-keep除非您喜欢麻烦，否则请反转您的选择

首先：我相信，通过使用 Proguard 来克服 dex 限制，您做出了正确的选择。我不建议在任何情况下使用 multidex 支持库：它会在您的应用程序中引入多个类加载器的问题，并且可能会以许多不明显的方式适得其反。

这是我个人有效缩小应用程序的方法：

  • 选择您拥有的几个最大的第三方依赖项；
  • 检查那些是否真的支持 Proguard；
  • 如果有，用 Proguard 缩小它们；
  • 如果您仍然不适合最大方法数，请对剩余的一些依赖项执行上述步骤；
  • 如果您仍然不适合，可能会重新评估一些不支持 Proguard 的，可能阅读他们的源代码以更好地了解他们为什么不适合，然后自己将 Proguard 应用于他们；
  • 在最坏的情况下，将 Proguard 应用于您自己的代码；
  • 如果以上都没有帮助，请使用 multidex。

选择依赖项进行收缩

在您的情况下，首先没有很多（直接）依赖项。您可能希望查看输出gradlew dependencies以更好地了解您的间接依赖关系，其中一些可能是总应用程序大小的最大贡献者。然后，您可以继续使用Android Arsenal的“Dex”部分中列出的一些工具来了解哪些库对 dex 方法计数的贡献最大。您似乎已经对此有了一个大致的了解，所以我不会过多地讨论这部分。

请记住：缩小可执行代码对库内部的干预有点不重要，因此您宁愿减少更少以避免将来出现神秘问题。如果有疑问，请从公开声明它们确实支持 Proguard 的库开始（在您的情况下，这将是 Android 支持库）。

请注意，“支持 Proguard”对于不同的开发人员可能意味着不同的事情。您可以期望 Android 支持库开发人员至少基本能胜任，但许多其他人将附带这样的消费者 Proguard 规则：

-keep class com.example.library.** { *; }

如果您想知道，上述配置基于许多现实生活中的配置，例如Square 的 Leak Canary Proguard 配置。它没有说明相关开发人员的整体能力，只是提醒您使用 Proguard 可能很困难。是的，这种配置将完全防止库的收缩和混淆，除非您从源代码构建它的本地副本并从那里删除这些有用 consumer-proguard-rules.pro的东西。

评估 Proguard 的依赖关系

如上所示，即使是经验丰富的开发人员有时也会选择忽略 Proguard。如果 Google 搜索有关该库并且它与 Proguard 的兼容性没有返回任何内容（即使它们确实返回了一些结果！）您可能必须对 Proguard 的使用做出自己的判断。以下是我个人的做法：

  • 如果图书馆网站的任何地方都有“框架”、“企业”、“反射”等字眼，很可能与Proguard的兼容性很差；
  • 如果该库与编译时代码生成有关（a-la Butterknife、Dagger 等），请在使用 Proguard 之前三思而后行；
  • 如果库与 JNI 混淆，请在使用 Proguard 之前再考虑几次，即使您不缩小库本身，Google 也会对 Proguard 产生影响；
  • 如果有疑问，Google for it 和/或阅读库源代码：使用Class.forName以及Proxy.getInvocationHandler类似的反射代码通常是不好的迹象。

提供 Android UI 组件（例如 MPAndroidChart）的库通常可以缩小，至少如果您保留getDefaultProguardFile('proguard-android.txt')Gradle 配置。

最重要的部分

很多开发者（包括 Proguard 开发者自己！）会给你一个误导的建议，从空的 Proguard 配置 + 默认的 Android Proguard 配置开始，最终-keep在必要时添加规则。

不要那样做！！

这些建议来自人们，他们要么太坏而无法理解普通开发人员的问题（阅读：“Proguard 开发人员本人”），要么不知道如何正确使用 Proguard。事实上，这种误导性的做法正是为什么这个问题的许多答案都警告您不要使用 Proguard 的原因：它的默认行为就像建议某人从攀登珠穆朗玛峰开始登山。

默认的 Proguard 配置将混淆、缩小和优化所有内容——您的整个应用程序具有所有依赖项，但您明确排除的某些类除外。您不希望这样，除非您对项目中的每个库和代码行有绝对的了解：它们如何工作和相互交互，它们在内部使用哪些技术等。

相反，您希望在最小的可能范围（很少有最大的库）内进行最少的必要干预（缩小代码以减少 dex 方法计数），而后果最小（仅在已知 Proguard 可以肯定工作的情况下）。这是我针对这种情况的 Proguard 配置：

-dontoptimize
-dontobfuscate

# Prints some helpful hints, always add this option
-verbose

-keepattributes SourceFile,LineNumberTable,Exceptions,InnerClasses,Signature,Deprecated,*Annotation*,EnclosingMethod


# add all known-to-be-safely-shrinkable classes to the beginning of line below
-keep class !com.android.support.**,!com.google.android.**,** { *; }

将上述规则添加到您的应用程序中proguard-rules.pro，它们只会收缩您明确允许收缩的类。将其他可安全收缩的包的通配符（与上面一样，带有!和.**部分）附加到-keep行首。

于 2015-07-20T04:34:52.950 回答
1

作为 ProGuard 的替代方案，您可以通过关闭 ProGuard来使用内置的 Gradle 收缩器，但仍引用 ProGuard 配置。这将删除未使用的代码，但不会混淆或执行任何其他“魔术”。尽管仅推荐用于 Debug 构建，但如果您认为不需要混淆，我不明白为什么不能将其用于 Release 构建。

与 ProGuard 相比（我认为）的主要好处是避免了 ProGuard 配置与代码库结构和第三方依赖项之间的紧密耦合。

构建.gradle：

minifyEnabled true
useProguard false
proguardFiles ('proguard-basic.pro', getDefaultProguardFile('proguard-android.txt'))

proguard-basic.pro：

-dontwarn javax.**
-keep class com.mycompany.** { *; }
于 2017-10-20T08:01:34.873 回答
0

如果您通过 ProGuard 启用缩小，它也会缩小您的依赖关系。

库通常尚未使用 ProGuard 进行混淆/缩小。某些库如果被混淆，默认情况下将无法正常工作，因此您应该检查您使用的任何库，看看它们是否有任何关于 ProGuard 的文档。例如，Butterknife 有一些特殊的 ProGuard 规则，您需要包含这些规则以确保它继续正常工作。

于 2015-07-20T00:42:39.137 回答
0

根据版本 3.2 中的新 Android Studio 更新，新代码收缩器也通过将以下行添加到项目的gradle.properties文件中来进行混淆

添加这一行：

android.enableR8 = true
于 2018-10-06T07:42:13.823 回答
0

对我来说，你应该寻找 multidex，超过 65k 的限制，而不是 proguard，因为从长远来看，后者不能解决你的问题。

请参阅文档：https ://developer.android.com/tools/building/multidex.html

于 2015-07-20T01:13:44.747 回答
0

如果您在 build.grade 文件中启用缩小，那么是的，它也会缩小您的依赖项。

请记住，Proguard 可能会引入不需要的副作用。并非所有库/依赖项都可以缩小，因为 Proguard 也会混淆代码。（即将字符串名称转换为字符串 n）并删除未使用的代码。

看看这个 Github 项目：https ://github.com/krschultz/android-proguard-snippets

作为替代方案，您可以考虑使用 MultiDex。你可以在这里阅读：https ://developer.android.com/tools/building/multidex.html

于 2015-07-20T01:17:34.393 回答