近期正值I/O大会与2025年之际，KMP社区重新焕发生机。在此之前，KMP的现阶段版本已对众多开发者而言足够成熟，尤其在和iOS领域，得益于额外支持，其可用性已不再是障碍。

大家普遍关注，当前有哪些公司正在应用KMP技术，亦或是国内有哪些企业正在采用？在这方面，美团平台上的项目“kmp-case--cn”已经呈现了一些实际应用的案例。

此外，在相关官方案例集中，也呈现了百度、美团以及B站的对应实例：

甚至在 2025 上，B站也是 C 位展示：

在本次I/O大会上，官方透露，自去年起便开始测试KMP技术，目前该技术已在iOS平台的Docs应用中得到应用，观察下来，App的运行时性能相较于之前有了显著提升。

经过长时间的携手合作，我们终于让自家产品得以融入了KMP技术。

那么，或许众人会疑惑，KMP 看起来相当不错，但如今运用 KMP 是否还会遭遇困境？我只能说：

一般不会有什么问题，因为有问题的时候也不是一般人能解决。

当然，存在一个较为特殊的情况，那就是KMP与大家所熟知的版本存在一定区别，尤其是在和iOS这两个平台上，这种差异尤为显著。毕竟，一个是基于Java虚拟机（JVM）的，而另一个则是基于其他技术架构的。

众所周知，该平台最为卓越的是其编译器功能，因此它能够支持包括/JVM、/、/S、/Wasm在内的多种编程语言，尤其在iOS平台上，它选择了特定的技术路径。

选择该方案，自然也是看中了其优越的性能表现，毕竟在 iOS 系统上运行一个支持 JIT 的虚拟机似乎并不现实。

实际上，JIT 在 iOS 平台上的运行路径，已经有过企业的实际测试。例如，那些从事热更新工作的企业，它们在早期就已经在 iOS 上对类似 JIT 的运行机制进行了测试，但发现效果并不理想。

JIT模式下的性能未必出色，尤其是在debug模式下，性能体验相当不佳。实际上，导致运行缓慢的根本原因在于框架中存在大量的一致性检查和断言，而这些会显著降低性能的检查和断言仅在debug模式下被激活，这才是导致运行缓慢的真正原因。

JIT模式的一大特点在于其预热需求，因此程序在达到最佳性能状态时可能需要耗费较长时间，并且会占用更多的内存资源。然而，从理论上的峰值性能来看，JIT模式实际上并不逊色于AOT模式。

在iOS系统上，KMP作为非本土应用intellij idea 2025，其采用即时编译（JIT）与Skia图形库的性能表现必然面临一定的局限。

AOT的优势在于其启动速度极快，无需经过预热即可发挥最佳效能，这使得AOT在UI应用场景中尤为适用，因为UI界面无法忍受JIT编译的不可预知性以及预热所需的时间。

这同样是目前较为常见的问题之一，KMP 在 和 iOS 平台上的支持或许存在某种“隐秘”的不匹配现象。尽管它们的前端（负责代码解析、名称解析以及类型推断等任务）与 JVM 的编译器是共通的intellij idea 2025，然而在对应的后端部分，即针对 LLVM 位码生成的处理上，却有着截然不同的实现，从而导致了一些令人费解的差异。

KMP 针对 KN 在 iOS 提供了一套标准库支持。

在2.1部分，对特定函数的行为进行了规范统一。这是因为在此前，该函数在遇到极端情况时，其表现与操作系统和JVM存在差异。这种差异产生的原因在于：内联操作在不同平台上的不同部分发生。

import kotlin.reflect.*

class Pair<A, B>(val x: A, val y: B)

inline fun <reified T1> typeOfX(x: T1) = typeOf()
inline fun <reified T2, T3> typeOfPair(x: T2, y: T3) = typeOfX(Pair(x, y))

// returns "Pair" in K/Jvm
// returns "Pair in K/N
fun test() = typeOfPair("1", 1).toString() 

这也就是为什么在2.1版本之前，该隐性问题在JVM和K/N中显现出了微小的不同之处：

而 JVM 以及它带来的区别还表现在多个方面，比如最初在 5.0 版本中，开发团队计划加入对 / 的支持，这包括 /，但这一计划最终被取消，原因是维护团队发现无法在 / 上利用现有的 HTTP 客户端引擎，而且团队也尚未准备好为 / 特别开发 TLS API。

自然，也有属于自己的Ktor，因此无需过分担忧，这并非什么严重的问题。当然，即便如此，小问题可能还是存在的，也许你同样需要使用Ktor。

image-

Ktor 3 对内核进行了显著优化，实现了I/O性能的显著增长，增幅高达三倍，同时增强了配置方面的支持，并引入了诸如-sent等新特性以及多项支持功能。

