当前位置：首页 > news >正文

试用kotlin multiplatform

news 来源：原创 2025/5/4 3:26:25

多平台框架简介

示例工程建立与运行

常用库

桌面平台遇到的一些问题

使用总结

多平台框架简介

多平台的框架不少,flutter,rust,每一个都是优点明显,缺点也明显.

flutter的桌面端控件少,质量不一.dart语言丑陋又慢.我不喜欢它.

rust,桌面gui不成熟,成熟一些的slint还是授权和qt一样,同一个团队部分成员做的.移动端更不用说了.难有大企业在支持

tarui,主要是桌面,可是也基于webview,试用了一下体验不好.

lua,支持多端,koreader是比较有名的,剩下估计用的不是太多,移动端的体验我觉得一般.本身也没有一个团队去推动多平台这事.

electron,移动端没有,桌面端主要受限于性能与进程,系统方面,体积也不小,用的人是有,也占不上主流.

windows端,gui成熟,多平台,暂时没发现有大的app在用c#,只是我没有发现.游戏开发用c#倒有不少人.

qt,授权是一个问题,相对较老了,算有商业团队支持.

kotlin的compose.自从jb出了这个以后,开始是吹的挺火的,但现在官方文档已经很少提桌面端了,只有移动端的示例,桌面的jni或调用native的库示例都没发现一个.ide的支持有时还不能识别出项目运行项.创建工程时,也没有桌面选项,猜想是想弱化吗,集中办移动端.

但本着对compose还有些了解与使用,试用一下.看看效果,现在移动端主要语言多数企业都是kt居多了.但compose用的多不多这个不了解,可能还不如flutter多.

示例工程建立与运行

从jb网站上下载了一个工程,对它的ide没办法建,但官网倒是有一个建工程的网站.Create your Kotlin Multiplatform app | Kotlin Multiplatform Development Documentation

然后composeApp目录下存着几个平台的代码,如果有选了ios,则在同级别的目录有一个iosApp,就这个工程模板都改了几次了,现在桌面的叫desktopMain,以前叫jvmMain.

我选了shared,就是主要共享代码,包括ui也使用一套,那么commonMain目录下主要存储着共享的部分.

androidMain/iosMain/desktopMain下面存着不同平台的入口.

对于每一个平台的依赖都是自己弄的.这也好.

如果用idea,安装一个compose multiplatform插件,as也装,但as无法正确运行桌面app,只有新建配置项,里面run里面gradle命令写上:desktopRun -DmainClass=com.archko.reader.kreader.MainKt --quiet

其中MainKt就是指向你自己的入口名.

下面的工程选中composeApp就可以跑起来了.idea在Main.kt文件打开,有一个run标志也可以跑,或者顶部运行栏的.current file点击run就可以运行起来了.

图片就不发了

常用库

Kotlin Multiplatform samples | Kotlin Multiplatform Development Documentation

官方示例的文档,里面列出示例.

多平台,共享代码,决定了原来android平台上的一些java代码,库是无法使用的.所以几乎都要重写一套,网络,数据库,等等太多了,这不是一个人可以完成的,工作量也非常大.

kotlinx-serialization
kotlinx-datetime
kotlinx-coroutines
play-services-maps
play-services-locations
android-maps-compose
accompanist-permissions
decompose
koin
jsonpathkt-kotlinx
horologist
google-cloud
firebase
bare-graphql
apollo
accompanist
ktor
koin
exposed
postgresql
sqldelight
awssdk
ktor-client
molecule
decompose
horologist

这些库是几个示例中用到的,通常已经覆盖了一个多平台app的主要方面了.网络,数据库,序列化,时间,等等.但对一个现有的app,这些当然还远不够,自己公司的依赖还有一堆.第三方的也有不少.要么写一套多平台的依赖库,共享部分工作量就少,要么就是共享部分的代码放到不同的平台去实现.

`桌面平台遇到的一些问题`

比如我熟悉的,pdf阅读器,android平台就有系统的,mupdf这些实现.而其它平台只能找jvm上能跑的,或是js可运行的.

kotlin compose在桌面平台上是依赖skiako,就是skia基于kotlin的封装实现,这是一个成熟的图形库了,依赖要下载一个包,解压后达到1个gb多点.

理论上,在mac,linux上都是基于jvm跑的.依赖java代码也能跑.

移动平台当然差别就大了.ios需要编译为native,这个差异大多了.很难在上面可以编译进java代码进去.

第三方库,同时实现不同平台的库,目前没有关注到,比起flutter肯定是要少的多.flutter控件质量虽然有好有坏,总体还算能用.

由于没有找到桌面端如何加载dll,dylib这些库的示例,放弃了,就当作当前无法调用.所以只能用一个演示用的demo.

资源不是R.,而是Res.资源,bitmap也是对应imagebitmap,这对于android开发人员来说,很容易熟悉,本来就是java那套.ios开发人员估计也不会去用这个.

其它ui部分,主要还是compose的,布局,状态这些,如果熟悉compose移动端开发,多数代码是直接使用的.

使用总结

对于android开发人员,尤其熟悉compose的较友好.迁移工作量小

对于ios开发人员没什么吸引力.

完整的app依赖库方面,太少.需要自己实现,缓存,工具多数是要自己实现的.

比flutter在多平台方面要写的代码要多一些,kotlin语言我觉得是远胜dart的.

基于m3的设计,主要是compose这套ui的功劳.

移动优先的策略估计还会持续下去,对多端统一代码的需求,大企业未必多,更多是小企业节省人力的退而求其次选择.玩玩就可以,做一些不复杂,没有特别api的应用倒是可以,一方面美观(相对swing)来说,另一方面省力.毕竟新设计的库很多之前的缺点都考虑到了.这点flutter也可以做到.

官方文档目前主要是英文.变化还挺快.大公司app跟进的好像不多.

多平台框架简介

示例工程建立与运行

常用库

桌面平台遇到的一些问题

使用总结

相关文章：

`桌面平台遇到的一些问题`