试用kotlin multiplatform

目录

多平台框架简介

示例工程建立与运行

常用库

桌面平台遇到的一些问题

使用总结


多平台框架简介

多平台的框架不少,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跟进的好像不多.

相关推荐
dme.7 分钟前
Javascript之DOM操作
开发语言·javascript·爬虫·python·ecmascript
teeeeeeemo12 分钟前
回调函数 vs Promise vs async/await区别
开发语言·前端·javascript·笔记
加油吧zkf17 分钟前
AI大模型如何重塑软件开发流程?——结合目标检测的深度实践与代码示例
开发语言·图像处理·人工智能·python·yolo
ejinxian32 分钟前
PHP 超文本预处理器 发布 8.5 版本
开发语言·php
福柯柯38 分钟前
Android ContentProvider的使用
android·contenprovider
不想迷路的小男孩38 分钟前
Android Studio 中Palette跟Component Tree面板消失怎么恢复正常
android·ide·android studio
餐桌上的王子40 分钟前
Android 构建可管理生命周期的应用(一)
android
菠萝加点糖44 分钟前
Android Camera2 + OpenGL离屏渲染示例
android·opengl·camera
用户2018792831671 小时前
🌟 童话:四大Context徽章诞生记
android
软件黑马王子1 小时前
C#系统学习第八章——字符串
开发语言·学习·c#