「KMM」、「KMP」?他们到底是什么?

Kotlin Multiplatform is a technology that allows you to create applications for various platforms and efficiently reuse code across them while retaining the benefits of native programming. Your multiplatform applications will work on different operating systems, such as iOS, Android, macOS, Windows, Linux, and others. —— kotlin官网

以上是Kotlin Multiplatform官网上对于KMP的简要概括,翻译一下,就是

Kotlin Multiplatform 是一种跨平台技术,它允许您在不同平台上高效的重用代码的同时保留不同平台的代码优势。使用KMP编写的程序可以在不同的操作系统上运行,例如iOS、Android、macOS、Windows、Linux等”。

image.png

KMM?KMP?

KMM(Kotlin Multiplatform Mobile)KMP(Kotlin Multiplatform)实际上是指同一个概念在不同范围的应用。Kotlin Multiplatform是一个更广泛的术语,而Kotlin Multiplatform Mobile专注于移动开发

Kotlin Multiplatform (KMP)

Kotlin Multiplatform是一种编程技术,允许开发者使用Kotlin语言编写跨平台代码。这意味着你可以用同一套代码逻辑同时运行在多个平台上(如JVM、JavaScript、iOS、Android、Linux、Windows、MacOS等),而不需要为每个平台重写逻辑。

KMP的目标是实现业务逻辑或非UI相关逻辑的共享,以减少重复代码和提高开发效率。对于UI部分,通常还是需要使用各个平台的原生技术或其他跨平台框架。

KMP的应用范围非常广泛,包括但不限于移动应用开发。它也可以用于Web开发、服务器端开发、桌面应用开发等。

Kotlin Multiplatform Mobile (KMM)

KMM是Kotlin Multiplatform在移动开发领域的应用。它专注于使用Kotlin编写可以在Android和iOS平台上共享的代码。

与KMP的差异主要体现在使用范围上,KMM专门针对移动平台,即iOS和Android(也许,maybe未来也包括鸿蒙?)

Kotlin Multiplatform(无论是KMM还是更广泛的KMP)提供了一种高效的方式来共享跨平台代码,同时允许开发者为每个平台提供最佳的用户体验,如果你的项目只涉及到iOS和Android应用的开发,KMM是一个很好的选择,因为它专为这个目的设计。如果你希望在更广泛的平台上共享Kotlin代码(如Web、桌面或服务器端),那么KMP会是更适合的选择。

受命于天,既寿永昌:谁才是跨端正统?

打盘古开天辟地以来,人类对统一一直有一种莫名的执念:非我族类,其心必异。所以历史上各路英雄疯了似的都要统一天下。
前端开发亦是如此:明明都是UI切图仔,为何还要区分出Android切图仔iOS切图仔web切图仔…为了达成一统天下的目的,前端历史上也是英雄辈出:React NativeWeexFlutter以及我们此次要讲的KMM(KMP)

一个国家,三个政府,这难道不是分裂,不是对孙先生的背叛吗?—— 《建军大业》

下面的表格列举出了几个主流的跨端方案的差异性:

特征/技术 Weex React Native Flutter Kotlin Multiplatform (KMP)
开发者/维护者 阿里巴巴 Meta (前Facebook) Google JetBrains
技术栈 Vue.js, JavaScript JavaScript, React Dart Kotlin
UI渲染 原生组件 原生组件 自绘UI(通过Skia) 依赖于平台
性能 接近原生 接近原生 高(性能更优) 取决于平台,逻辑部分高效
跨平台范围 iOS, Android iOS, Android, Web (部分支持) iOS, Android, Web, Desktop, Embedded iOS, Android, Web, Desktop
学习曲线 适中,需要了解Vue.js 适中,需要了解React 较陡峭,需要学习Dart语言 适中,对Kotlin开发者较为友好
社区和支持 适中 强大 强大 增长中
用例 适合阿里生态圈内的项目 广泛的应用场景,尤其是需要快速迭代的项目 适合高性能和高度定制化的UI设计的应用 适合逻辑重用,跨多平台共享业务逻辑

其中React NativeFlutter成名已久,也算是跨端方案两种实现思路的代表:

  • React Native为代表的使用平台的原生组件来构建UI。这就意味着它需要讲JavaScript代码桥接到原生代码,使用原生控件来渲染界面。这种方法可以提供接近原生的性能和外观,但可能会受限于框架对原生组件的支持。与之类似的还有Weex
  • Flutter为代表的使用自己的渲染引擎绘制界面、构建UI。这种方案由于避免了桥接开销,通常可以提供更好的性能,使得动画和过渡更加平滑,响应更快。与之类似的还有Compose Multiplatform