此外，诸如对反射的辅助功能相当有限，其内省机制主要涵盖诸如`cast`和`Class`等基本信息，然而，对于全面内省功能，诸如展示成员（.）、构造函数（.）、嵌套类（.）、超类型（.）等，通常仅限于JVM的默认支持，当然，这些功能也不包括`Class.`的具体实现。

此外，GC（垃圾回收）方面存在显著的不同，但通常这些差异对包的开发者并无大碍；即便对你产生了影响，你也难以改变这一状况。

在相应模式下，代码运行时成为了一个自主的本地可执行文件，无需借助虚拟机环境。它独立管理内存资源，并具备独立的内存架构以及垃圾回收机制，这些特点不仅彰显了其与JVM后端架构的不同，同时也揭示了其与iOS平台在后台支持方面的差异。

此外，作为AOT，它对内存的消耗相当大；在之前的KT-77683报告中，就有提及，当使用CMP iOS时，AS的内存占用达到了38G。

这主要是因为在iOS的整个构建工具链中，包括编译器、LLVM以及Xcode构建系统组件，它们本身就存在内存消耗较大的问题。特别是由于的AOT编译过程，它需要对整个代码库进行深入分析，并将其转换成原生代码。

在iOS设备上，若您的电脑内存不足，便可能频繁遇到：Java堆内存不足的问题。

最终，众多大型企业开始采用 KMP 技术开发鸿蒙系统，其中主流的路径包括 /JS 和 /。然而，例如 B 站这样的平台，由于 /JS 性能上的不足，最终选择了转向 /。

采用  /  能够带来更佳的性能，然而其兼容性成本相对较高。这是因为，在鸿蒙系统中，我们必须借助 llvm 来提供支持。具体来说，直观的问题在于，KMP 官方对 llvm 的更新速度相当快，例如当前已更新的 llvm 16 以及即将到来的 #KT-75829 llvm 19。然而，目前鸿蒙平台所使用的仍是 llvm 15。

若您打算提升iOS系统的兼容性，抑或采用Swift编程语言，那么您必须权衡是坚持iOS系统还是维护鸿蒙平台。

Swift 的首个试验性版本预计将在 2.2.20 版本中亮相，其主要目的是解决先前存在的纯 Swift 互操作性不足的问题，以及在使用 -C 桥接时，Swift 泛型所受的限制。

暂时看性能还有点问题，但是前景是好的。

说了诸多问题，让我们转换话题，谈谈积极的一面：Amper，这一实验性的构建工具和JVM构建工具，旨在简化项目的构建配置，并增强用户体验以及IDE的支持。需要注意的是，它的主要目标是优化用户体验，而非打造一个全新的独立构建工具。目前，它仍有所依赖，至于未来能否完全独立，目前尚不可知。

此外，/Wasm 已经历了一系列的优化，包括更高效的增量构建过程、更紧凑的二进制输出文件以及提升了的开发者使用感受；据悉，/Wasm 与 for Web 的组合版型预计将在本年度的后期阶段推出 Beta 版本。

image-

紧随其后，我们迎来了全新的KMP插件，它使得在集成开发环境（IDE）中构建新的KMP项目成为可能，同时，用户可以选择使用原生用户界面或者共享用户界面进行操作。

自从 Fleet 被舍弃作为 KMP 的专用集成开发环境之后，官方终于走上了正确的道路。现在，对于那些需要同时运用 和 Swift 的项目来说，IDE 中已经可以支持跨语言的导航、语法的高亮显示、快速查阅文档以及调试功能。

image-

IDEA已经为iOS提供了调试功能，而IDEA中的这一支持将会稍后推出。

目前插件仅适用于获取 IDEA 2025.1.1.1 及 2025.1.1 版本，并且目前仅限于 macOS 系统，而针对 和 Linux 的支持正在开发中。

需要启用 K2 模式 。

最终，该工具正在向更多开发平台拓展——包括官方语言服务器插件和针对特定环境的新扩展正在积极开发中。尽管目前尚处于初级阶段，但已实现了对代码自动补全、代码导航、错误检查、快速修复、Java语言交互以及基础项目导入等基本功能的支持。预计将在今年稍晚时候推出Alpha测试版，而对于KMP的支持则可能要推迟至之后。

最后

目前看来，在客户端开发方面，KMP 依然是被广泛推荐的选择。之前提到的问题并非是让你放弃，而是为了让你心中有数。通常情况下，大多数人并不会遇到太多难题。至于是否采用 CMP，则各有所见。在国内，KMP 在大型厂商中的应用较为普遍，而 CMP 的使用率相对较低。使用 CMP 需要更高的技术积累，尤其在适配鸿蒙系统时成本更高。因此，我个人更倾向于推荐 KMP。当然，如果你希望在生产环境中寻求更稳定的方案，CMP 或许是一个不错的选择。

那么，2025 你准备好 KMP 了么？

参考链接

如有侵权请联系删除！