共计 1290 个字符，预计需要花费 4 分钟才能阅读完成。
因为看到谷歌在近期大力推广 Jetpack Compose 进行 Android 开发，下意识联想到目前正火的 Flutter。之前理解到 JetBrains 有推出基于 Jetpack Compose 针对桌面平台的图形界面解决方案 JetBrains Compose for desktop。出于对两种跨平台计划的抉择艰难，明天就大略钻研了一下两种计划之间的区别，当然要提一句，受限于自己的技术水平和对两种技术的理解，文章仅示意自己的大抵了解和剖析。
如果你理解过 Flutter 相干的常识，就会理解到，Flutter 屏蔽了不同操作系统底层的图形界面 API，间接利用 skia 引擎进行图形界面的绘制，相似于提供一个能够在各个平台上运行的画板，让你在下面作画，因而可能做到同一套 UI 代码在全平台都能编译出现同样的成果，正当应用某些包和插件甚至能够进行小局部跨平台的简略业务逻辑的开发。同样的，Compose 的图形界面绘制局部也是由 skia 引擎实现。本认为和 Flutter 一样，是同一套代码跨平台绘制，然而浏览 Compose 在 Github 上开源的示例代码后，我发现并非如此。应用 Compose 开发须要为每个平台的主图形界面局部独立地编写代码，例如在 Android 上是绘制 Activity，而到了桌面零碎就要绘制 Window，因而其通用局部仅是业务逻辑以及内容组件局部，如解决逻辑、按钮、图片视图之类。这样做尽管减少了图形界面的编写老本，但其益处就是能够调用每个平台不同的图形界面本地个性，在 Android 上能够应用长按来呼出上下文菜单，到了 desktop 就能够转而应用右键监听事件，能够在保障业务逻辑编写一次的状况下还具备针对不同平台进行布局和操作逻辑解决的灵活性，而这一点 Flutter 自身就很难实现，其须要用到第三方开源库 NativeShell 来调用桌面环境下独有的 API，远不如 Compose 来的灵便，并且该库目前还处于试验期，将来的倒退很难预测。当然，你也能够通过 FFI 来应用其余语言对接不同零碎的特定 API，然而这就失去了跨平台的能力。
在应用过程中，我还发现 Flutter 在桌面端对 hidpi 的反对比拟好，可能随零碎设置一起正确缩放，然而 Compose 目前在 Linux 上还不能正确缩放，包含 Wayland 和 X11 都不行，在 4K 屏幕上图形界面元素会变得十分小。
综上所述，目前两者都应用 skia 引擎进行绘制，但区别是 Flutter 属于一个画板，你能够用 Dart 在下面任意画画，但实现其余大部分性能须要应用 Dart 或者进行 FFI 调用，然而 Dart 的生态比起其余语言来说切实是顾此失彼，因而个别仅用来进行图形界面的编写，而且进行图形界面编写的时候多层嵌套经常令人头痛；Compose 则属于一套工具箱，外面有针对各个平台的各种工具，而后也有一个画板，驱动工具箱中所有货色的形式为 Kotlin，而 Kotlin 背靠弱小的 Java/JVM 生态，领有用不完的工具库以及近乎变态的跨平台发展势头（iOS 除外），但目前还处于 Alpha 阶段。
因而通过比拟，我集体更偏向于学习和应用 Compose，也心愿这篇文章对你的抉择有所帮忙。
