>第一篇文章聊了为什么决定深入 KuiklyUI。这篇是整个系列正文的起点。我选择从整体架构开始写，是因为跨端框架天然涉及多层抽象——如果一上来就钻进某个类或某条调用链，读下来容易看着很多细节却说不上来它们在整套系统里处在什么位置。先把整体框架是什么、层和层之间怎么衔接搞清楚，后面拆具体机制时才不容易迷路。

---

## 一、先从一张图开始
![image.png](https://developer.qcloudimg.com/http-save/yehe-320080/7814d19641d2aeb64b107d5022cc1d98.png)

这张图是我自己画的 KuiklyUI 架构图。五层按从上到下的顺序说一下。

最上面是**业务层**。平时写代码的地方——给类加 `@Page` 注解、用 `View { }` 和 `Text { }` 搭 UI、在 `attr { }` 里配样式、在 `event { }` 里绑交互。对业务开发来说，KuiklyUI 首先表现出来的是一套 Kotlin 风格的 UI DSL。

业务层下面有一条**Compose DSL** 路径，是可选的。不是所有页面都要经过它——KuiklyUI 同时支持自研 DSL 和标准 Compose DSL，两条路径在底层汇合。这篇先知道它存在就够了。

再往下是 **Core 层**。Core 提供了业务层构建 UI 和业务逻辑需要的各种类和方法——Pager 基类、View 组件、响应式能力、布局引擎、网络模块——业务层通过继承和调用这些能力来写跨端代码。业务层和 Core 一起组成了一套完整的跨平台逻辑层。页面管理、状态更新、内部 view 树、布局计算、模块调用、和 Native 通信的入口，这些能力全部收敛在 Core 里。

Core 再往下是 **Bridge 层**。它不负责业务，也不负责真正渲染界面，职责只有一条：把 Core 的指令翻译成一套标准化的通信协议。共享层不能直接操作 Android 的 `View` 或 iOS 的 `UIView`，所以中间必须有这样一条通道，把创建组件、设置属性、触发事件、回传结果这些动作有组织地传下去。

最下面是 **Render 层**。这里不再是共享逻辑，而是五个平台各自独立的渲染实现。Android 有自己的 Render，iOS 有自己的 Render，鸿蒙、Web、小程序也各自处理自己的平台 UI 对象。它们接收 Bridge 下发的指令，再把这些指令落实为真正的原生 UI 行为。

一句话概括就是：业务层通过调用 Core 的能力完成跨端代码的编写，Core 通过 Bridge 向 Render 下发渲染指令，Render 层各平台各自实现。

这张图和 KuiklyUI 官方架构图有一个关键差别。官方图只画了 Core 和 Render 两层，Bridge 没有独立成层，而是标了两个方向箭头——`callKotlin` 和 `callNative`。我在官方图的基础上把 Bridge 单独拉出来画成了一层，目的是让跨端通信这条边界更显眼。后面讲具体机制会反复回到这里，画清楚了后面理解成本会低很多。

---

## 二、从点击到更新发生了什么

前面把五层各自说了一遍。现在换个角度——不从结构看，从一次交互看：用户点了一下按钮，后面发生了哪些事情。

用户在屏幕上点了一下按钮。这是真实的原生 View——可能是 Android 的 `Button`，也可能是 iOS 的 `UIButton`。平台原生事件系统先捕获这个点击。

Render 层收到事件后，把它转化为 Bridge 协议里的一条指令，沿 `callKotlin` 方向传给 Core。这条指令大致包含：methodId（一个数字，标识这是「View 事件触发」）、instanceId（哪个页面）、viewTag（哪个 View）、eventType（事件类型是什么）。

Core 的 BridgeManager 收到指令，先根据 instanceId 找到对应的 Pager 实例，再根据 viewTag 找到对应的 View。然后触发这个 View 上的 `onClick` 回调——这就是业务代码里写的那段逻辑。

业务回调执行，`count++`。`count` 是一个 `observable` 字段，响应式系统检测到它变了，通知所有依赖它的 View 需要更新。这些 View 重新计算自己的属性，再通过 `callNative` 方向下发新的渲染指令到 Render。Render 把属性变更应用到对应的原生 View 上，屏幕像素更新。

一次点击加一次状态更新，Bridge 穿了两次——事件上行走 `callKotlin`，UI 更新下行走 `callNative`。

但更值得注意的不是次数，而是业务代码从头到尾都没有直接和 Bridge 打过交道。你写 `onClick { count++ }` 的时候，就像写 Vue 的 `@click="count++"` 或 React 的 `onClick={() => setCount(c => c + 1)}` 一样自然。跨端通信的复杂度——事件怎么从 Native 传到 Kotlin、状态更新怎么从 Kotlin 下发到 Native——全部被 Core 和 Bridge 吸收掉了。

这种体感并不陌生。写 Vue 的时候也不会关心 `count.value++` 背后响应式系统怎么收集依赖、怎么触发组件 re-render。但在真正理解 KuiklyUI 整体设计之前，并不知道 KuiklyUI 和 Vue 在这一点上像到了什么程度。把 Bridge 的通信模型和 ReactiveObserver 的依赖收集机制串起来看之后，这一点就更具体了——KuiklyUI 的响应式机制和跨端通信这两块，和 Vue 有不少同构的地方。这些同构不是巧合，是两边在面对类似的问题时各自做出的选择，理解这些选择为什么成立，比记住具体怎么实现的更有价值。

---

## 三、Core 层在做什么

回到刚才那次点击。事件从 Native 传到 Kotlin 之后，是 Core 的 BridgeManager 根据 instanceId 找到对应的 Pager 实例、根据 viewTag 找到对应的 View，再触发的 `onClick` 回调。`count++` 之后，也是 Core 的 ReactiveObserver 检测到变化，通知依赖方重新计算属性，再通过 Bridge 下发更新。换句话说，Kotlin 侧发生的所有事情——业务回调、状态追踪、指令生成——都是 Core 在负责。

把 Core 拆开来看，大概可以按这几个角度理解。

### Core 是一个 KMP 库

KMP 是 Kotlin Multiplatform 的缩写，简单说就是用一份 Kotlin 代码编译出多个平台的可执行产物。每个平台有独立的源集目录，跨平台通用代码放在 `commonMain`，各平台特有的代码放在 `androidMain`、`iosMain` 等目录，通过 `expect` / `actual` 机制对接。之前我在专栏里写过两篇 KMP 的详细介绍，不熟悉的读者可以先翻一下[《前端开发者的 Kotlin 之旅》第 18 篇](https://cloud.tencent.com/developer/column/105164)，这里不重复展开了。

Core 的目录结构很能说明问题。绝大多数逻辑写在 `core/src/commonMain/` 里——Pager 管理、view 树、响应式系统、指令系统、FlexLayout 布局引擎、BridgeManager 通信入口。各平台目录（`androidMain`、`iosMain`、`ohosArm64Main`、`jsMain`）只做两件事：把 Bridge 协议翻译成对应平台的原生调用，以及补一些平台特有的底层能力（JSON 引擎、异常封装这类）。

这种组织方式意味着**业务逻辑代码 100% 跨端共享**。新增一个平台不改 `commonMain`，只需要在对应平台目录加一份 Bridge 的 native 调用封装。前端工程师对这种模式应该不陌生——很像 monorepo 里 `shared/` 目录放同构代码、`client/` 和 `server/` 各放平台特有逻辑，只不过 Kotlin 的源集（sourceSet）机制把它体系化了。

### 两条 DSL 路径

Core 同时支持两种 DSL 写法——自研 DSL（基于 `attr { }` 和 `event { }`）和标准 Compose DSL（基于 `@Composable` 函数）。不管走哪条路径，最终都构建出同一棵 view 树，后续走完全相同的 Bridge 通信链路。这和 Vue 2 升 Vue 3 的思路很像——引入 Composition API 但保留 Options API，存量业务不强迫改造，新业务推荐新写法。两条 DSL 的具体写法和差异后面会有单独的文章展开。

### 主要功能模块

**Pager 和 PagerManager**。Pager 是 KuiklyUI 的页面抽象——每打开一个页面就创建一个 Pager 实例，拥有完整的生命周期（`created`、`pageWillAppear`、`pageDidAppear`、`pageWillDisappear`、`pageDidDisappear`、`destroyed`）。PagerManager 是单例，管理所有活动的 Pager 实例。这个模型和 Vue 实例、React 顶层组件的概念非常接近。

**ReactiveObserver 响应式系统**。KuiklyUI 自研了一套依赖收集和更新触发机制，核心 API 是 `observable`。你声明一个 `var count by observable(0)`，在 `attr { text("$count") }` 里读取时自动建立依赖，后续 `count++` 时自动通知所有依赖方更新。这套机制和 Vue 3 的响应式系统几乎是同一套思路——依赖收集、变更通知、按需更新。

**vfor / vif / vbind 指令**。三个核心指令，名字和 Vue 完全一致。`vfor` 做循环渲染，`vif` 做条件渲染，`vbind` 做值绑定。对前端工程师来说看到这三个名字几乎不需要学习成本。

**自研 FlexLayout**。这是 KuiklyUI 最重要的设计点之一。它的 Flex 布局引擎跑在 Kotlin `commonMain` 里，所有平台共用同一份布局算法。这意味着同一个布局规则在五个平台上像素级一致。这个选择的代价后面会讲。

**Module 体系**。Network、Router、SP（持久化存储）、Notify（事件总线）这些能力通过 Module 体系暴露给业务。使用风格类似浏览器 Web API——你调用 `network.get(url)` 不需要关心底层是 Android 的 OkHttp 还是 iOS 的 NSURLSession。

---

## 四、Render 层是怎么和 Core 协作的

再看那次点击的另一端。用户的触摸最初是被平台原生的 View 捕获的——Android 的 `Button` 或 iOS 的 `UIButton` 上的事件监听。最后 `count` 更新后的新属性，也是下发到同一个原生 View 才最终体现在屏幕上。这两头都是 Render 的事。

Render 的职责很明确：接收 Bridge 下发的指令，操作真实的平台 UI 对象。五个平台的 Render 是各自独立的工程——Android 用 Kotlin 和 Java，iOS 用 ObjC 和 C++，鸿蒙用 ets + C++，Web 用 Kotlin/JS。各自用平台原生语言对接各自的 UI 系统。

Render 和 Core 之间的解耦方式也值得注意。Render 编译时只依赖 Core 的接口签名——用的是 Gradle 的 `compileOnly`。这意味着编译时能看到 `IKuiklyCoreEntry` 这些接口的类型，但运行时不带 Core 的实际类。运行时宿主 App 会加载业务跨平台层代码（业务代码加上 Core 的编译产物），Render 再通过 KuiklyCoreEntry 这个入口和跨平台层对接。

这和 TypeScript 的 `import type` 是同一类思路——编译期有类型，运行时不带实现。工程设计上就是经典的依赖倒置：Render 依赖接口，不依赖具体实现。好处很直接：Render 可以独立升级，Core 内部重构不影响 Render。

---

## 五、Bridge——Core 与 Render 通信的桥梁

Bridge 是 Core 和 Render 之间唯一的通信通道。回到那次点击——事件从 Render 传到 Core、Core 更新后下发到 Render，这两次穿越走的都是 Bridge。它的设计选择直接决定了整个跨端机制的复杂度和表达能力。

KuiklyUI 的 Bridge 用了一套**瘦协议**——23 个固定的 methodId，每个 method 的签名统一为 `(methodId, arg0, arg1, arg2, arg3, arg4, arg5)`。

23 个 method 分两个方向。Native 到 Kotlin 方向只有 6 个，全部是事件和生命周期通知。Kotlin 到 Native 方向有 17 个，全是操作指令。数量不对称是因为业务逻辑都在 Kotlin 侧，Kotlin 侧需要发出更多种类的指令，Native 侧只需要汇报有限的几种事件。

固定签名设计也值得注意——`arg0` 永远是 instanceId（页面 ID），其余 5 个槽位按 method 含义解读。这意味着每个平台的 Render 工程只需要实现一个 `callNative` 函数，里面用 `when(methodId)` 分发到具体逻辑。新增一个 method 就是加一个 ID 常量，不破坏 ABI，老版 Render 没有匹配项就走 default 兜底。

这种设计放弃了灵活（复杂参数要序列化成 JSON 塞进某个槽位），也放弃了调试的便利（看到 `callNative(4, ...)` 需要查表才知道是 SET_VIEW_PROP），换回来的是性能（无字符串匹配开销）和极强的协议稳定性。

如果是一个快速试错的创业项目，大概率会选择调试更友好的 JSON 全量协议——开发效率优先。但 KuiklyUI 服务的场景是 QQ、腾讯视频、腾讯新闻这种亿级 DAU 的大业务，任何一次额外的序列化开销在用户体量下都会被放大。所以它选了保守的、稳定的方案。

---

## 六、总结

这篇文章没有深入解释任何单个机制的实现，只是先把整体框架的几个核心认识建立起来。

KuiklyUI 把共享逻辑收进 Core，把平台差异留给 Render，用 Bridge 维持边界。Core 用 KMP 把业务逻辑写一次跑五个平台，Render 用独立工程保持平台原生开发的灵活性。Bridge 是 23 个固定指令的瘦协议——放弃了表达力和调试便利，换来了性能和协议稳定。Compose 是 Core 之上的可选 DSL 路径，业务可以根据团队情况选用。

一个值得注意的视角是，KuiklyUI 的架构设计和 React 生态的 Renderer 模式有很多结构上的同构——Core 对应 react-reconciler，Bridge 对应 commit 阶段，Render 对应各平台 renderer。这不是巧合，两种框架在面对跨端 UI 这个同一问题时，各自独立收敛到了类似的答案。

下一篇文章会顺着这条线索继续，从页面创建这条主链路开始——一个 KuiklyUI 页面从宿主发起创建到最终显示在屏幕上，中间经历了哪些阶段。

第一篇文章聊了为什么决定深入 KuiklyUI。这篇是整个系列正文的起点。我选择从整体架构开始写，是因为跨端框架天然涉及多层抽象——如果一上来就钻进某个类或某条调用链，读下来容易看着很多细节却说不上来它们在整套系统里处在什么位置。先把整体框架是什么、层和层之间怎么衔接搞清楚，后面拆具体机制时才不容易迷路。

KuiklyUI 整体架构解读

前端开发工程师

架构设计

前端

客户端

深入解析KuiklyUI跨端框架架构：从业务层到Render层的五层设计，Core层实现Kotlin跨平台逻辑，Bridge层标准化通信协议，Render层处理平台原生UI。文章详细剖析了点击事件到UI更新的完整流程，揭示KuiklyUI如何通过响应式系统与跨端通信机制实现高效开发。

事件总线

TypeScript

Android

Kotlin

JSON

Java

2026年中大促 | AI 领航 智绘未来

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

KuiklyUI 整体架构解读-腾讯云开发者社区-腾讯云

KuiklyUI 整体架构解读

KuiklyUI 整体架构解读

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