kotlin compose 升级的苦涩 | 一地鸡毛

年中的时候一直有开发同学反馈想升级各个基础库的版本，而且我们也有每年一调整的计划，所以前一阵子就顺便一起做了一次升级迭代基础库的操作。

这里我就是想吐槽下，安卓开发体系实在是过于臃肿了，明明就是几个官方库升级的操作，没想到竟然会互相影响。真实的让人害怕！

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升级和我们项目的动态化部分也有所冲突，这里就不展开这个了，反正就是很蛋疼。

语法异常

另外在改造过程中还有些语法异常，这些就是有点蛋疼，大概就是下面这么几种类型把。改起来就比较简单，就是单纯的体力活了。

1. kotlin 升级导致的when else异常，只写了when没有else就会报错，直接会是编译异常。
2. smartcast 异常，一部分is 判断之后不会直接进行强制类型转换了。
3. 非空判断，原来有一部分判断语句中的?无效语法，现在直接变成error级别。

结尾

我个人觉得吧，工程一旦太大了这种基础组件的升级就会变得非常的蛋疼。而且最让我没想到的就是没想到abc之间竟然会互相影响，就让人有点措手不及，而且都是直接影响编译打包，疲惫。

另外就是compose 的设计竟然和kotlin版本强制绑定确实不是一件好事。分仓的工程在接入compose的时候尤其要慎重，升级尤其痛苦。

作者：究极逮虾户
链接：https://juejin.cn/post/7140808035823255560
来源：稀土掘金