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

从 PC 时代到多端鼎立：跨平台不是新故事 回顾移动开发的历史，跨平台的需求几乎和移动应用本身一样古老。 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 的技术起点。 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 的核心就是统一业务逻辑。这也代表了跨平台框架的又一次代际变化。 从统一 UI 到共享逻辑 Flutter：自渲染带来一致性，也形成性能边界 Flutter 的关键技术是自渲染。开发者使用 Dart 编写一套代码，便可以运行在 Android、iOS 和 Web 等平台上。此后，Flutter 又引入 Impeller，以更现代的 GPU 渲染方式逐步替代 Skia，并利用 Vulkan 等图形接口改善渲染性能。 Dart 在国内的接受度相对有限，因此不少团队尝试将 Flutter 的开发语言替换为类 TypeScript 或 JavaScript 语言，例如腾讯的 MXFlutter。行业中甚至一度有一种观点：如果 Flutter 使用 JavaScript，它可能会成为更加理想的跨平台框架。 Flutter 未来可能会面临生态变化，但它所代表的自渲染技术路线不会轻易消失。框架可能退潮，具有独特价值的底层技术却会被保留下来。 KMP：以更细粒度的方式共享逻辑 KMP 与 Flutter 的设计理念不同。Flutter 试图统一 UI，KMP 则更加关注共享逻辑，这种差异主要体现在架构模式和交互性能两个方面。 在 Flutter 中，如果需要调用原生能力，通常要编写 Platform Channel。随着业务复杂度上升，一个图片库、网络库或其他组件可能对应大量通道代码，整体粒度偏粗。跨端与原生之间还需要进行序列化和反序列化，在高频交互场景中容易产生性能损耗，甚至引发卡顿。 KMP 引入了 Expect/Actual 机制。公共层可以声明统一接口，各平台再提供具体实现，其复用粒度既可以很粗，也可以细化到函数和属性。这样既能提高开发效率，也能保留调用平台原生能力的灵活性。 在性能方面，KMP 可以直接调用平台 C 接口，直接生成各平台原生二进制代码，性能可能获得数倍甚至接近两个数量级的提升。 因此，KMP 的下一代特征主要体现在两点：一是提高共享逻辑的开发效率，二是降低跨端逻辑与原生平台交互的成本。 为什么国内大厂纷纷押注 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，鸿蒙开放了不少 C