一直以来，我们始终专注于三件事：提供最佳实践指南、减少样板代码以及简化开发流程。我们的目标，是帮助开发者把更多精力放在真正关键的业务逻辑上。Jetpack 正是为此而生，它包含的一系列库、工具和开发指南，能够帮助您更高效地构建高质量 Android 应用。
那么，Jetpack 和 AndroidX 到底是什么关系呢？Jetpack 中的所有库都统一使用 AndroidX 作为包名，同时我们也将 AndroidX 作为一个用于开发、测试与发布 Jetpack 库的开源项目体系。
在 2018 年的 I/O 大会上，我们正式公布了将 Support Library 重构到 AndroidX 命名空间的计划。在 Support Library 28 中，这项重构已经完成，并发布了 AndroidX 1.0。也就是说，如果您希望使用 Jetpack 带来的新能力与开发便利，就需要将旧版 Support Library 迁移到 AndroidX。
为什么有必要迁移至 AndroidX
您可能会疑惑：既然 AndroidX 本质上只是 Support Library 28 的重构版本，为什么还要专门迁移？关于这个问题，主要有以下几个原因：
Support Library 已经完成了它的历史任务，28 将是它的最后一个发布版本。后续我们不会继续在 Support Library 中修复 bug，也不会再为其增加新功能；
更优秀的依赖与包管理能力：独立版本、独立命名以及更高频率的更新机制，这些都是 AndroidX 天生具备的优势；
目前，许多常用的 Android 开发工具库都已经迁移至 AndroidX，例如 Google Play 服务、Firebase、Butterknife、Mockito 2、SQL Delight，后文我们也会提到这些依赖应如何迁移；
我们正在持续推广 AndroidX 命名空间，未来所有新的组件库，例如 Jetpack Compose 和 CameraX，也都会成为 AndroidX 生态的一部分。
如何迁移至 AndroidX
前期准备
在正式开始 AndroidX 迁移之前，为了让整个升级过程更加顺利、平稳，我们建议您先做好以下准备：
首先，备份整个工程。虽然大多数开发者都在使用代码版本控制系统，但由于迁移 AndroidX 会涉及大量文件变更，仍然建议您额外备份完整项目；
其次，尽量减少与迁移同时进行的新功能开发；
最后，强烈建议您在单独的分支中完成 AndroidX 迁移工作。
开始迁移
在整个 AndroidX 迁移过程中，我们的重点是持续解决编译错误，直到应用能够成功构建并通过全部测试。
下面是迁移流程的整体思路。虽然步骤看起来不少，但本文会对每个关键环节逐一说明：
第一步: 将 Support Library 升级至 28
首先，我们建议您将当前项目中使用的 Support Library 依赖统一升级到 28 版本。如果您是从更早期的 Support Library 版本直接迁移，可能不仅会遇到 API 不兼容的问题，还需要同时处理命名空间变更；而 Support Library 28 与 AndroidX 在 API 层面基本一致，差异主要集中在命名空间。因此，更推荐您先把 Support Library 升级到 28，解决所有 API 变动并确保工程能够正常编译，然后再进入下一步 AndroidX 迁移，这样整体修改成本会更低。
第二步: 开启 Jetifier
接下来需要完成的操作是启用 Jetifier。Jetifier 的作用，是帮助您把第三方依赖库中仍基于旧 Support Library 的部分转换为可兼容 AndroidX 的形式。顾名思义，Jetifier 会对这些第三方依赖进行处理，使它们能够与已迁移到 AndroidX 的工程正常协作。不过需要注意的是，Jetifier 不会修改您的项目源码，也不会处理自动生成的代码，因此一般不必担心它会对工程造成额外副作用。
开启 Jetifier 非常简单，您只需要在 gradle.properties 文件中加入 "android.useAndroidX = true" 和 "android.enableJetifier = true" 即可。其中，"useAndroidX" 用于启用 AndroidX 库的自动导入功能，这样在自动补全或添加依赖时，系统会优先导入 AndroidX 对应库。
第三步: 检查第三方库版本的兼容性
启用 Jetifier 之后，下一步就是检查并升级第三方依赖库，确保它们使用的是兼容 AndroidX 的版本。实际上，在您真正开始迁移之前，最好先把所有依赖更新到当前可用的较新版本。
为什么要这样做？因为我们自己就在这个问题上吃过亏。我们有一个示例应用 Plaid，它依赖图片加载库 Glide。原本我们打算用 Plaid 来演示如何将 Android 应用迁移到 AndroidX，但在没有提前检查 Glide 版本兼容性的情况下直接开始迁移，结果遇到了大量编译错误。后来排查才发现，问题出在当时使用的 Glide 版本本身并不兼容 AndroidX。
而当我们将 Glide 以及其他依赖库全部升级到更新版本之后，再重新开始迁移，同样的问题就不再出现了。因此，在着手 AndroidX 升级之前，建议您先全面检查并更新项目中的第三方依赖，因为新版本库往往已经完成了对 AndroidX 的适配。还需要特别注意，Jetifier 并不能帮您处理那些包含自动生成代码的依赖库，所以这类库是否兼容 AndroidX，仍然需要您亲自确认。
如果跳过前面这两步，您很可能会遇到以下问题：
- 如果当前使用的第三方库还不兼容 AndroidX，您会发现它仍然在尝试拉取旧版 Support Library；
- 如果项目处于部分迁移状态，还可能出现类型重复的报错，这是因为工程同时从 Support Library 和 AndroidX 中拉取了相同代码。
第四步: 将 Support 库依赖转换为 AndroidX
开始这一步之前，您应当已经完成了前面的三个阶段：将 Support Library 升级到 28、启用 Jetifier，以及检查和升级第三方依赖库。确认这些前置条件都已处理妥当后，就可以正式开始把 Support 库迁移到 AndroidX 了。这里有以下三种常见方法可供参考：
- 使用 Android studio 自动迁移工具
我们在 Android 3.2 稳定版中加入了 "Migrate to AndroidX" 选项，方便开发者快速完成迁移。您可以在 "Refactor" 菜单中找到 "Migrate to AndroidX" 这一功能：
这个按钮的作用，就是将源码中的相关依赖和引用迁移到 AndroidX。在理想情况下，它能够帮助您完成大部分 AndroidX 自动迁移工作。
- 使用自动迁移脚本
我们也意识到，并不是所有团队都使用 Android Studio，同时有些 Android 项目的结构过于复杂，导致自动迁移工具无法顺利生效。
因此，您还可以选择另外两种方式，其中一种就是使用 bash 脚本，配合 grep 和 sed 命令完成批量替换。在介绍如何通过脚本迁移 AndroidX 之前，我们也特别感谢 Dan Lew 提供了这一实用工具。
您可以通过短链接: goo.gle/androidx-migration-script 访问脚本源码所在的 GitHub 页面，在那里也能看到更多来自社区的补充与贡献。
这个脚本的原理并不复杂。您需要手动配置类型映射表 "androidx-class-mapping.csv" 以及项目路径，而脚本核心逻辑实际上就是通过 grep 搜索，再结合 sed 命令批量替换工程中的导入包名：
不过，由于脚本处理方式相对直接，某些场景下可能会引发误替换或其他问题。所以如果您打算通过脚本执行 AndroidX 迁移，一定要提前评估风险并做好校验。
- 人工迁移
另一种方式，就是手动完成迁移。在 迁移到 AndroidX 中，您可以查看前文提到的 Support Library 与 AndroidX 的类型映射表。如下图所示，有了这份映射关系表之后，您就能够结合项目实际情况逐项替换：
完成这一步之后，只要重新编译项目，并修复迁移过程中受影响的测试，您就可以得到一个完全基于 AndroidX 的工程。可喜可贺！
可能遇到的问题
当然，实际迁移过程往往不会总是一帆风顺。下面整理了一些 AndroidX 迁移中常见的问题，希望能为您提供帮助。
常见的需要手动处理的情况
以下图为例，我们可以看到这里依赖的仍然是 Support Library，并且 drawerLayout 和 recyclerview 的版本号是通过一组变量统一管理的：
遇到这种情况时，自动迁移工具不会保留您原先的变量配置，而是直接将这些依赖替换成明确写死的 AndroidX 版本。如果您仍希望继续使用变量来统一管理依赖版本，就需要手动把这些 AndroidX 依赖重新改回变量引用形式。
此外，自动迁移工具也不会修改您的混淆配置文件和构建脚本。如果这些文件中同样包含旧包名或相关引用，您也需要手动完成相应调整。
冲突处理
前面我们已经提到，最好在新的分支中处理 AndroidX 迁移，这里再补充一些实践建议。
由于迁移会涉及大量文件修改，因此我们建议尽量放缓，甚至临时停止当前并行进行的开发工作。虽然让整个团队暂停开发听起来有些夸张，但这种做法确实能够显著减少后续代码合并冲突。
如果无法完全停止开发，那么退一步说，在条件允许的情况下，最好安排部分成员在独立分支中集中完成迁移工作。同时，也要提前提醒团队其他成员，后续很可能会出现分支合并冲突。
在处理依赖迁移时，请把注意力集中在修复错误上，以项目能够成功编译并通过全部测试为首要目标。不要一边迁移 AndroidX，一边顺手重构代码或添加新功能。
检查自动迁移工具导入的库版本
当您运行完自动迁移工具之后，可能会发现新的依赖中既包含稳定版，也包含 Alpha 版。这通常取决于当时可获取的最新发布版本。您需要根据自己项目的稳定性要求和实际需求，手动调整这些 AndroidX 依赖的版本号。
文档资源
最后，我们整理了一些与 AndroidX 迁移相关的重要文档，方便您后续回顾与查阅。
AndroidX 概览 包括：AndroidX 总览、迁移指南，以及 Support Library 到 AndroidX 库稳定版和 Alpha 版的映射关系表。如果您计划使用脚本完成迁移，这里也提供了映射关系表对应的 CSV 文件。
我们还有一篇关于 Kotlin & Jetpack 实践技巧的文章: 把 "格子衫" 改造得更时尚，详细介绍了示例工程 Plaid 迁移到 AndroidX 的全过程。在这篇文章中，我们说明了迁移步骤、遇到的问题以及对应的解决思路。
此外，我们还提供了 问题追踪页，您可以在该页面查看当前正在处理的问题，也可以通过左上角的按钮提交新的问题反馈给我们。
祝大家都能顺利、高效地完成 AndroidX 迁移！
您也可以通过视频回顾 2019 Android 开发者峰会演讲 —— 是时候迁移至 AndroidX 了!
