[译] Plaid 应用迁移到 AndroidX 的实践经历，安卓卡顿优化方法

Plaid 是一款呈现 Material Design 风格和丰富交互界面的有趣应用。最近这款应用通过现今的 Android 应用开发技术实现了一番重构。获取更多应用信息和重新设计的视觉效果，可以查阅 Restitching Plaid。

• Restitching Plaid: 把 Plaid 更新到最新应用标准
  

和大多数 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。

什么是 AndroidX?

在 2018 Google I/O 大会上，Android 团队发布了 AndroidX。它是 Android 团队用于开发、测试、打包、定版以及在 Jetpack 中发布库时所用到的开源代码。和 Support Library 类似，每一个 AndroidX 库都是独立于 Android OS 来发布，并且提供了跨 Android 版本的向后兼容性。它是对 Support Library 的重大改进和全面替代方案。

阅读下文来了解我们如何为迁移过程准备自己的代码，以及执行迁移过程。

迁移前准备

我强烈建议在一个版本可控的分支做迁移工作。这样你可以逐步解决可能出现的任何迁移问题，同时分离出每个变更用于分析定位问题。你可以在这个 Pull Request 下查看我们的讨论过程，并且通过点击下面的提交链接来跟进最新信息。另外 Android Studio 提供了一个迁移前做工程备份的可选服务。

和任何大规模代码的重构工作一样，最好在迁移到 AndroidX 期间，迁移分支与主要开发分支之间做到最少合并来避免合并冲突。虽然对其他应用来说不可行，但是我们团队能够临时暂停向主分支提交代码以帮助迁移。一次性迁移整个应用也非常必要，因为部分迁移——同时使用 AndroidX 和 Support 库将会导致迁移过程中的失败。

最后，请阅读 developer.android.com 网站上迁移至 AndroidX 文中的提示。现在让我们开始吧！

依赖标识

在你开始之前，对代码准备的最重要的一点建议是：

确保你正在使用的依赖库是与 AndroidX 兼容的。

依赖于一个旧版 support 库的第三方库可能与 AndroidX 不兼容，这很有可能导致你的应用在迁移到 AndroidX 后无法编译。检查你的应用任意依赖是否兼容的一个方法是访问这些依赖的项目站点。一个更直接的方法是开始迁移，并且检查可能出现的报错。

对于 Plaid 应用，我们使用了一个与 AndroidX 不兼容的图形加载库 Glide 的旧版本（4.7.1）。这导致迁移后出现一个让应用无法构建的代码生成问题（这是一个记录在 Glide 工程下的类似问题），在开始迁移之前我们把 Glide 更新到版本 4.8.0（参考这次提交），这个版本添加了对 AndroidX 注解的支持。

关于这一点，请尽可能地更新到你的应用所依赖第三方库的最新版本。这对 Support 库而言尤其是一个好主意，因为升级到 28.0.0（截至撰写本文的最终版本）将使迁移更加顺畅。

使用 Android Studio 进行重构

迁移过程中我们使用了 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.a

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

ndroid.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 问题的可持续解决方案。

现在应用可以运行了，到清理代码的时候了！