React Native虽然号称可以实现接近原生的性能,但由于其天然存在的桥接机制(JavaScript与原生代码之间的通信),对于一些要求高性能的应用或复杂动画,React Native可能无法与原生应用相匹敌。
同时,尽管React Native旨在支持跨平台开发,但在实际开发中,仍然可能需要编写平台特定的代码来处理不同操作系统之间的差异。这可能减少代码复用率,增加开发和维护成本。

至于Flutter呢,性能上倒是和原生没有太大差异,对于那些不熟悉Dart语言的开发者来说,Flutter可能有一定的学习曲线。虽然Dart设计为易于学习的语言,但它并不是什么大众性的语言。开发者往往需要额外的时间和资源来学习Dart语言及Flutter框架。

同时,虽然Flutter努力提供丰富的插件来支持各种平台特定功能,但新的平台功能或较少使用的功能可能没有现成的插件支持,这些也需要开发者自行编写原生代码并创建桥接逻辑,无疑增加了开发的复杂性和时间成本。

什么?你问我「Weex」?

大人,时代变了,大清亡了啊!Weex的Github最近的一次提交是在23年8月份[/哭]

「KMP」新王当立?

更细粒度、渐进式的跨平台

image.png

与传统的Flutter or React Native方案不同,KMP对于跨平台代码的粒度更加精细,允许开发者 渐进式 的完成跨平台,按代码的重用程度不同分为3种:

  • 共享部分逻辑层代码

在保障app的稳定性的前提下,将部分关键且独立的逻辑层代码进行共享,使其能在不同的平台上重用这部分的代码。这种方式适合现有项目向KMP的迁移,最大程度的保证app的稳定性。

  • 逻辑层代码完全跨平台,UI层代码保持平台独立性

逻辑层代码完全实现跨平台,但是UI部分的代码保持平台独立性。这种模式比较适合新项目,没有历史债务,从新开始。

  • 逻辑层和UI层完全的跨平台,即代码100%重用

跨平台项目的完全体,UI部分使用Compose Multiplatform来完成跨平台达到重用代码的目的。
使用Compose Multiplatform编写的跨平台项目

性能有保障的跨平台

通过KMP跨平台而共享的代码,最终会被编译成对应平台的二进制文件。

什么意思呢?我们使用Kotlin写的跨平台的代码,最终编译生成的,不一定是.class文件了,可能是js文件、.exe、.framwork…等等都有可能 —— 这取决于目标平台。

这个特性天然就决定了KMP的性能相对于React Native和Flutter更好。理论上KMP生成的代码和原生代码在性能上应该别无二致。

image.png

说的天花乱坠,都谁在用KMP?

官网上列举了很多案例:

基本上以国外公司为主,不过据我所知,国内的很多公司也已经在生产环境上尝试KMP,像小破站莉莉丝美团等。

Google也一直在加大对KMP的支持力度,早在2022年10月份就宣布了Jetpack开始支持KMP了:

Announcing an Experimental Preview of Jetpack Multiplatform Libraries

Jetpack开始支持KMP

所以对于KMP的社区生态或者说是开发体验上,我是保持着相对乐观的态度:背靠Google以及最会做IDE的Jetbrains,我相信KMP的生态不会差,时间问题罢了。

该不该使用KMP?

开源的世界百家争鸣,但是落到实处往往也是成王败寇。作为开发者,做技术选型就更需要慎重再慎重了。
如果你有跨平台的诉求,我认为KMP当前值得推荐。

作为一个Android开发者、Kotlin语言的使用者,Kotlin、Compose本身就很熟悉,使用KMP几乎没什么学习成本和门槛,跨平台的能力简直算是白送的。即便不熟悉Compose,我们也可以使用KMM写一些UI无关的、逻辑层的代码,共用逻辑层,达到跨平台的能力。比如使用KMP做埋点数据上报。

至于跨平台是不是伪需求,我觉得应该高瞻远瞩一下。现有主流的移动端平台只有iOS和Android,加上未来的「鸿蒙」呢?之前一套逻辑iOS和Android平台上写两次,现在加上鸿蒙写三遍么?即使你能忍,公司能不能忍呢?KMP对人效的提升和逻辑的统一性我觉得是无需质疑的。

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

0%