前言
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迁移步骤
-
升级as 版本和 gradle 的版本;
-
使用as提供的一键迁移;
-
开启
android.useAndroidX=true
android.enableJetifier=true
4.动态修改反射用的support类命以及xml布局文件使用的控件类名; 5.不断的修改、编译,直到编译通过;
验证迁移成功
-
编译运行通过;
-
通过support关键字查找,项目中不存在相关类;
-
通过lint检查;
-
没有再依赖任何support包;
经验
-
修改代码过程中,如果对于修改不是很确定,记得做记录重点测试,例如api变更;
-
有一点比较奇怪,网上很多人说需要升级的第三库,以便匹配androidx,但是我没有升级,也能编译运行,不知道是不是开启android.enableJetifier的原因;
-
建议有条件的还是升级第三方库,毕竟是最新。我是为了控制出现错误的范围,才选择没有升级,因为一旦升级,api就有可能发生变化,对应业务不太熟悉,就会很痛苦,多一事不如少一事。