android - 如何使用Proguard缩小Android代码

Question

由于我在应用程序中使用了许多依赖关系，因此我达到了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'
}

Answer 1

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's Leak Canary Proguard配置。它没有说明有关开发人员的整体能力，只是提醒您使用Proguard可能很困难。是的，这种配置将完全防止库的缩小和混淆，除非您从源代码构建它的本地副本并从其中删除此类有用的 consumer-proguard-rules.pro。

评估Proguard的依赖关系

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


如果图书馆站点上的任何地方都有“框架”，“企业”，“反射”一词，则可能与Proguard的兼容性较差；
如果该库与编译时代码生成（a-la Buttknife，Dagger等）有关，请在使用Proguard之前三思。
如果该库与JNI混乱，则在使用Proguard之前，请再三思，Google会对Proguard产生影响，即使您不缩减该库本身也是如此；
如有疑问，Google会为此和/或阅读库源代码： Class.forName以及 Proxy.getInvocationHandler的用法以及类似的反射代码通常是不好的标志。


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

最重要的部分

许多开发人员（包括Proguard开发人员本身！）都会向您提供错误的建议，即从空的Proguard配置+默认的Android Proguard配置开始，并最终在必要时添加 -keep规则。

不要那样做！！

这些建议来自人们，他们要么太bad，无法理解普通开发人员的问题（请阅读：“ Proguard开发人员本人”），要么对正确使用Proguard毫无头绪。实际上，这些错误的做法正是原因，为什么对此问题的许多答案会警告您不要使用Proguard：这是默认行为，就像建议某人从扩展Everest开始登山。

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行的开头。