KMP鸿蒙适配：半自绘降内存95%、CMC降GC卡顿90%

鸿蒙专家

在鸿蒙生态快速崛起的背景下，跨平台框架的适配节奏明显加快。KMP（Kotlin Multiplatform）作为以共享业务逻辑为核心的跨平台方案，从2025年开始与华为展开深度合作，2026年6月发布了首个KMP公版。从最初只能承载简单页面，到如今可以支撑完整应用开发，KMP在鸿蒙上的落地经历了多项关键改造，其中渲染内存下降95%、GC卡顿率下降90%这两组数据，直观反映了底层优化的实际效果。

一、为什么是KMP：共享逻辑比共享UI更适合国内现状

Flutter的核心思路是统一UI，开发者用Dart写一套代码，通过自渲染引擎保证多端视觉一致。但KMP的切入点不同，它聚焦于共享业务逻辑，而不是UI层。这种差异在实际开发中体现在两个层面：

首先是交互方式。Flutter调用原生能力时通常依赖Platform Channel，业务复杂度上来之后，图片库、网络库等组件会产生大量通道代码，跨端与原生之间还要做序列化和反序列化，高频交互场景容易卡顿。KMP的Expect/Actual机制则更灵活，公共层声明接口，各平台提供具体实现，复用粒度可以细分到函数和属性级别，既能提升开发效率，又保留了对平台原生能力的调用灵活性。

其次是性能表现。KMP通过Kotlin/Native直接生成各平台的原生二进制，可以直接调用平台C接口，避免中间层的解释和转换开销，性能获得数倍甚至接近两个数量级的提升并不罕见。

国内大厂密集押注KMP的一个重要背景，是鸿蒙生态的崛起。当企业需要同时维护Android、iOS和鸿蒙三端时，每新增一个平台就扩充一支完整团队的模式难以为继。逻辑跨平台从技术探索变成了现实刚需。

值得一提的是，鸿蒙在这个过程中的姿态相当开放。为了支持KMP，鸿蒙开放了大量CAPI接口。React Native适配鸿蒙时，一度因为桥接ArkTS的性能不足，系统也紧急开放了CAPI供框架调用。这种操作系统层面的适配和开放，是后来者吸引开发者、兼容既有生态的必然选择。

二、半自绘：把自渲染的内存包袱卸下来

Flutter采用自渲染机制，意味着它要维护一整套独立的GPU上下文和渲染管线。这在多端一致性上有优势，代价也很直接：内存占用高、启动速度慢、与原生内容混排困难。以1080P手机为例，单个Flutter页面大约增加70MB内存，如果同时存在N个Flutter页面，额外开销接近N×70MB。混排时的"挖洞"操作更是让人头疼，透明度的正确设置、拖拽过程中的图层错位，都是自渲染与原生渲染两套体系碰撞出来的典型问题。

KMP在鸿蒙上的方案是"半自绘"。组件和文本仍然由框架生成绘制命令，但底层复用鸿蒙的原生渲染管线，不再创建一套完整的GPU环境。这样做有三个直接收益：不需要重复申请大量渲染内存；不用重新创建GPU环境，启动速度更快；跨平台内容与原生内容的混排问题也迎刃而解。

半自绘带来的内存收益非常可观。以Compose实例为例，每个实例可能创建约5个Buffer，一个页面存在10个实例时，额外开销接近500MB。复用原生渲染管线后，这部分内存可以大幅下降，实测渲染内存下降95%的成果正是来源于此。

半自绘还打开了系统垂直整合的空间。传统自渲染方案中，即使页面只有局部节点移动，也可能触发整个区域的重新绘制。在原生渲染管线的支持下，可以缓存对应的子树结构，节点移动时仅调用transform接口修改位置，大量减少重复绘制。

三、CMC算法：把GC长卡顿拆解成日常小清理

2025年时，KMP在鸿蒙和iOS上使用的GC算法仍接近早期CMS的水平，两个痛点非常明显：长时间卡顿和内存碎片过多。

问题出在对象扫描机制上。GC在扫描时难以准确区分某个值到底是指针还是普通数据，因此虽然Mark阶段可以并行执行，但对象无法安全移动。运行一段时间后，堆里出现大量不连续的内存空洞，即使剩余内存总量充足，也可能申请不到一块较大的连续空间。这时候只能触发Stop-the-World，暂停主线程重新整理内存，卡顿时间可达几十甚至上百毫秒。

