AndroidX 迁移实录 | 项目复盘

817 阅读4分钟

一、项目简介:

首先介绍一下 AndroidX ,在古老的 Android 中存在着 support 库这个老大哥,由于种种历史原因,在 support 库中又存在着v4,v7的版本差别。为了统一依赖库的命名,也为了更精确的导入依赖库,减少应用包体积,Google 2018 IO 大会 推出了 AndroidX ,目前新建项目也会默认选择 AndroidX。可以预测的是,未来将会有越来越多的第三方库支持 AndroidX ,因此升级 Androidx 是大势所趋。

在这次的项目复盘中,我来说说如何将公司项目从 support 库的 27 版本升级到 Androidx,包括整个迁移过程和踩坑实录。

二、项目背景:

由于公司项目是由16年开始迭代至今,所用的 support 库也是 27 版本的,心心念想尝试 Jetpack Compose 却没有办法。而且很多开源项目都只维护 AndroidX 版本,影响开发心情。因此决定迁移到 AndroidX。

其实迁移到 AndroidX 不仅仅是为了尝新,要知道 Google 对 support 库的维护永远停留在了 28 版本,而很多的开源项目也停止了对 support 库版本的维护。也就是说,一直使用 support 库将没有办法去修复旧 bug 和体验新功能。

三、实践过程:

既然有了想法,那就大步向前!

1. 另起炉灶

首先安全意识拉满,先拉一个单独的分支进行迁移工作。

由于项目中的Android support 库版本是 27 ,因此首先按照 Google 官方提供的迁移思路:先将版本库升级到 28 ,如果在 28 的版本上运行没有问题的话,就可以升级到 AndroidX 。这是因为 AndroidX 和 support 库的 28 版本只有命名上的区别。

2. 偷天换日

在 gradle.properties 文件中添加下面两句话。

android.useAndroidX=true
android.enableJetifier=true

这里的第一句话好说,顾名思义使用 AndroidX。

第二句表示会将你项目中的依赖库替换为 AndroidX 版本的。然而这个功能有些激进了,它实际上替换的是 AndroidX 中的Beta版本,而不是稳定版本,因此迁移后还需要再观察观察。

3. 一拍两散

等你完成了迁移前的工作,那么重头戏来了,一键迁移

按下Refactor -> Migrate to AndroidX。

喝杯奶茶,你的项目就会自动迁移的 AndroidX 了。(其实后面还要点一堆默认选项)

会有这么简单吗,确实没有。

4. 难舍难分

经过漫长的等待后,我发现 Android Studio 提供的一键迁移到 AndroidX 没有想象中靠谱,还有以下几个问题:

  1. 还需要手动将xml布局文件和Java文件中的 support 组件修改为 AndroidX 的版本,具体可以查看官网中的替换查找表。
  2. 需要将第三方库版本替换为支持 AndroidX 的版本。这里需要注意的是,上面提到的android.enableJetifier=true会使用 Beta 版本,因此需要再三留意选择自己合适的稳定版本
  3. 如果你的项目是组件化开发,或者用到了 config.gradle 进行项目配置,那么也需要修改文件内相应依赖库。
  4. 最后再对混淆文件中的 support 相关进行修改,替换为 AndroidX的。

至此,迁移任务大功告成。

四、总结思考:

对于 AndroidX,只有一个字:真香!

其实从很久之前就有想法去迁移到 AndroidX,但是一直没有付诸行动。主要是因为之前业务比较繁忙,也不好在开发过程中进行迁移。恰巧最近比较空闲,也下定决心解决这个痛点,才有了这篇文章的诞生。而通过这次的迁移,对 AndroidX 的一些新特性又有了更进一步的认识,可以算得上收获颇丰。

就迁移到 AndroidX 本身来说,并不是什么难点。但是对开发人员来说,更重要的是迁移后对开发效率的提升,以及不用担心 support 库被抛弃的踏实,巴适~

参考文章:

  1. Google 官方迁移指南

本文正在参与「掘金 2021 春招闯关活动」, 点击查看活动详情