我有一个 java 库项目，其中包含对 guava 库的依赖项。 Guava 有近 11k 个方法，我预计大多数用户将来自 Android 社区。在Android上有一个限制计数方法，它是65k...
但是我的库的方法总数大约是 11.400，所以我的库的代码不到 200 行。
我能够使用 proguard 下载并缩小 Guava jar ，将计数方法数量减少到 1k。但现在该项目需要包含对此收缩 jar 的引用，而不是对托管 Guava 的远程存储库的引用。 But any jar added to the project would be discard当它作为工件发布在任何远程存储库时，由 maven 执行，因此 guava 依赖关系无法解决，应用程序客户端最终会崩溃。
Guava 本身advices to not use proguard如果你的“应用程序”实际上是一个库，并让你的库的用户处理这种情况，使用他们自己的 proguard 来缩小 guava 的大小。但我不喜欢这个想法，因为我想提供一个简单的配置解决方案。
据我所知，proguard 提供的输出是某种可执行文件(jar、apk 等)，因此，如果我缩小自己的库，最终输出将是一个 jar，而这个 jar 又是，无法作为工件发布，因为它将被丢弃(我尝试了几次)。
有没有办法在我自己的 java 库项目中使用 proguard 并将结果输出传递到构建链，以便作为远程存储库而不是 jar 发布？
我正在使用 gradle 来构建我的项目，但此时我准备转向 Maven 来解决问题。
谢谢。
最佳答案
执行以下操作之一:
- 使用您的 guava 压缩版本作为单独的 Maven 工件，发布它，并让您的库像依赖任何其他依赖项一样依赖它
- 不要缩小库并使用 multidex 构建 - 这是 解决65K方法限制的方法 http://developer.android.com/tools/building/multidex.html
无论如何，为了便于配置，您不应该在库上使用 progruard，原因很简单:用户无论如何都必须向其项目添加依赖项。如果在某些情况下用户将开始遇到 ClassNotFound 异常，因为您截断了一些您不希望使用的代码，该怎么办？
如果有人正在为 Android 编程，他迟早会接触到 ProGuard，而且我认为越早越好。
因此，为了便于配置，我宁愿在文档中建议，如果用户希望避免 65k 限制，因为您的库已经超过了它，他可以在提供的示例配置中使用 proguard。
关于java - 将 proguard 应用于 Java 库项目，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34820161/