长久以来,咱们致力于作到三件事: 实践指南、减小模板代码和简化任务流程,咱们但愿帮助开发者们集中精力专一在真正须要考虑的逻辑中去。Jetpack 为此而生,它所包含的库、工具和指南,能够帮助您更轻松地编写高质量的应用。android
Jetpack 和 AndroidX 有什么关系呢? Jetpack 中全部库都使用 AndroidX 做为包名,咱们把 AndroidX 做为一个开发、测试和发布 Jetpack 库的开源工程。bash
在 2018 年的 I/O 大会上咱们宣布了把 Support Library 重构至 AndroidX 命名空间的计划。在 Support Library 28,咱们完成了重构,而且发布了 AndroidX 1.0。为了可以享受 Jetpack 所带来的便利,您须要将旧的 Support Library 迁移至 AndroidX。app
您可能会想: 既然 AndroidX 只是 Support Library 28 的重构,那为何要迁移呢? 关于这个问题,咱们有下面几个理由:ide
在开始迁移以前,为了使接下来的工做能够更加顺畅平滑,咱们但愿您能够作到如下几点:工具
在整个迁移步骤中,咱们将着重于解决错误,使您的应用编译并经过全部测试。测试
下面是迁移工做的流程示意图,虽然步骤很多,可是本文会对其中的每一步都作出说明:gradle
首先,咱们但愿您把当前的 Support Library 依赖升级至版本 28。若是您从早期版本的 Support Library 进行迁移,可能会在须要修改命名空间的同时遭遇 API 不兼容的问题; 而 Support Library 28 的 API 与 AndroidX 之间只有命名空间上的不一样。因此咱们建议,先尝试将 Support Library 升级至版本 28,处理过全部 API 变动,而且确保编译经过后,再进行下一步,这样所作的修改是最少的。google
接下来须要作的是开启 Jetifier。Jetifier 能够帮助您迁移第三方依赖库的依赖至 AndroidX。正如字面意思所说,Jetifier 会修改这些第三方依赖库的代码,从而使其与使用 AndroidX 的工程兼容。不过 Jetifier 不会修改您的源码和自动生成的代码,所以不用担忧它会形成额外的不良影响。spa
开启 Jetifier 十分的简单,您只须要在 gradle.properties 文件中加入 "android.useAndroidX = true" 和 "android.enableJetifier = true" 便可。"useAndroidX" 设置用于开启 AndroidX 库的自动导入,当您自动补全或导入依赖库时,会自动导入 AndroidX 库。3d
当您开启 Jetifier 以后,就要着手升级第三方依赖库到兼容的版本。在您真的开始迁移以前,最好把全部依赖升级到最新。
为何要这么作? 其实咱们本身就在这方面 "栽过跟头",咱们有一个演示应用: Plaid,它依赖了图片加载库 Glide,咱们原本打算使用 Plaid 来演示如何迁移应用至 AndroidX,但当咱们在没有检查 Glide 依赖库版本就开始迁移时,咱们遭遇了一堆编译错误。检查后才发现,当时依赖的那个版本的 Glide 没法兼容 AndroidX。
而当咱们把 Glide 和其余依赖库版本都升级后,再作迁移工做,就没有再出现相同的错误。因此,建议在开始迁移前,先检查和升级应用的第三方依赖,新版本的第三方库可能已经兼容 AndroidX。因为Jetifier 不会帮您迁移自动生成代码的依赖库,因此您仍是须要本身检查这类依赖是否兼容 AndroidX。
若是跳过了前面两步,您可能会遇到一些问题:
这一步开始前,您应该完成了前面三个步骤: 升级 Support Library 到 28 版; 开启 Jetifier; 升级和检查第三方依赖库。肯定这些都没问题后,咱们终于能够开始真正的迁移工做了。这一步有如下三个方法供您参考:
咱们在 Android 3.2 稳定版中加入了 "Migrate to AndroidX" 选项,方便你们迁移。您能够在 "Refactor" 菜单中找到 "Migrate to AndroidX" 选项:
这个按钮的功能,就是迁移源码中的依赖到 AndroidX,理想状况下,它会帮您完成绝大部分工做。
咱们也意识到有些团队使用的不是 Android Studio,并且也会有一些应用的结构过于复杂,使咱们的工具没法生效。
因此还有两种选择,其中之一即是使用 bash 脚本中的 grep 和 sed 命令。在介绍如何使用脚本进行迁移以前,咱们要特别感谢 Dan Lew 为咱们提供了这个工具。
您能够经过短连接: goo.gle/androidx-migration-script 去到脚本源码的 GitHub 页面,在那里您也能够找到更多的社区贡献内容。
脚本的工做原理并不复杂,以下所示,您须要手动作的是配置好类型映射表 "androidx-class-mapping.csv" 和工程路径地址,而脚本中真正有效的部分,就只是 grep 命令后跟着一个 sed 命令来替换工程中导入的包名:
因为脚本的处理十分简单粗暴,因此可能会在某些状况下形成一些错误。使用这种方式必定要本身内心有数。
另外一个选择,是人工进行迁移工做。在 迁移到 AndroidX 中,您能看到前文提到过的 Support Library 与 AndroidX 的类型映射关系表。以下图,有了这个映射关系表,您就能够根据具体状况进行替换:
这一步作完以后,只要您从新编译工程,而且修复那些迁移工做中损坏的测试,就能够得到一个基于 AndroidX 的工程。可喜可贺!
固然,真实的状况每每不会那么一路顺风。下面咱们收集了一些迁移过程当中常见的问题,但愿能帮到您。
如下图为例,咱们看到这里依赖的仍然是 Support Library,其中 drawerLayout 和 recyclerview 的版本是用一组变量设置的:
遇到这种状况时,自动迁移不会理会您以前的变量配置,它会直接把这些库替换成一个肯定的 AndroidX 版,若是您仍然想要使用变量管理这些库的版本号,就须要手动把 AndroidX 的依赖库版本改成使用变量设置。
自动迁移工具也不会修改您的混淆文件和构建脚本。若是这些文件中包含相关的包名,您须要手动去把它们改好。
咱们前面有提到,必定要在一个新的分支中处理迁移工做,关于这点还有一些和你们分享的内容。
因为迁移工做会修改大量的文件,因此咱们建议减缓或中止手头的开发工做。虽然要求整个开发团队停工听起来十分离谱,可是这样确实能够大大减小可能产生的合并冲突。
退而求其次的话,若是条件容许,最好能安排一些人手在一个单独的分支上专一于迁移的工做。与此同时,也要向团队中的其余成员预警即将到来的合并冲突。
在迁移依赖时,要专一于错误的修改,以编译成功和经过全部测试为首要目标。不要在迁移的同时进行重构或者引入新的功能。
当您运行完自动迁移功能后,您可能会发现新的依赖库中既有稳定版,又有 Alpha 版。这其实取决于咱们最新发布的版本。您须要手动修改这些依赖库的版本,以知足本身工程的特定须要。
咱们总结了一些与本文相关的文档放在最后,来方便您回顾和查找。
AndroidX 概览 包括: AndroidX 总览、迁移指南以及 Support Library 到 AndroidX 库稳定版和 Alpha 版的映射关系表。若是您想要使用脚本处理迁移,这里也提供映射关系表的 CSV 文件。
咱们有一篇文章介绍 Kotlin & Jetpack 实践技巧: 把 "格子衫" 改造得更时尚,描述了示例工程 Plaid 迁移至 AndroidX 的过程。在这篇文章中,咱们说明了迁移的步骤,遇到的问题和对应的解决方案。
咱们还提供了 问题追踪页,您能够在这个页面看到咱们正在解决的问题,也能够经过左上角的按钮创建新的问题给咱们。
祝你们都能顺畅地迁移至 AndroidX!
您也能够经过下面视频回顾 2019 Android 开发者峰会演讲 —— 是时候迁移至 AndroidX 了!