鸿蒙自研的CMC算法对症下药。第一项改造是按对象大小将内存划分为多个Region，每个Region由独立线程管理，GC并发度显著提升。第二项改造是引入Stack Map机制，记录对象引用信息，运行时能够准确判断对象引用关系，对象就可以在GC过程中安全移动了。

这两项改造配合起来的效果是：对象能从From Space拷贝到To Space，碎片整理分散到日常GC中按部就班地完成，而不是等问题堆积到一定程度后做一次耗时很长的全局大清理。这就像平时持续打扫房间，而不是等到房间彻底无法使用时再停下所有工作大扫除。实测GC卡顿率下降90%，体验改善非常明显。

四、并行编译：拆开一个巨大的LLVM IR文件

KMP工程在鸿蒙上的编译，过去是一条典型的串行链路：大量Kotlin文件被编译成一个巨大的LLVM IR文件，做全局优化后生成一个大型.so文件。这个过程几乎无法并行化，编译耗时成为开发迭代的瓶颈。

鸿蒙的改造思路很直接：把一个大LLVM IR拆分成多个IR模块，模块内部再做并行编译。但拆分引入了两个新问题。

第一个问题是包体积变大。模块独立编译时，需要导出更多Symbol供其他模块调用，其中一部分最终并不会被真正用到。解决办法是拆分前记录真正需要暴露的Symbol，打包后再清理中间产物中的冗余Symbol。

第二个问题是运行性能下降。模块化初期关闭了部分全局变量优化Pass，编译器无法完成原有的全局优化。解决方法是给全局变量信息建立缓存，让每个模块在编译时仍然能识别需要优化的全局变量，从而保留全局优化的能力。

两个问题解决后，并行化编译让KMP的整体构建速度提升了约2到4倍。对于需要频繁验证跨端逻辑的团队来说，这个提升直接转化成了开发效率。

五、AI Coding的落地实践：A2K采纳率60%、D2C引入React作IR

鸿蒙突击队在KMP的建设中，同步探索了AI Coding的完整研发流程，重点包括A2K（Android到KMP）和D2C（设计稿到Compose）。

AI Coding在大型工程中面临三个现实挑战。第一，头部应用积累了大量Kotlin、ArkTS代码，模型需要理解整个工程而不只是一个孤立函数。第二，AI生成代码的质量控制难，有些团队生成后不做充分验证就直接提交，风险明显。第三，每家企业的编码规范和内部组件体系都是私域知识，通用的AI工具难以直接理解。

A2K的流程包括理解原项目、生成Spec、初版代码转换、对齐测试和性能结果，最终产出可交付代码。其中最关键的改造有两个：复用原工程已有的测试用例资产，测试用例既用于验证结果，也帮助模型理解原代码的真实行为边界；从源代码中识别并抽取基础模块，在生成初版代码时把目标工程容器和基础设施能力一并嵌入。经过这些改造，A2K生成代码的采纳率达到了约60%。

D2C的演进更有意思。最初采用一步到位的方案，直接把Figma设计稿转成Compose代码，实际使用中问题频出。模型可能无法正确理解图层关系，导致z-order错误；Figma里写死的偏移值会让转换后的页面在其他尺寸屏幕上短一截或多一截。

后来团队调整了策略，不再直接生成Compose，而是引入React作为中间表示（IR）。选React有两个原因：React与Compose对大模型而言范式相似性高，都采用声明式响应式UI，转换顺畅；React生态成熟，存在大量Figma to React工具，能更好地完成设计稿的初步结构化。

拆分为"Figma到React、React到Compose"两步后，过去难以解决的尺寸偏差和层级错误基本改善，在合作厂商的评估体系中整体得分提高了约10分。React还带来了调试优势，中间结果可以直接在Chrome中展示，团队能先验证UI结构是否正确，再进入Compose代码生成。这印证了一个判断：AI Coding并不是步骤越少越好，必要的中间表示能把一个不稳定的大问题拆成两个更容易验证的小问题。

六、跨平台框架如何选：三种路线的现实考量

从React Native、Flutter和KMP三条路线来看，AI带来的影响各不相同。

React Native受到冲击最大。它最初的核心价值之一是让前端工程师能开发移动应用，但在AI可以辅助生成原生代码后，这一优势明显减弱。RN仍具备天然的动态化能力，但H5等方案也能覆盖不少动态化需求，Meta已在部分页面减少RN的使用。新项目中对RN需要谨慎评估。

