过渡到Androidx的主题现已浮出水面。
Daniel Lew已经有
一篇英文短篇文章 ，有一篇
报告 。 但是他们所有人都只是从表面上考虑了
Google文档中介绍的过渡方案。
我想分享我的经验。 我的项目使用Moxy和Cicerone，我发现我的经验很有趣，因为在这些库的官方电报频道中，何时将它们转移到Androidx时会定期出现此问题。
只需迁移到AndroidX ...
为了将项目转移到Androidx，您需要执行一些简单的步骤：
1.安装
compileSdkVersion 28和
targetSdkVersion 28 ，将所有支持库更新为最新版本。
2.在
gradle.properties文件中添加以下行：
android.useAndroidX=true android.enableJetifier=true
3.如果您已经在使用Android Studio 3.2，请使用重构：
他将为您完成大部分（或更少）工作。
如果由于某种原因您没有使用Git或其他版本控制系统，那么在此阶段，您将有机会创建项目档案：
单击“迁移”按钮，选择保存档案的位置，过一会儿，我们得到在重构之前检查项目的结果：
在这里，我们看到将替换build.gradle和import指令中的哪些依赖项。 在上面的屏幕快照中可以看到的MainActivity类的示例中，将替换一个依赖项：
android.support.v4.view.GravityCompat ，但是如果我们打开此类，我们将看到实际上还有三个需要替换的依赖项：
我不了解这种选择性行为的原因，但是这些依赖关系必须手动修复。 单击“执行重构”。
如果您未使用Android Studio 3.2，则将手动更正所有依赖项必须更改
build.gradle中的依赖
项 （为清楚起见，我注释掉了旧的依赖项）：
完整的替换清单可在
此处找到。
然后与Gradle同步项目，并得到一堆错误。 这些是您类中的import指令，它们引用旧软件包，您需要根据
此表进行更改。
因此，由于工作室无法替换所有依赖项（也许可以，那么可以恭喜），因此当您尝试构建项目时，会看到类似的错误列表：
打开带有错误的类，我们将看到类似以下内容：
我们删除过时的依赖项，并通过热键Alt + Enter从
androidx包中导入类
因此，我们修复了所有类。 如果错误与“导入”无关，则不要关注它，这很可能是由于另一个类中的相同问题所致。
例如：
这里的错误与以下事实有关：在TimelineView类中，您还需要消除导入问题。 当所有错误均已修复后，我们将再次执行项目构建，也许我们会再次获得错误列表，仅在其他类中，我们才能继续迭代过程。
对于所生成类的错误（Dagger或DataBinding），在此阶段不要关注。 如果您的班级中没有错误，并且工作室只对生成的代码发誓，那么您需要运行“清理项目”和“重建项目”。
如果这样做没有帮助，您可以尝试清除工作室缓存：
您将必须至少清除一次缓存，以便正确创建生成DataBinding或Room的类。
外部图书馆
通常，我们将
android.enableJetifier = true标志设置为仅在项目构建阶段将外部库的依赖项自动替换为相应的AndroidX依赖项，但是由于某种原因不会发生这种情况。
无论如何，在执行下面描述的操作之前，请确保您有此问题，并且所使用的库的最新版本尚未转换为AndroidX。
莫西
我项目中的
MainActivity是从
MvpAppCompatActivity继承的，是Moxy类，在撰写本文时，该类尚未转换为AndroidX。 为了解决这个问题，我将该类复制到了一个单独的
androidx包中的项目中，并修复了其中的依赖项。 最好不要更改类名，这样将更容易更新依赖关系。
对于
MvpAppCompatFragment类，需要对片段执行相同的过程。
请注意，这些类中有一个通用类，在
mMvpDelegate字段中，不要忘记修复其中的依赖项，因为它是Moxy类而不是支持库类的依赖项，因此很容易注意到它。
西塞龙
为了解决Cicerone的问题，我必须在项目中创建
SupportAppScreen和
SupportAppNavigator类的副本。 请注意，SupportAppNavigator类依赖于SupportAppScreen。 请记住要在副本上解决此依赖性。
结论
切换到AndroidX是一种令人兴奋的体验，也许如果您没有紧急需求，则应该稍等片刻。 毕竟，当将大部分耙从路径中移除时，这样做会更加轻松快捷。 但就我个人而言，我很高兴这条路已经过去，额头上的颠簸将he愈，有用的经验将继续存在。