渲染内存降95%、GC卡顿率降90%：KMP 是怎么在鸿蒙上跑起来的

回顾移动开发的历史，跨平台的需求几乎和移动应用本身一样古老。

PC 时代，用户在浏览器里输入一个 URL 就能跳转到目标页面，开发范式简单直接。后来乔布斯推出 iPhone，因为早期手机性能有限，原生 App 成为承载移动体验的重要方式。为了吸引开发者入场，苹果发明了 App Store。更准确地说，是 App Store 首页上那个小小的图标。

这个图标对开发者的吸引力极大，原因并不复杂：拥有一个入口按钮，意味着开发者第一次掌握了自建流量的能力，于是大量开发者和企业开始进入移动应用生态。

随后，Android 兴起，行业从相对统一的 PC、Web 时代，逐渐进入 Web、Android、iOS 多端并存的阶段。

问题也随之而来：一个应用要同时覆盖 Android、iOS 和 PC，意味着几套代码、几个团队、和几倍的成本。开发者开始怀念"写一套代码到处跑"的高效时代。

Facebook 率先给出了自己的答案，把 React 的开发范式搬到移动端，这就是 React Native。但随着应用复杂度上升，React Native 的性能问题逐渐显现。

与此同时，Google 内部一群做 Chrome 的顶尖工程师也在思考同样的问题。他们发现 Chrome 在移动端的性能表现很差。PC 端硬件强劲，Chrome 可以堆功能、强调并发能力。但移动端的 CPU 资源极其有限，Chrome 那套为 PC 设计的架构在手机上水土不服。具体表现为：长列表滑动时跟手性还行，但白屏频出。这在 Web 端不算什么，在移动端就是 Bug。

于是他们决定重构整个渲染管线。核心思路是：从强调并发能力，转向一条精简的渲染流水线，强调即时渲染，内容要立刻出来，不能等。由于渲染链路更短，出现问题时也更容易定位。

Flutter 还有一层更深的战略意图，Google 的生态嗅觉一向敏锐，在为未来的 AI 和 IoT 设备做准备之外，Flutter 的推出也意在发展开发者生态。至于 Flutter 的另外一重使命，就是要统一多端的 UI。这也是其在国内风靡一时的原因。

另一条演进路线来自 Android 自身。2018 年，Jetpack 推出，改善了传统 Android 开发中 XML 与 Java 代码混杂、开发方式相对粗糙的问题，并提供了 Lifecycle 等更加完整的工程能力。2021 年，Jetpack Compose 推出，声明式 UI 从 Web 进一步进入移动原生开发，SwiftUI 也采用了类似的声明式范式。

在某头部互联网公司内部，Compose 刚推出时开发人效就有 1:1.6 的提升，一个人能干 1.6 个人的活。当然那时 Compose 还不太成熟，性能问题不少。

到了 2023 年，KMP 开始受到更多关注。如果说 Flutter 的核心是统一 UI，那么 KMP 的核心就是统一业务逻辑。这也代表了跨平台框架的又一次代际变化。

Flutter 的关键技术是自渲染。开发者使用 Dart 编写一套代码，便可以运行在 Android、iOS 和 Web 等平台上。此后，Flutter 又引入 Impeller，以更现代的 GPU 渲染方式逐步替代 Skia，并利用 Vulkan 等图形接口改善渲染性能。

Dart 在国内的接受度相对有限，因此不少团队尝试将 Flutter 的开发语言替换为类 TypeScript 或 JavaScript 语言，例如腾讯的 MXFlutter。行业中甚至一度有一种观点：如果 Flutter 使用 JavaScript，它可能会成为更加理想的跨平台框架。

Flutter 未来可能会面临生态变化，但它所代表的自渲染技术路线不会轻易消失。框架可能退潮，具有独特价值的底层技术却会被保留下来。

KMP 与 Flutter 的设计理念不同。Flutter 试图统一 UI，KMP 则更加关注共享逻辑，这种差异主要体现在架构模式和交互性能两个方面。

在 Flutter 中，如果需要调用原生能力，通常要编写 Platform Channel。随着业务复杂度上升，一个图片库、网络库或其他组件可能对应大量通道代码，整体粒度偏粗。跨端与原生之间还需要进行序列化和反序列化，在高频交互场景中容易产生性能损耗，甚至引发卡顿。

KMP 引入了 Expect/Actual 机制。公共层可以声明统一接口，各平台再提供具体实现，其复用粒度既可以很粗，也可以细化到函数和属性。这样既能提高开发效率，也能保留调用平台原生能力的灵活性。

在性能方面，KMP 可以直接调用平台 C 接口，直接生成各平台原生二进制代码，性能可能获得数倍甚至接近两个数量级的提升。

