谷歌已经将他们的 support 库更名为 Jetpack（又名 AndroidX）。开发人员需要对此进行更改。
本文将解释这意味着什么，以及如何开始转换您的项目以使用新组件。
Jetpack走向未来
什么是 Jetpack?
Android Jetpack 是一组库，工具和架构指南，旨在使构建 Android 应用程序变得容易。它旨在提供通用的基础结构代码，以便开发人员可以专注于编写使应用程序独有的内容。
这是一项大范围的工作，旨在改善开发人员的体验并将有用的工具和框架收集到一个有凝聚力的单元中。
来自 Alan Viverette (Android Framework team) 的这句话是一个很好的总结：
“Jetpack 是一项旨在改善开发人员体验的更大范围的工作，但 AndroidX 构成了技术基础。 从技术角度来看，它仍然是您在 Support Library 和 Architecture Components 下看到的相同库。“
为什么？
为什么 Google 要经历所有这些麻烦（并为开发人员创造所有这些麻烦）？
- 为支持库创建一致的命名空间（androidx.*）
- 更好地支持工件的语义版本控制（从 1.0.0 开始）。这使它们能够独立更新。
- 创建一个共同的伞，以在其之下开发所有的支持组件。
值得一提的是 - 当前版本的AppCompat(v28.x) 是最终版本。 此代码的下一个版本将仅使用 Jetpack。 开发人员必须意识到这一点，并尽早进行切换。
Alan Viverette 的这句话很好地总结了这一点：
“不会有 29.0.0，所以 Android Q APIs 将只会在 AndroidX 中”
Jetpack 里有什么?
答案是：一切。
Jetpack 是我们长期使用的许多现有库（如 AppCompat、Permissions、Notifications 或 Transitions）和近年来引入的较新的 Architecture Components（如 LiveData、Room、WorkManager 或 ViewModel）的集合。
开发者可以期望他们从 AppCompat 得到的同样的便利之处，包括向后兼容性和不依赖于制造商 OS 更新的发布周期。
Jetpack Components
你现在需要升级吗？ 你可以只更新部分代码吗？
您今天不必更新，但在不久的将来您必须更新。
AppCompat (v28.x) 的当前版本与AndroidX (v1.x) 完全相同。 事实上，AppCompat 库是通过更改 AndroidX 代码库的 maven 坐标和包名来生成的。
例如，旧坐标和包是：
implementation “com.android.support:appcompat-v7:28.0.0"
import android.support.v4.widget.DrawerLayout现在是：
implementation 'androidx.appcompat:appcompat:1.0.2'
import androidx.drawerlayout.widget.DrawerLayout重要的是要注意，您不能在同一个项目中混合使用 AppCompat 和 Jetpack。 如果要升级，必须将所有内容转换为使用 Jetpack。
第一步 - 将您的应用升级到最新的Support 库
当您准备好更新到 Jetpack 时，请确保您的应用程序已升级到 Gradle 和 AppCompat 的最新版本。这将确保重构只是更改包名，而不是与库更新相关的更大问题。
更新项目非常重要，并且会暴露您进一步操作时遇到的一些问题，例如对旧版本库的延迟依赖。 如果您无法更新到最新版本，则需要先解决这些问题，然后再继续。
不要忘记查看 https://maven.google.com 获取最新的 Gradle 依赖信息。
使用 Refactor 工具更新项目
升级项目后，您将使用 Android Studio (AS) 实用程序来执行重构。
从菜单运行它：Refactor\Refactor to AndroidX:
Android Studio AndroidX refactor 工具
此工具将扫描您的应用，并显示所需更改的预览：
如果您对更改感到满意，请选择 “Do Refactor” 按钮，转换工具将执行以下 3 项操作：
- 更新 imports 以映射新的包名：
只有包名更改，其他一切都完全相同
- 更新依赖项的 Gradle 坐标
注意：我手动将 “compile” 替换为 “implementation”，该工具没有做到这一点
- 在 gradle.properties 文件中添加 2 个标志。 第一个标志告诉Android插件使用 AndroidX 包而不是 AppCompat，第二个标志将启用 Jetifier，这是一个帮助使用外部库的工具（有关详细信息，请参阅下一节）：
android.useAndroidX=true
android.enableJetifier=true一般来说，变化应该仅被隔离到这 3 个区域，但根据我的经验，我看到重构工具也做了其他更改。 在我的例子中，该工具添加了代码来考虑 Kotlin Nullability（它在我的源代码中添加了一些 !!），但可能会有其他更改。 密切监控工具所做的所有更改，并确保您对它们感到满意是一个非常好的主意。
Jetifier
AS 重构工具仅对项目中的源代码进行更改。 它不会对库或外部依赖项进行任何更改。
为此，Google 创建了一个名为 Jetifier 的工具，旨在构建时自动转换可传递的依赖项以使用 Androidx 库。 如果我们没有这个工具，我们需要等待每个第三方 lib 更新，然后才能使用它（并推迟我们的更新，直到准备就绪）。
除了使用 gradle 标志启用此工具之外，没有太多关于使用它的知识，因为这是一个自动化过程，不需要任何配置。
谷歌最近宣布了一个独立的选项，用于运行 Jetifier。您甚至可以运行一个 “反向模式”，它将 “消除Jetify” 代码（这对于调试非常有用）。
你可能遇到的问题
您可能会发现需要更新的第三方库。例如，有人发现当前版本的 SqlDelight 需要房间持久性库的旧版本。他们请求更新，Square 已经提供了 lib 的更新版本。如果你发现了一个问题，你越快向开发人员请求更新，效果越好。最新版本的 Room (v2.1) 已经需要 AndroidX，这可能会造成许多人升级。截至本文撰写之时， Facebook SDK 还没有更新，这可能会对很多人造成阻碍。
将项目更新到最新版本的 AppCompat 可能并非易事。 您可能在代码中遇到以前的 bug 或遇到需要大量重新工作的升级。提前计划以考虑这项工作。
Jetifier 不会修改源文件，因此在使用文档时可能会造成混淆。
你不能通过 Module 来区分Jetify，所以这是你的代码库上的 “全有或全无” 操作。 这可能需要阻止正在进行的开发直到问题解决 - 否则你可能会遇到巨大的合并噩梦。
映射工具也许会在代码中插入 alpha 依赖项（例如，添加了 ConstraintLayout alpha）。
Android Studio 可能不了解 Jetifier 并显示错误（红色波浪形）。执行 Invalidate Cache and Restart 应该可以解决此问题。
Jetifier 不会修改生成的代码，这可能需要额外的返工。
一些替换名称未正确映射（这些似乎主要来自 design 库）。重构工具不适用于这些情况，您的代码将无法编译。 要解决这些问题，您需要手动解决导入问题。希望随着工具的成熟和重构工具中的错误得到修复，这些问题会随着时间的推移而最小化。
有用的提示：
Jetpack 的标准命名约定是将包名复制到 Maven 坐标。 在 Jetpack 中，包将始终与 groupid 匹配。
例如，如果您知道包名称是 `androidx.webkit`，那么依赖项将映射到：`androidx.webkit:webkit:VERSION`。
总结
提前计划迁移到 Jetpack 所需的更改，这将需要进一步操作。 升级中最困难的部分可能是将项目更新为最新的依赖项。
可能有第三方库尚未更新。很重要的一点是要尽早识别这些内容，并要求开发人员对其进行更新。
资源
将旧类名完整映射到新类名，如果您遇到自动重构问题，或者需要找出具体的更改，这可能会很有用。
来自 Dan Lew 的精彩文章，强调了他重构他项目的经历（以及遇到的问题）。
来自 Android Developers 的 Jetpack 博客文章介绍。
感谢 Elliot Mitchell 的校对和灵感！