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

·  阅读 2888

前言

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

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

Kotlin 1.7.0 正式发布!主要新特性一览

kotlin 升级引出来的一堆问题

我们masterkotlin版本是1.5.31,开发同学打算升级的版本是1.6.21,而kotlin官方最新版本是1.7.10,我想了想直接干最新的啊,一步到位岂不是美滋滋。

另外开发同学的另一个诉求是升级compose的基础依赖的,由于低版本的存在一个bug,必须升级版本才能修复。之前文章也介绍过compose的一部分实现原理是基于kcp的,那么也就导致了compose compilerkotlin版本强绑定在一起。所以就必然要让这两个的版本升级放在一起才行。而在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升级内容

image.png)

由于这个问题吧,我去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的时候尤其要慎重,升级尤其痛苦。

分类:
Android
标签:
收藏成功!
已添加到「」, 点击更改