KuiklyUI 如何通过 Applier 接入 Compose Runtime

前面的文章已经拆开 KuiklyUI 自研 DSL 的主链路：Pager 创建 view 树，状态变化更新属性，布局结果写入 Frame，属性和事件经过 Bridge 到达各平台 Render。Compose 页面走的是另一套上游机制。Jetpack Compose 是 Google 在 Android Jetpack 中推出的声明式 UI 框架，Compose Multiplatform 在此基础上支持更多平台。KuiklyUI 采用标准 Compose 的 @Composable、State、Modifier 和 Material 组件，页面结果仍要写回 KuiklyUI 的 Core、Bridge 和 Render。

本文按实际处理顺序展开：先确定 Compose 和 KuiklyUI 各自负责的部分，再看页面如何进入容器、树变化如何落地，以及布局和绘制结果如何下发。

一、Compose 的复用范围

KuiklyUI 没有定义另一套 Compose DSL。页面中的 @Composable、remember、mutableStateOf 和 Modifier 都来自标准 Compose API，State 的读取、重组调度和 Composition 记录也继续使用 Compose Runtime。

运行时负责计算。Composable 执行后会形成一棵 UI 描述树；State 变化时，Runtime 能判断哪些节点需要插入、移动、删除、重新布局或重绘，但它不知道这些结果要落到哪一种渲染宿主。

Android Compose 的计算结果由 Android UI 渲染体系承接。KuiklyUI 使用自己的 Core view 树作为宿主，再由统一的 Bridge 对接 Android、iOS、鸿蒙和 Web Render。Compose 的节点、几何信息和绘制属性需要先转换为 Core 能处理的数据。

源码中可以看到两部分内容。Compose Runtime 直接依赖 androidx.compose.runtime；场景、布局和绘制相关代码位于 com.tencent.kuikly.compose.ui，文件保留了 Compose 开源实现的来源信息，并接入 KuiklyUI 渲染后端。ComposeContainer、KuiklyApplier 和 KNode 位于两部分之间，负责完成适配。

后面的链路按这个关系展开：页面进入容器，树变化交给 Applier，KNode 再处理结构、布局和绘制结果。

二、Compose 页面进入 KuiklyUI 容器

ComposeContainer 是 KuiklyUI 提供的页面容器，也是 Pager 的子类。Compose 页面仍使用 KuiklyUI 的路由、页面尺寸和生命周期；业务传入的 Composable 内容会在页面创建后交给 Compose Scene。

容器会准备一个根 DivView 作为 Compose 子树在 Core 中的挂载位置，并把页面尺寸交给 Scene。重组、布局和绘制由 Scene 推进，页面帧循环继续接在 KuiklyUI 的调度体系中。

下游几个对象需要先区分。Core 维护平台无关的 view 树；Frame 保存位置与尺寸；Attr 保存透明度、圆角、裁剪等视觉属性；Bridge 将 view 的创建和更新指令交给 Android、iOS、鸿蒙或 Web Render。

Compose DSL 接入 KuiklyUI 的整体边界

图的上半部分是 Compose 的计算过程：业务描述界面，Runtime 根据 State 计算更新。下半部分是 KuiklyUI 的 Core、Bridge 和 Render。KuiklyApplier 与 KNode 放在中间，负责转换两边的数据。

容器确定了内容的运行位置。接下来需要把 Compose 的树变化写入 Core view 树，Applier 由此进入链路。

三、树变化的接缝

Composition 记录 Composable 与 State 的依赖，并在重组后得到一组树操作。它描述哪些节点需要插入、移动或删除，不直接操作具体的 view。Compose 将这一步交给 Applier，由不同宿主提供实现。

KuiklyApplier 继承 Compose Runtime 的 AbstractApplier。它接收树操作，并将操作交给当前的 KNode。这一层只负责树操作的转交，不承担布局、绘制或 Bridge 通信。

Compose 树变化如何映射为 KuiklyUI view 树

KNode 连接两套节点模型。它继承 Compose UI 层的 LayoutNode，参与 Compose 的布局和绘制；它也持有 KuiklyUI 的 DeclarativeBaseView，负责把结构变化写入 Core view 树。节点映射主要留在 KNode，KuiklyApplier 只做操作转交。

Compose State 与自研 DSL 的 observable 分别维护依赖关系。前者触发 Compose 重组，后者重新执行依赖它的 attr 属性块。两条路径在 Core view 更新处汇合。

结构建立后，Compose 还会给出位置、尺寸和绘制属性。这些结果进入 KNode 后，需要按 KuiklyUI 的 Frame 与 Attr 边界继续拆分。

四、布局和绘制结果的映射

Compose 的 measure 与 place 阶段计算节点的位置和尺寸。draw 与 Modifier 产生透明度、裁剪、圆角、阴影等视觉信息。这两类结果的表达方式不同，KuiklyUI 分别处理。

Compose 的布局与绘制结果如何回到 Frame 和 Attr

布局结果进入 Frame。KNode 取得 Compose 计算出的相对位置和尺寸，按页面 density 换算后更新 RenderView。RenderView 是 Core 中与平台实际渲染对象对应的承载对象。

绘制结果进入 Attr。KNode 在绘制过程中收集属性，整理为 Attr 更新，再由 Bridge 下发给平台 Render。Compose 的绘制结果由此进入 KuiklyUI 已有的属性更新通道。

Frame 和 Attr 的边界也限定了适配范围。Compose 的某项效果能否正常落地，取决于 KuiklyUI 是否有对应的几何或属性表达；两边表达能力不一致时，适配层需要补充转换或保留限制。

五、适配层的维护边界

Compose Runtime、Composition 和重组机制由标准 Compose 提供。KuiklyUI 沿用 Pager、Core、Bridge 和各平台 Render。两者之间的代码主要集中在页面容器、Applier 和 KNode。

KNode 的职责最多。它要遵循 Compose 的节点和布局语义，也要维护 Core view、Frame 和 Attr 的映射。新增一个 Compose 能力时，通常先判断它影响树结构、几何信息还是视觉属性，再检查 KuiklyUI 下游能否表达这份结果。

Compose 页面继续使用标准的 State 与组件模型，KuiklyUI 不需要重复实现 Compose Runtime。维护重点落在适配边界，各平台 Render 继续处理来自 Core 的统一更新。

总结

KuiklyUI 的 Compose 支持建立在 Jetpack Compose 的标准模型上。Compose Runtime 执行 Composable、记录 State 依赖，并计算树、布局和绘制的变化。ComposeContainer 将页面接入 KuiklyUI 生命周期，KuiklyApplier 将树操作转交给 KNode，KNode 再把结构、Frame 和 Attr 写回 Core，后续经过 Bridge 到达各平台 Render。

Applier 划出了 Compose 计算与 KuiklyUI 渲染之间的边界。页面帧循环和输入事件如何进入 Compose Scene，需要结合页面容器继续展开。