Kotlin Multiplatform使用感受

KMP（Kotlin Multiplatform）是新兴的跨平台开发方案，通过Kotlin语法实现非UI逻辑共享，Compose Multiplatform解决UI跨平台问题。相比RN、Flutter等方案，KMP直接编译为原生代码，避免了桥接性能损耗，支持渐进式改造，既保持原生体验又能提高开发效率。在当前APP追求质量体验的趋势下，KMP为开发速度和产品质量提供了平衡方案，特别适合混合项目改造。

赵泓博

1503人浏览 · 2025-06-09 11:46:48

赵泓博 · 2025-06-09 11:46:48 发布

一、什么是跨平台？

1.1 跨平台概念

提到“跨平台”，必须要先理解“平台”的概念。什么是“平台”？

平台就是指应用程序运行的环境，如操作系统，运行方式等？

通俗的将，常见的平台有iOS、Android、HarmonyOS、浏览器、PC应用、后端服务等。

那跨平台是什么？

就是一个应用程序可以运行在上述各个不同平台，或者同一套代码编译成各平台可执行的程序运行包。

1.2 跨平台技术

市面上跨平台技术有很多，各有各的适用环境，这里不详细展开，只列举相关技术。

Flutter

Flutter是Dart语法，其性能上基本接近原生。但对于团队组成偏前端的项目来说有很高的学习成本，其独有的语言使其在和原生对接的情况下有跨平台通讯开销。如大量的flutter三方插件，内部会在Android和iOS平台各实现一套原生代码，通过channel进行通讯。

React Native

RN是facebook开发的，技术实力比uniapp是强大很多，在目前KMP刚出道的情况下，选择RN是大厂的必然。但从技术上JS到Native之间的通信开销比较高，导致交互的流畅性受损，这是js和原生之间的本质问题导致。

Uniapp

Uniapp是当下小团队特别流行的开发模式，其作用是让前端js开发人员快速打包出Android和iOS平台包，如果同时需要小程序和网页端那更是再适合不过了。不过打出的Android或者iOS包分析其UI渲染层级，发现基本是网页组成，其使用体验上差了很多，这方面比着RN和Flutter差了很多。如果是想打磨一款性能优越使用体验丝滑的产品，建议不要选这种方式。

Kotlin Multiplatform

KMP/CMP是Jetbarains公司推出的跨平台解决方案，用Kotlin语法写出不同平台运行包。KMP负责业务逻辑，CMP负责UI，其中CMP是基于Google Android平台的Jetpack Compose为核心进行扩展，是和Google的深度合作项目，在今年Google IO开发者大会上，Google明确未来全力支持Compose的发展。

二、为什么选择KMP？

技术选型上，如果不差钱和资源，当然纯原生开发是最好的，性能和产品体验也能达到丝滑，不然swiftUI还推出干嘛。但对于大多数企业来说，节约成本和资源消耗要尽可能平衡。

2.1 Kotlin Multiplatform（KMP）

MMP负责非UI部分的跨平台。个人对老项目进行改造，把纯业务逻辑部分提取到kmp模块中，然后依赖到Android、iOS、Server、Web平台，发现运行正常，流畅度不受任何影响。这给了我很大惊喜，作为大前端全栈来说，同样的网络请求，同样的数据结构，同样的很多内容都要写两遍，感觉时间在浪费。而用KMP改造后，只需要用跨平台网络请求扩家ktor就能运行在两个平台，刚好解决了我的诉求。

2.2 Compose Multiplatform（CMP）

CMP负责UI部分的跨平台。个人把老项目首页用Compose进行重写，然后嵌入Android和iOS平台，效果和原生一模一样，运行丝滑体验一点不差。以前每次开发新功能都要在iOS上用swift/swiftUI写一遍，然后在Android上用kotlin/compose写一遍，感觉同样的人生体验了两遍，非常苦恼。更要命的是，一个Bug要改两次，并且swiftui和compose都是响应式语法结构很相似，用CMP成功解决了我的难题。

三、未来前端技术思考

3.1 技术融合趋势

在资源有限的情况下，所有团队都在追求跨平台，期望同样的人力同样的代码可以运行在所有端，这样在技术人员有限的情况下，可以尽可能满足所有端开发需求。而RN、Flutter、Uniapp都在进行尝试，各有优缺点吧。

但从另外角度来说，现代项目越来越趋于混合型开发，就是一个项目中包含了Android/iOS原生、vue3、flutter、js、react等，不断提高项目复杂度，但也更加灵活。这时候，把项目各部分解耦就显得非常重要。

以React Native、Uniapp为首的js平台，通过JSBridge进行通讯的方式已比较成熟，但由于其性能上和原生有一定差距，对于打磨一款丝滑体验的产品来说不是首选，但放在非核心位置来说，还是可以满足大部分场景需求的。

Flutter嵌入原生Android/iOS，通过消息通道也是可以正常使用，并且有大量成熟的三方库提供支持。但混合开发依然有通讯成本开销，虽然性能上和原生没有明显的差距，但在大量计算和数据处理的时候就显得有点吃力，毕竟是通过桥接方式进行链接的。

而KMP不是通过桥接实现，而是直接编译成对应平台可执行代码，相互之间代码直接引用，可以说KMP就是原生开发。令人惊喜的是，KMP可以渐进式改造，在混合型项目开发中显得尤为重要，一个没有跨平台通讯成本的跨平台框架谁不喜欢呢？

另外，KMP移动端开发，能做web端和ServerAPI的事，何乐而不为呢？

3.2 产品质量和用户体验提升

当前大量的APP使用uniapp进行开发，但使用体验上得不到用户认同，只能评价说功能可用，没有任何体验可言，并且一些莫名奇妙的问题，如白屏、卡顿、跳转错误、无响应等质量低下。在当下APP开发热度降低，逐渐淘汰低效应用的背景下，提高产品质量和使用体验才能留住用户，这就提高了APP质量和使用丝滑度的要求。