浅谈迁移Androidx的必要性

309 阅读2分钟

前言

android.support v4 v7是什么;

  • 它们都是依赖包,跟第三方依赖包一样;
  • 出现目的,是为了在低版本平台使用高版本的特性,例如想在minSdkVersion=8的机子使用Fragment能力,Fragmet是api 11才有的,这时候就需要用到support包;
  • v4 最低支持api 4及以上的平台(Android 1.6),v7 最低支持api 7及以上的平台(Android 2.1);
  • 引入v7必须同时引入v4,两者强相关,不能做到单独依赖;

android.support的使用问题

1. 版本选择;

support 依赖包版本得跟targetSdkVersion版本匹配,否则会出现找不到类的情况,相信接触过support包的同学都遇到过。

2.官方后续维护

官方称support不再维护,发现有bug也不会解决;

引入androidx的必要性

1.依赖更新的第三库

很多第三方库都已经基于androidx开发,如果旧版本有问题或新版本有新特性,就不得不升级到新版。基于support和androidx无法共存的问题,那么你的项目也得升级到androidx。

2.减少apk体积

androidx 将组件拆分得更细,可以按需接入,也就意味着apk可以更小,下载更快;

3.引入Jetpack

虽然Jetpack也有旧版本可以使用,但是新特性的更新必然是在androidx上;

4.使用Kotlin

如果要使用Kotlin,as、gradle版本都得升级,那么as就会强制你使用androidx,反正我是遇到这个问题;

Androidx迁移步骤

  1. 升级as 版本和 gradle 的版本;

  2. 使用as提供的一键迁移;

  3. 开启

android.useAndroidX=true
android.enableJetifier=true

4.动态修改反射用的support类命以及xml布局文件使用的控件类名; 5.不断的修改、编译,直到编译通过;

验证迁移成功

  1. 编译运行通过;

  2. 通过support关键字查找,项目中不存在相关类;

  3. 通过lint检查;

  4. 没有再依赖任何support包;

经验

  1. 修改代码过程中,如果对于修改不是很确定,记得做记录重点测试,例如api变更;

  2. 有一点比较奇怪,网上很多人说需要升级的第三库,以便匹配androidx,但是我没有升级,也能编译运行,不知道是不是开启android.enableJetifier的原因;

  3. 建议有条件的还是升级第三方库,毕竟是最新。我是为了控制出现错误的范围,才选择没有升级,因为一旦升级,api就有可能发生变化,对应业务不太熟悉,就会很痛苦,多一事不如少一事。