前语
年中的时分一向有开发同学反应想晋级各个根底库的版别，并且咱们也有每年一调整的方案，所以前一阵子就顺便一同做了一次晋级迭代根底库的操作。
这儿我便是想吐槽下，安卓开发系统实在是过于臃肿了，明明便是几个官方库晋级的操作，没想到居然会相互影响。实在的让人害怕！
Kotlin 1.7.0 正式发布！主要新特性一览
kotlin 晋级引出来的一堆问题
咱们master的kotlin版别是1.5.31，开发同学打算晋级的版别是1.6.21，而kotlin官方最新版别是1.7.10，我想了想直接干最新的啊，一步到位岂不是美滋滋。
别的开发同学的另一个诉求是晋级compose的根底依赖的,由于低版别的存在一个bug，有必要晋级版别才能修正。之前文章也介绍过compose的一部分完结原理是根据kcp的，那么也就导致了compose compiler和kotlin版别强绑定在一同。所以就必然要让这两个的版别晋级放在一同才行。而在compose的晋级过程中，由于kotlin最新版别刚刚完结发布，所以compose compiler还没有完结1.7.10的适配，只能被迫运用1.7.0的kotlin版别进行晋级了。别的由于改动点太多了，涉及一切事务回归等等，所以compose compiler硬生生等出了一个新的版别。
其间还闹出了一个笑话，我晋级1.7.10 版别有一部分原因是想尝试下K2编译器的，晋级的报错仓库中我发现了一个很有意思的仓库信息，便是k2jvmcompiler我一惊，起飞这不便是默许开启了吗。最终和霍教师聊了下，发现这个k2的意思是kotlin to jvm，哈哈哈哈。就真的很为难，老脸一红！！！！
compose 拆开成两部分的，一部分是根底依赖库ui组件，别的一部分是compiler库。后续在最新版别中compiler库的版别号现已不好根底库一同晋级了。
还有便是kotlin plugin迭代过程中呢，会变化一些extension特点。特别是在大版别的迭代过程中。本次kotlin官方在迭代中，先隐藏了useIR特点，在最新版别中更是对其进行了移除。所以工程内一切在build.gradle内声明晰useIR的都需要进行移除。悉数改造完结之后，我原本单纯的以为工程现已能够编译了，可是万万没想到啊咱们运用的android gradle plugin(后续简称agp)版别是7.0.3, 居然在agp内部运用了这个特点，导致了在履行阶段的时分会直接溃散。满屏的草尼玛啊！！！！！
kotlin 1.7.10晋级内容
由于这个问题吧，我去agp版别发布那边找了下，之后测试了大约一天左右，找到一个相对稳定并且改动最小的版别7.0.4。主要是由于后续版别虽然解决了这个问题，可是其间对于有ndk的工程有巨大的改造工作量，所以就直接放弃了。
hilt issue
当我以为事情现已稳步向前的时分，hilt也给我来了沉重的一击，由于kotlin 170 版别中kapt的改造，导致了hilt的一部分功能也呈现了编译反常还有运行溃散，真的是人都裂开了。编译问题咱们通过晋级hilt到最新版才解决的。可是由于最新版的hilt中运用了新版agp中的asm字节码操作去修正DI优化，所以最终在apk打包的时分，咱们把本来的hiltapplication移动到了com.android.application,最终才完全完结了hilt相关的适配工作。以前版别这个是随便是能够放在library内的。
别的，最终kotlin晋级和咱们项目的动态化部分也有所抵触，这儿就不展开这个了，反正便是很蛋疼。
语法反常
别的在改造过程中还有些语法反常，这些便是有点蛋疼，大约便是下面这么几种类型把。改起来就比较简单，便是单纯的膂力活了。
- kotlin 晋级导致的when else反常，只写了when没有else就会报错，直接会是编译反常。
- smartcast 反常，一部分is 判别之后不会直接进行强制类型转换了。
- 非空判别，本来有一部分判别语句中的?无效语法，现在直接变成error级别。
结尾
我个人觉得吧，工程一旦太大了这种根底组件的晋级就会变得十分的蛋疼。并且最让我没想到的便是没想到abc之间居然会相互影响，就让人有点措手不及，并且都是直接影响编译打包，疲惫。
别的便是compose 的规划居然和kotlin版别强制绑定的确不是一件好事。分仓的工程在接入compose的时分特别要稳重，晋级特别苦楚。
