title: androidx迁移
date: 2019-10-15 11:49:20
tags: Androidx

Androidx 迁移总结

一、什么是androidx

背景

随着android版本的不断迭代更新，每个版本中都会有新的API加入，但是新加入的API在老的版本里并不存在，因此就出现了向下兼容的问题。于是android团队就退出了大名鼎鼎的支持库Android Support Library,用于提供向下兼容的功能。比如我们每个人都熟知的support-v4、suport-v7都是属于Android Support Library。

随着支持库版本的迭代，从最初的android Support v4到后来的v7、v13,以及在这其中又对支持库的内部拆分，使得支持库变得庞大而复杂。同时，支持库具体版本的最低支持的系统版本也在发生着变化，比如android Support v4,最初的命名含义就是最低支持API 4,但是到后来最低支持9、14等。含义的变化使得开发者在引入的时候不得不慎重核实。

且支持库为了更好地利用Android系统自身的一些新特性，每个版本的支持库内部又针对不同的编译版本，划分出了对各支持库细分版本。后来，开发者引入时，需要引入与当前项目编译版本对应的，且满足当前项目最低支持构建版本的具体支持库版本。比如常见的写法：

//支持库
            support_support_annotations       : "com.android.support:support-annotations:$versions.support",
            support_appcompat_v7              : "com.android.support:appcompat-v7:$versions.support",
            support_recyclerview_v7           : "com.android.support:recyclerview-v7:$versions.support",
            support_cardview_v7               : "com.android.support:cardview-v7:$versions.support",
            support_design                    : "com.android.support:design:$versions.support",
            support_support_v4                : "com.android.support:support-v4:$versions.support",
            support_support_core_utils        : "com.android.support:support-core-utils:$versions.support",

其中versions.support需要与项目编译版本保持一致，至少需要在大的Api Level上保持一致。

由于支持库过于混乱，最终导致的问题就是，开发者不方便使用，官方维护也困难。所以需要对支持库做一次统一的梳理。

androidx华丽登场

Android 官方于2018年Google I/O 大会发布了AndroidX。

AndroidX对原始的Android支持库做了重大的改进。AndroidX完全取代了支持库，不仅提供同等的功能，而且提供了新的库。而且AndroidX还包括以下功能：

• AndroidX 中的所有软件包都使用一致的命名空间，以字符串 "androidx." 开头(除了 Design 库被迁移到 Android 的 Material Components)。有关所有旧类到新类以及旧编译工件到新编译工件的完整映射，请参阅软件包重构页面。

• 与支持库不同，AndroidX 对各个Libray分开设立单独的版本管理，并且都严格遵守语义版本控制。

• 所有支持库新的API都在AndroidX中更新，包括原始支持库工件和引入新的 Jetpack 组件。

由于各个单独Library的独立版本管理，开发者就可以精确指定需要依赖的library,避免不必要的导入，从而减小代码体积。并且开发者在引入时，只需要关注AndroidX中具体的需要引入的构件版本即可。且大部分具体的构件，具有一致的版本号。开发者使用起来不再需要关注项目自身的最低支持版本和编译版本了，只需要像引入其他的第三方库一样，v1.0、v2.0、v3.0这种方式引入即可。

如原有的引入写法

com.android.support:recyclerview-v7:28.0.0

变成了

androidx.recyclerview:recyclerview:1.0.0

二、为什么迁移

AndroidX相较于原始支持库更友好，同时，官方文档明确表示原始支持库后续将不再维护。另外，在Android Studio新建模块时，如果没有迁移到AndroidX,模块是创建不了的。

image

新建项目时也是默认使用androidX库，并且是无法取消的。

image

而且，主流的第三方库如butterknife、glide等都已适配AndroidX。如果要用使用它们的新特性，迁移到androidX也是前提。

三、怎么迁移

前提准备

• Android Studio 3.2及以上。当前时点最新版本已经是3.5.1稳定版了。
• AGP版本3.2.0及以上，对应的Gradle版本4.6及以上。
• 项目编译版本28及以上。

注意： 最好在一个版本可控的分支进行迁移，因为涉及到变动的类或文件会非常多，避免合并代码时冲突。
同时,分离出没次变更，以便于分析定位问题。

迁移过程

Android官方提供了具体的迁移文档：
https://developer.android.com/jetpack/androidx/migrate

Android Studio一键迁移

Android Studio 3.2 及以上版本提供了更加方便快捷的方法一键迁移到 AndroidX，Refactor > Migrate to AndroidX:

image

然而，一键迁移并不是万能的，有些库还是无法很好识别并迁移，还是需要手动迁移。

四、遇到的问题

1. 部分库不会自动替换，需要手动替换

design库，因为并不是以androidx.开头,并没有自动替换掉，比如：

android.support.design.widget.AppBarLayout
替换成
com.google.android.material.appbar.AppBarLayout

coordinatorlayout库，
如：

android.support.design.widget.CoordinatorLayout 
替换成
androidx.coordinatorlayout.widget.CoordinatorLayout

布局文件
部分布局文件还是需要手动进行替换。

比较保险的解决方案：
全局搜索android.support，然后一个一个找(任意文件)，然后在官方迁移文档找到原先支持库对应的AndroidX库，进行替换。

注意：：如果项目中用到FilProvider,会搜索到android.support.FILE_PROVIDER_PATHS,这个是不用改的。参考资料

2. Glide中使用的 android.support.annotation.CheckResult 和 android.support.annotation.NonNull这两个注解无法迁移

查看Glide仓库发现有人提过issue:https://github.com/bumptech/glide/issues/3185

解决:
升级Glide版本到4.8.0或更高,问题解决。

3. Butterknife依赖编译无法通过。

解决：
由于Butterknife中用到android.support.v4.content包，而在AndroidX中找不到了所以报错。

image