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