因此，KMP 的下一代特征主要体现在两点：一是提高共享逻辑的开发效率，二是降低跨端逻辑与原生平台交互的成本。

KMP 在海外的应用规模一度并不算大，但在国内，越来越多大型企业开始押注 KMP，其中一个重要原因是鸿蒙生态的崛起。

当企业需要同时维护 Android、iOS 和鸿蒙三端时，很难再为每个平台分别扩充一支完整团队。尤其在成本压力较大的情况下，企业希望通过跨平台框架解决新增平台带来的研发投入问题。

从业务模式看，一个大型移动应用通常可以拆成三个区域：

性能域 ：与业务强相关、出问题损失大的场景（如购物应用从首页到购物车到下单），需要高性能和高稳定性，一般用原生或 KMP；

动态域 ：种草类页面，运营和产品希望今天设计方案明天就能上线，对性能要求不高但要求高动态性，一般选 Lynx、Weex 等类 RN 框架；

开放域 ：航母级 APP 希望用户所有时间都停留在自己生态内，通过支付宝小程序、微信小程序等方式接入第三方。

过去，性能域往往只能选择原生开发，因为业界缺少真正成熟、可落地的高性能逻辑跨平台框架。

从语言角度看，C++ 的内存管理门槛较高，Rust 的学习曲线较陡，JavaScript 和 Dart 的性能上限又相对有限。Kotlin 和仓颉在语言性能上具有一定潜力，但当时也各有短板：Kotlin 在 Android 上生态强大，在 iOS 和鸿蒙上的基础设施仍不完善；仓颉的运行时和性能表现不错，但生态尚处于早期阶段。

某个头部应用曾计划两年内把跨平台框架占比从 45% 提升到 75%，但由于缺乏逻辑跨平台能力，只能双线并行：一边提升 JS 框架性能，一边试点 KMP 和仓颉 CJMP。

这意味着，逻辑跨平台已经从一项技术探索变成了现实刚需。

过去开发者做跨平台框架时，面对 Android 和 iOS 这样的成熟生态，更多是仰望和遵循。特别是 iOS，平台方处于生态顶端，可以制定应用上架、下架以及能力使用规则，开发者必须遵守。为了实现动态化等能力，团队有时不得不在规则边界内寻找复杂的技术路径。

鸿蒙作为后来者，所处的位置不同。为了吸引开发者、兼容既有生态，它需要在操作系统层面做更多适配和开放。例如，为了支持 KMP，鸿蒙开放了不少 CAPI；React Native 适配鸿蒙时，由于桥接 ArkTS 的性能不足，系统也曾紧急开放 CAPI，供框架进行更高效的调用。

跨平台框架带来了效率提升，Flutter 典型的提效比例是 1:1.5，到了鸿蒙阶段基本是两个人干三个人的活。但效率不是免费的，代价主要体现在三个方面：

性能与体验问题。 跨平台框架强调通用性，很难针对每一个平台进行足够深入的定制。Flutter 会面临包体积、内存占用、启动速度以及原生交互等问题。引入跨平台框架通常也意味着引入一种非原生语言，频繁的跨语言调用会增加额外开销。多语言运行时还可能带来更复杂的对象生命周期问题。例如 React Native 与 Android 原生代码之间可能形成相互引用甚至引用环，导致对象无法及时释放。业务团队需要对两侧的内存模型都足够了解，才能规避这类问题。

生态与碎片化问题。 国内不少头部厂商会基于开源框架进行深度定制，形成私有版本。此后，即使鸿蒙侧修复了 Flutter 的某些问题，也很难将改动顺利推送到所有应用厂商维护的分支中。

技术复杂性与维护问题。 引入一套新技术栈后，疑难问题可能横跨业务代码、跨平台框架与原生系统。工程师必须理解整条链路，才能找到真正的故障位置。这里还存在“抽象泄漏”问题。跨平台框架试图用统一抽象抹平平台差异，但差异很难被完全消除，业务代码中最终仍可能出现大量与平台相关的 if/else 。

跨平台框架提升了复用效率，却不会自动消除平台复杂性；很多时候，它只是把复杂性从业务层转移到了框架层。

鸿蒙为了支持 Flutter，对运行时、UI、跨语言调用、第三方库和开发命令行等关键模块进行了适配。

其中，第三方库的工作量尤其大。Flutter 生态中存在数以万计的第三方库，2025 年紧急完成了 Top 30 核心库的适配，此后的覆盖范围还在持续扩大。在完成基础适配后，鸿蒙又围绕渲染性能和系统垂直整合进行了优化。

Impeller 能够逐步替代 Skia，一个重要原因是它解决了着色器编译问题。