从0使用Kuikly框架写一个小红书Demo-Day5

Kuikly是怎么做到一码五端的

Kuikly实现了 "一码五端" 的开发能力，那么Kuikly是怎么做到又快又好的呢？

一、Kuikly技术的基石

Kuikly是基于JetBrain公司推出的KMM（Kotlin Multiplatform Mobile，现更名为 KMP）跨平台技术方案。

KMP 的跨平台编译能力将 Kotlin 代码编译为各平台原生产物（如 Android 的 JVM/ART 字节码、iOS 的 Native 二进制），可以支持多端高性能运行。

这些技术特性就是 Kuikly 的核心技术基石。

对比另外一个流行的跨端框架React Native，RN核心思想是用 JavaScript 编写应用逻辑和 UI 结构，通过桥接机制调用原生组件，在 iOS 和 Android 上渲染原生 UI。RN编译出来的最终产物并不是平台原生构建产物，而是依赖JavaScript运行时与原生平台通信，JS 和原生之间的通信需要序列化和反序列化，出现频繁通信场景时（如高频动画、复杂交互），会明显产生性能瓶颈。Kuikly的编译产物实际上和原生平台构建生成的产物没有区别，所以Kuikly可以有像原生开发般的性能。 RN 则是在运行时转换为原生控件，这种运行时转换肯定就不如Kuikly的原生编译产物性能好了。

二、Kuikly架构设计

三、关键技术点

3.1 两棵树渲染原理

典型的渲染流程包括4个步骤：创建 ViewTree、测量、布局、绘制。为了保留纯原生渲染的体验，绘制这一步是放到了 Native 层，前三步都放在平台无关的 Kotlin 层。

与 Flutter、RN 等基于虚拟 Dom 的三棵树方案相比，Kuikly 采用跨平台 DSL 树直接映射生成 Native 渲染树的方案，实现了更轻量的渲染机制，进一步提升性能表现。

3.2 高一致性原生渲染

跨端框架在渲染方式上主要分为两种：一种是采用原生控件渲染，比如RN框架；另一种是自绘渲染，如Flutter和Compose。原生渲染的优势在于拥有更完善的开发工具、能够提供更接近原生的交互体验，并且安装包体积更小；自绘渲染则能保证不同平台间很高的一致性，但在交互体验方面难以做到和原生完全一致。综合各种因素，Kuikly框架最终选择了原生渲染方案。

不过，原生渲染过去的一大难点是，不同平台上的原生控件行为经常不一致，导致开发体验不佳。Kuikly在架构设计阶段就充分考虑到这一问题，采取了“轻原生层”方式——原生UI层只包含极少量基础控件，而各种复杂、高阶的组件则在Kotlin跨平台核心层内实现和组合，这样既能保证组件的行为一致，也提升了整体的可维护性和扩展性。

3.3 UI扁平化

UI 层级过深会导致测量和布局耗时增加、渲染性能下降，甚至引发卡顿。为了解决这一问题，Kuikly借鉴了RN的思路，并结合自身的双树架构，设计了仅将可视节点渲染到屏幕上的机制。具体做法是：在第一棵“原型树”中，引入可渲染节点接口，各子类可重写该接口以标明是否需要实际渲染；对于仅用于布局的View节点，通过重写接口使其不作为渲染节点，避免被映射为原生控件。在原型树与渲染同步的过程中，框架会自动剔除所有非渲染节点，只将真正可渲染的节点保留在RenderTree，并最终实现与原生控件的1:1映射，从而提升渲染效率和性能。

四、小结

总体来说，Kuikly也是一种类RN框架，但是Kuikly比RN做的更好。Kuikly 把 Kotlin 多平台（KMP）的技术优势和自身独特的技术架构相结合，真真正正做到了 “一码五端” 的高效开发。它的技术底子其实很扎实，一方面靠 Kotlin 本身在多端的兼容性够强，另一方面是 KMP 的高性能原生编译能力托底。在核心架构上，Core 层专门装那些和具体平台无关的核心逻辑、统一 DSL 还有高阶组件，都是抽离出来的通用部分；Render 层则负责轻量化的原生渲染，以及对接各个平台的 API。再加上两棵树机制、UI 扁平化处理和指令式通信这几手，不仅把渲染的高性能和原生感拉满了，还让不同平台的UI一致性特别高，大幅提高了开发效率和开发体验。