AAR 依赖项 - 捆绑与否？答案

【问题标题】：AAR dependencies - bundle or not?AAR 依赖项 - 捆绑与否？
【发布时间】：2019-07-23 07:14:52
【问题描述】：

我正在开发自己的 SDK，而这又依赖于一些 3rd 方 SDKS。例如 - OkHttp。

我应该将 OkHttp 添加到我的build.gradle，还是让我的 SDK 的用户包含它？在这种情况下，他们可能“无论如何”都会使用它，因此可以肯定地说他们已经拥有它。

另外一点要补充 - 并非我的 SDK 的所有路径都需要“OkHttp”，因此，理论上，我的 SDK 的某些用户只能使用这些部分，而他的 APK 上没有 OkHttp。

我正在考虑的另一件事：如果我确实通过build.gradle 嵌入了 OkHttp - 我的 SDK 的用户如何使用该 OkHttp 库，而不是使用另一个副本？

【问题讨论】：

我建立了一个图书馆，我遇到了同样的问题。就我个人而言，我认为让消费项目添加库会更好，因为您可以更好地控制消费项目的 gradle 中的内容。在主项目导入库的不利方面，Android SDK 可能存在问题，因为您的库可能包含对旧版本 X 库的引用（例如方法），并且它可能与其他库不兼容，消费项目已经有
不，您最好不要将一个通用库打包到您的可交付库中，因为打包在您的库中的那个会导致不必要的包重复错误。正如你所说的，对于一些客户来说，他们并不真正需要那个库。他们可能会抱怨库/apk 大小的影响（尽管他们可以通过应用代码收缩来减轻大小，但并非所有客户都知道这一点）。
如果你真的想把常用的库打包到你的库中，那么你最好将包/类扁平化到不同的包中（使用ProGuard工具可以做到这一点）避免包重复错误。例如。 ``` -flattenpackagehierarchy com.new.package.name ```
还有一点是库版本问题，考虑一下你打包低版本的通用库，但客户需要高版本的库。那么你会给你的客户带来一些不必要的麻烦。

【解决方案1】：

我应该将 OkHttp 添加到我的 build.gradle 中，还是让我的 SDK 的用户包含它？

在build.gradle 中添加依赖并不意味着将依赖打包到 aar 文件中。 aar 文件不包含传递依赖项，并且没有描述库使用的依赖项的 pom 文件。

将工件上传到 maven 存储库，您将拥有您的 aar 和一个包含依赖项列表的 pom 文件。
这样 gradle 会自动下载所有的依赖树，你可以将 gradle 配置为排除相同的库。

【讨论】：

【解决方案2】：

使用implementation 并将其打包 - 消费者仍然可以exclude 它。

一个人不能依赖某些东西，然后不打包它；这不会建立。

在应用程序包中，它可以/必须只存在一次......那有什么意义呢？

【讨论】：

【解决方案3】：

我会以相反的顺序回答你的问题

我正在考虑的另一件事：如果我通过 build.gradle 嵌入 OkHttp - 我的 SDK 的用户如何使用该 OkHttp 库，而不是使用另一个副本？

Gradle 构建系统的工作原理是假设，在我的项目中，我使用您的库，并且我使用的是 OkHttp 的 v2，而您的库使用的是 OkHttp 的 V1，那么 gradle 将自动使用最新版本。你可以阅读它here

另外一点要补充 - 并非我的 SDK 的所有路径都需要“OkHttp”，因此，理论上，我的 SDK 的某些用户只能使用这些部分，而他的 APK 上没有 OkHttp。

在我的项目中，我使用了您的库并且它使用了 OkHttp，而我也没有在我的项目中使用它，我没有使用您使用 OkHttp 的库的一部分，但我的 APK 仍然会包含 OKHttp它。这可以通过将您的库拆分为两个单独的库或我在我的项目中使用 proguard 来避免。

我应该将 OkHttp 添加到我的 build.gradle 中，还是让我的 SDK 的用户包含它？在这种情况下，他们可能“无论如何”都会使用它，因此可以肯定地说他们已经拥有它。

您不应该将它捆绑在您的库中，您只需使用 implementation 并让您的库的用户决定是否要排除它。

【讨论】：

【解决方案4】：

你需要了解 gradle 中的 api 和实现 link 会很有帮助

API：作用：声明、API、依赖

消耗品？没有

可以解决吗？没有

描述：在这里你应该声明依赖项，这些依赖项会传递给消费者，以供编译。

实现：作用：声明、实现、依赖

消耗品？没有

可以解决吗？没有

描述：您应该在此处声明纯粹内部的依赖项，而不是向消费者公开。

【讨论】：