Flutter的突出价值仍然是多端UI一致性。如果应用强调不同平台上的统一视觉体验，对启动速度和包体积没有极致要求，Flutter依然合适。但自渲染的内存边界和混排困难，决定了它很难在高端场景达到原生性能。

KMP则更适合国内三端并行的环境。既能复用Android、iOS和鸿蒙间的业务逻辑，国内企业又有大量存量Kotlin代码，迁移成本可控。KMP通过Kotlin/Native生成原生二进制，性能接近原生。结合鸿蒙生态的持续开放，一个务实的判断是：面向三端长期建设，战略上优先考虑KMP；强调UI一致性且性能要求不极端的，选Flutter；React Native则要结合动态化需求和生态趋势谨慎决策。

AI能生成原生代码，并不代表跨平台框架会失去价值。有公司在裁员50%后，正是通过AI Coding补充研发能力缺口，同时用KMP统一技术栈来降低多套开发体系的维护负担。如果AI分别生成三端代码，工程师调试时还是要理解三套技术栈，跨平台框架抹平平台差异的效率杠杆反而可能因为AI大规模生成代码而进一步放大。

跨平台框架的核心问题正在从"如何让开发者高效编写多端代码"，转变为"如何让AI生成更高质量、可验证、可复用的多端代码"。这要求框架提供更清晰的抽象、更完整的测试资产和更稳定的工具链。

七、结语：共享逻辑、原生UI与AI的混合工作流

从国内市场的趋势来看，KMP的共享逻辑能力与鸿蒙生态建设之间契合度很高，既兼容Android侧的Kotlin存量，又降低新增鸿蒙端的研发成本。但对于追求极致体验的大型应用，UI层的统一很难替代原生体验——iOS的原生转场交互、Android的水波纹效果，跨平台UI框架很难完整复刻。

未来三年，共享逻辑加原生UI很可能成为跨平台开发的主流形态，AI则贯穿需求理解、代码迁移、UI生成、测试验证和性能对齐的全流程。原生UI负责平台体验，KMP负责共享逻辑，AI负责放大开发与迁移效率，这套混合工作流正在从概念走向工程实践。

（本文基于InfoQ对华为鸿蒙突击队编程框架首席技术专家谢国的分享整理。谢国拥有10年以上移动应用开发经验，曾任字节跳动Flutter团队负责人。）

热心网友4

楼主的分享很扎实，把KMP在鸿蒙上的落地路径讲得很清楚。尤其“半自绘”和“CMC”这两块，把性能优化的具体手段和收益量化了，读下来收获很大。 有个点想请教：半自绘模式下，KMP生成的绘制命令在复用鸿蒙原生渲染管线时，遇到复杂的自定义绘制场景（比如自绘图表、复杂动画）会不会有表达力或性能上的限制？还是说这类场景基本都能无损映射到原生能力上？

热心网友4

看了这篇技术分享，感觉KMP在鸿蒙上的这套优化思路挺扎实的，尤其是半自绘和CMC那两块，确实解决了跨平台框架落地的老大难问题。之前用Flutter混排的时候被“挖洞”坑过，看到“半自绘”复用原生渲染管线的做法，觉得这才是更符合国内多端现状的方向——共享逻辑不强行统一UI，灵活性和性能都能兼顾。 CMC那个“平时持续打扫”的比喻也很形象，把长卡顿拆成日常小清理，思路跟传统CMS比确实是质变。还有并行编译那段，拆IR模块带来的包体积和全局优化问题，能看出鸿蒙团队是真在底层打磨，不是简单套壳。 AI Coding部分，A2K采纳率60%这个数据挺亮眼的，能复用原工程测试用例来帮模型理解行为边界，这个思路值得借鉴。D2C一步到位转Compose遇到问题也算意料之中，设计稿到代码中间隔着太多隐式逻辑，后续如果能把IR层做扎实，应该会更稳。 整体看下来，KMP在鸿蒙上的这套落地路径，对国内大厂三端复用来说确实有吸引力，期待后续公版进一步完善。

热心网友4

感谢楼主分享，这篇把KMP在鸿蒙上的几项关键优化讲得很透。尤其是半自绘那部分，之前一直担心Compose多实例的内存问题，看到复用原生渲染管线后能降这么多，确实很有吸引力。想请教一下，半自绘在复杂动画场景下，和原生组件混排时会不会有额外的同步开销？另外CMC算法目前是鸿蒙独有还是也会回馈到KMP的iOS端？期待后续更多实践细节。