41

当我注意到我可以使用两个不同的依赖项时，我正要在我的项目中使用约束布局：

  • com.android.support.constraint:constraint-layout
  • androidx.constraintlayout:constraintlayout

这两者之间是否有区别或一些建议更可取？

编辑

Google 将停止支持com.android.support并提示用户迁移到新的androidx等效版本。

注意：随着 Android 9.0（API 级别 28）的发布，有一个名为 AndroidX 的支持库的新版本，它是 Jetpack 的一部分。AndroidX 库包含现有的支持库，还包含最新的 Jetpack 组件。

您可以继续使用支持库。历史工件（那些版本为 27 及更早版本，并打包为 android.support.*）仍将在 Google Maven 上可用。但是，所有新库的开发都将在 AndroidX 库中进行。

我们建议在所有新项目中使用 AndroidX 库。您还应该考虑将现有项目迁移到 AndroidX。

这是官方迁移指南和相应的库等价物。

4

4 回答 4

33

所有支持库都删除了 v4 v7 v12 v13 等标签，所有内容都被重构到 androidx 包中。

它们本质上是相同的，但为了将来参考，androidx 将是我们应该在我们的应用程序中使用的库。

本周（2018 年 5 月 14 日这一周）发布的 Android Studio 3.2 Canary 应该具有允许自动重构 androidx 包的工具。在 google i/o 2018 上有一个关于此的公告。

于 2018-05-14T20:27:46.357 回答
17

AndroidX 和 Support 库的区别之一是，当你使用支持库时，所有支持库必须是相同的版本，但在 androidX 中没有这样的东西。

另一件事是，在支持库中，大多数情况下，当您在应用程序中需要一个组件时，您必须添加具有许多其他您真正不需要的东西的依赖项。但在 AndroidX 中，您只能添加您需要的依赖项，而不再添加。

于 2019-02-16T11:01:38.207 回答
6

这可能会有所帮助，

有以下几点不同：

  1. 使用当前的命名约定，不清楚哪些软件包与 Android 操作系统捆绑在一起，哪些与您的应用程序的 APK（Android 软件包工具包）打包在一起。为了消除这种混乱，所有未捆绑的库都将移至 AndroidX 的 androidx.* 命名空间，而 android.* 包层次结构将保留给 Android 操作系统附带的包。例如：android.content.Intent;是否依赖于 Android 操作系统androidx.fragment.app.Fragment;且随 APK 一起提供

  2. 最初，每个包的名称表示该包支持的最低 API 级别，例如 support-v4。但是，支持库的 26.0.0 版本将最低 API 增加到 14，因此今天许多包名称与最低支持的 API 级别无关。当 support-v4 和 support-v7 包都具有 14 的最低 API 时，很容易看出人们为什么会感到困惑！。所以现在有了 AndroidX，就不再依赖 API 级别了。

  3. 这只是对第二点的扩展，另一个重要的变化是 AndroidX 工件将独立更新，因此您将能够更新项目中的各个 AndroidX 库，而不必一次更改每个依赖项。那些令人沮丧的“<strong>所有 com.android.support 库必须使用完全相同的版本规范”消息应该成为过去！
于 2019-07-30T07:45:51.347 回答
1

如上所述，在迁移到 AndroidX中，您可以轻松地在 AS 中迁移：

使用 Android Studio 3.2 及更高版本，您可以通过从菜单栏中选择Refactor > Migrate to AndroidX快速迁移现有项目以使用 AndroidX 。

关于差异（TLDR：无损伤，强调我的）

AndroidX 将原始支持库 API 包映射到 androidx 命名空间。只有包和 Maven 工件名称发生了变化； 类、方法和字段名称没有改变。

于 2019-07-03T12:10:05.770 回答