- 原文地址:Cross-stitching Plaid and AndroidX
- 原文做者:Tiem Song
- 译文出自:掘金翻译计划
- 本文永久连接:github.com/xitu/gold-m…
- 译者:Mirosalva
- 校对者:PhxNirvana
一份 AndroidX 的迁移指南html
由 Virginia Poltrack 提供图片。前端
Plaid 是一款呈现 Material Design 风格和丰富交互界面的有趣应用。最近这款应用经过现今的 Android 应用开发技术实现了一番重构。获取更多应用信息和从新设计的视觉效果,能够查阅 Restitching Plaid。android
和大多数 Android 应用同样,Plaid 依赖 Android Support Library,该库能够为新 Android 特性提供向后兼容性,以即可以运行在旧版操做系统的 Android 机上。在 2018 年的 9 月份,最新的 Support Library 版本(28.0.0)被发布,和 Support Library 一块儿发布的 Android 库已经被迁移到 AndroidX(除了 Design 库被迁移到 Android 的 Material Components),而且这些库的新增开发都是基于 AndroidX。所以,接收 bug 修复、新功能和其余库更新的惟一选择就须要将 Plaid 迁移到 AndroidX。ios
在 2018 Google I/O 大会上,Android 团队发布了 AndroidX。它是 Android 团队用于开发、测试、打包、定版以及在 Jetpack 中发布库时所用到的开源代码。和 Support Library 相似,每个 AndroidX 库都是独立于 Android OS 来发布,而且提供了跨 Android 版本的向后兼容性。它是对 Support Library 的重大改进和全面替代方案。git
阅读下文来了解咱们如何为迁移过程准备本身的代码,以及执行迁移过程。github
我强烈建议在一个版本可控的分支作迁移工做。这样你能够逐步解决可能出现的任何迁移问题,同时分离出每一个变动用于分析定位问题。你能够在这个 Pull Request 下查看咱们的讨论过程,而且经过点击下面的提交连接来跟进最新信息。另外 Android Studio 提供了一个迁移前作工程备份的可选服务。后端
和任何大规模代码的重构工做同样,最好在迁移到 AndroidX 期间,迁移分支与主要开发分支之间作到最少合并来避免合并冲突。虽然对其余应用来讲不可行,可是咱们团队可以临时暂停向主分支提交代码以帮助迁移。一次性迁移整个应用也很是必要,由于部分迁移——同时使用 AndroidX 和 Support 库将会致使迁移过程当中的失败。bash
最后,请阅读 developer.android.com 网站上迁移至 AndroidX 文中的提示。如今让咱们开始吧!架构
在你开始以前,对代码准备的最重要的一点建议是:app
确保你正在使用的依赖库是与 AndroidX 兼容的。
依赖于一个旧版 support 库的第三方库可能与 AndroidX 不兼容,这颇有可能致使你的应用在迁移到 AndroidX 后没法编译。检查你的应用任意依赖是否兼容的一个方法是访问这些依赖的项目站点。一个更直接的方法是开始迁移,而且检查可能出现的报错。
对于 Plaid 应用,咱们使用了一个与AndroidX 不兼容的图形加载库 Glide 的旧版本(4.7.1)。这致使迁移后出现一个让应用没法构建的代码生成问题(这是一个记录在 Glide 工程下的相似问题),在开始迁移以前咱们把 Glide 更新到版本 4.8.0(参考此次提交),这个版本添加了对 AndroidX 注解的支持。
关于这一点,请尽量地更新到你的应用所依赖第三方库的最新版本。这对 Support 库而言尤为是一个好主意,由于升级到 28.0.0(截至撰写本文的最终版本)将使迁移更加顺畅。
迁移过程当中咱们使用了 Android Studio 3.2.1 版本中内置的重构工具。 AndroidX 迁移工具位于菜单栏的 Refactor > Migrate to AndroidX 选项。这个选项将迁移整个项目的全部模块。
运行 AndroidX 重构工具后的预览窗口。
若是你不使用 Android Studio 或者更倾向于其余工具来作迁移,请参考 Artifact 和 Class 来对比新旧支持库间架构和类的改动,这些材料也有提供 CSV 格式。
Android Studio 中的 AndroidX 迁移工具是 AndroidX 迁移的主要方式。这个工具正在持续的优化中,因此若是你遇到问题或者但愿查看某个功能,请在 Google 问题追踪页提交一票。
变动最少的代码以保证应用能够仍能正常运行。
在运行 AndroidX 迁移工具后,大量的代码被变动,然而项目却没法编译成功。此时,咱们仅仅作了最少许的工做来使应用从新运行起来。
这个方法有利于把流程拆解为可控的步骤。咱们留下了一些任务,诸如修复导入顺序、提取依赖变量、减小完整 classpath 的使用,以便后续的清理工做。
刚开始出现的报错之一是重复的类 —— 像这种状况,PathSegment
:
Execution failed for task ':app:transformDexArchiveWithExternalLibsDexMergerForDebug'.
> com.android.builder.dexing.DexArchiveMergerException: Error while merging dex archives:
如何解决这个问题参考这里: https://developer.android.com/studio/build/dependencies#duplicate_classes.
Program type already present: androidx.core.graphics.PathSegment
复制代码
这是一个由迁移工具生成错误依赖(androidx.core:core-ktx:0.3
)致使的报错。咱们手动更新(参考此次提交)到正确的依赖版本(androidx.core:core-ktx:1.0.0
)。这个bug 已经在 Android Studio 3.3 Canary 9 及以后的版本被修复。咱们指出这点是由于你或许在迁移过程当中会遇到相似的问题。
接下来,Palette
API 在新版中变得能够为空,为了暂时避开(参考此次提交)这点,咱们添加了!!
(非空断言操做符)。
而后咱们遇到了一个 plusAssign
缺失的报错。这个加载在 1.0.0 版本中被移除。plusAssign
的使用被临时注释掉了(参考此次提交)。本文的后面咱们会研究对 Palette
和 plusAssign
问题的可持续解决方案。
如今应用能够运行了,到清理代码的时候了!
应用在运行中,可是咱们的持续集成系统报告了代码提交后的构建错误:
Execution failed for task ':designernews:checkDebugAndroidTestClasspath'.
> Conflict with dependency 'androidx.arch.core:core-runtime' in project ':designernews'.
Resolved versions for runtime classpath (2.0.0) and compile classpath (2.0.1-alpha01) differ. This can lead to runtime crashes.
To resolve this issue follow advice at https://developer.android.com/studio/build/gradle-tips#configure-project-wide-properties.
Alternatively, you can try to fix the problem by adding this snippet to /.../plaid/designernews/build.gradle:
dependencies {
implementation("androidx.arch.core:core-runtime:2.0.1-alpha01")
}
复制代码
咱们依照测试日志中的参考建议,添加了缺失的依赖模块(参考此次提交)。
咱们也借此机会更新了咱们的 Gradle 插件版本、Gradle wrapper 版本、Kotlin 版本(参考此次提交)。Android Studio 推荐咱们安装 28.0.3 版本的构建工具,咱们也照作了。在使用 Gradle 3.3.0-alpha13 版本插件时咱们遇到的问题,经过降级到 3.3.0-alpha8 版本的方式获得解决。
迁移工具的一个缺点是:若是你在依赖版本项使用了变量,迁移工具把它们自动内联。咱们从 build.gradle 文件中从新提取了这些版本(参考此次提交)。
上文中咱们提到了运行 AndroidX 迁移工具后对 plusAssign
和 Palette
问题的临时解决方案。咱们经过将 AndroidX 版本下降来从新添加了 plusAssign 函数和相关测试(参考此次提交),而且恢复了被注释了的代码。与此同时,咱们把 Palette
参数更新到能够为空的这个版本(参考此次提交),这样就无需使用操做符 !!
。
一样的,自动转化可能使得某些类须要使用它们的完整类路径。作最少的手工修正是一个好的思路。做为清理工做的一部分,咱们移除了完整类路径,并在必要时从新添加了相关引用。
最后,一些少许测试相关的修改被加入工程,围绕着测试过程当中的依赖冲突(参考此次提交)和 Room 的测试用例(参考此次提交)。这时咱们的工程完成所有转化,而且咱们的测试都已经过。
尽管遇到了一些障碍,AndroidX 的迁移进展得比较顺利。遇到的问题主要涉及依赖库或类的错误转换,以及新库中的 API 变化。 幸运的是这些都相对容易解决。Plaid 如今已经准备好再被用起来了!
若是发现译文存在错误或其余须要改进的地方,欢迎到 掘金翻译计划 对译文进行修改并 PR,也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。
掘金翻译计划 是一个翻译优质互联网技术文章的社区,文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域,想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。