技术摘要：通过 ArkTrans 将声明式 UI 迁移至鸿蒙系统

问题陈述

鸿蒙系统的兴起产生了将软件从 Android 和 iOS 等成熟平台迁移至鸿蒙的迫切需求。然而，用户界面（UI）开发的格局已从命令式范式（如 XML、UIKit）转向声明式框架：Android 的 Kotlin Jetpack Compose (KJC)、iOS 的 SwiftUI 以及鸿蒙的 ArkUI。现有的自动程序翻译方法并不适用于这一任务，因为它们主要针对后端逻辑或遗留的命令式 UI。

直接应用大语言模型（LLM）将 KJC/SwiftUI 翻译为 ArkUI 面临两个显著挑战：

1. 编程语言（PL）熟悉度不足： ArkUI 是一个相对较新的框架（2023 年正式发布），与成熟的编程语言相比，在代码托管平台上缺乏足够的语料库。因此，最先进的（SOTA）LLM 缺乏足够的训练数据来掌握 ArkUI 特有的语法和编程范式。
2. 严重的语法混乱： 由于这种不熟悉性，LLM 在翻译过程中倾向于复制源语言的语法，或者混合源语言与目标语言的语法。实证研究表明，40% 的直接提示失败源于语法错误，即使在有引导的情况下，超过 50% 的语法错误仍无法解决。

方法论：ArkTrans

为了应对这些挑战，作者提出了 ArkTrans，一种用于自动 UI 迁移的启发式引导 LLM 方法。ArkTrans 通过一个四阶段流水线运行：

1. 元数据提取 (Metadata Extraction, ME)

系统将源 UI 文件（KJC 或 SwiftUI）解析为抽象语法树（AST），以层次化地提取元数据。它过滤掉非 UI 逻辑（如生命周期钩子、属性包装器），并构建一个结构化 UI 树。该树中的每个节点都是一个包含组件类型、属性（键值对）、修饰符（链式调用）和子节点的元组。这一过程将纯 UI 声明从样板代码中分离出来。

2. 骨架构建 (Skeleton Construction, SC)

利用提取的 UI 树，ArkTrans 合成一个确定性的 ArkUI 骨架。此步骤通过预定义的字典进行跨语言组件映射，将已知的组件、属性和修饰符翻译为其 ArkUI 对应的形式。未知元素则保留为注释。其结果是一个部分的 ArkUI 代码结构，定义了 UI 拓扑和布局约束，确保最大限度地保留无法通过启发式迁移的元数据。

3. LLM 驱动的翻译 (LLM-driven Translation, LT)

调用 LLM 来使用生成的骨架填充可执行代码。提示策略包括：

• 系统角色与上下文： 提供 ArkUI 骨架和提取的颜色常量。
• 单样本学习 (One-Shot Learning)： 提供一个演示示例，展示如何将类似的骨架翻译为 ArkUI 代码。该示例涵盖了常见的语法陷阱（属性赋值、修饰符链式调用、布局扩展、状态管理），以引导 LLM 进行上下文学习。

4. 后置修复 (Post-Fixing, PF)

意识到 LLM 仍会产生语法错误，ArkTrans 应用了一个基于规则的后置修复引擎。该阶段根据经验揭示的错误模式执行确定性转换：

• 常量内联 (Constant Inlining, CI)： 通过内联字面量值并移除未使用的类定义，解决对外部设计令牌（如颜色类）未解决的引用问题。
• 词法纠正 (Lexical Rectification, LR)： 将源语言特有的词法标记（如 Kotlin 中的 toInt()）替换为其 ArkUI 等价物（如 ArkTS 中的 Number()）。
• 布局属性纠正 (Layout Property Rectification, LPR)： 将方向简写属性（如 padding(horizontal)）展开为显式的 ArkUI 属性（如 left、right）。
• 结构完整性校验 (Structural Integrity Validation, SIV)： 验证组件放置规则（例如，确保 Blank 组件仅位于 Row 或 Column 等线性布局内部）并修复不平衡的定界符。

核心贡献

1. 基准测试构建： 作者构建了首个文件级的并行 UI 迁移基准测试，包含涵盖八个应用场景（如电子商务、社交媒体）的 100 个样本。这些样本包含经过人工验证在功能和视觉上保持一致性的等效 KJC 和 SwiftUI 代码文件。
2. 实证研究： 对 KJC/SwiftUI 到 ArkUI 的翻译失败进行了全面分析，指出在没有引导的情况下，SOTA LLM 会完全失败，且即使在有骨架引导的情况下，语法错误依然存在。
3. ArkTrans 框架： 提出了专门为声明式 UI 迁移设计的骨架引导且具备后置修复增强功能的翻译框架。
4. 渐进式评估系统： 建立了一个多维评估系统，衡量 代码可执行性（编译成功率）和 视觉保真度（全局指标如 CLIP/颜色直方图，以及局部指标如位置、尺寸、颜色和文本完整性）。

实验结果

作者使用 SOTA LLM（GPT-5.2, DeepSeek-V3.2, Kimi-K2-Turbo, GLM-5）对 ArkTrans 进行评估，并将其与直接提示（Direct Prompting）和单样本提示（One-Shot Prompting）基准进行对比。

• 编译成功率 (Compilation Success Rate, CSR)： 直接提示和单样本提示未能生成任何可编译的文件（0.00% CSR）。相比之下，ArkTrans 实现了 53.33%–90.67% 的 CSR。具体而言，KJC 到 ArkUI 的翻译达到了 90.67%，而 SwiftUI 到 ArkUI 的翻译达到了 53.33%。
• 视觉保真度： ArkTrans 在视觉一致性方面显著优于基准。对于 KJC 到 ArkUI，它实现了 78.89% 的 CLIP 相似度和 56.01% 的颜色直方图相似度。局部指标（位置、尺寸、颜色、文本）也表现出高保真度，其中文本完整性达到 82.50%。
• 消融实验：
  • ArkUI 骨架 是打破 0% CSR 障碍的主要驱动力。
  • 单样本示例 显著提升了性能，尤其是在视觉保真度方面。
  • 后置修复 为可执行性提供了最实质性的提升，解决了阻碍编译的剩余语法错误。
  • 研究发现，提示中的 颜色元数据 对于维持视觉完整性是必不可少的。
• 泛化能力： ArkTrans 在多种 LLM 架构上均展示了有效性，无论底层模型如何，都能持续提升性能，尽管性能会根据模型的固有推理能力略有不同。

重要性与主张

本文声称 ArkTrans 是第一个成功将 UI 迁移作为现代声明式框架之间直接代码翻译问题的方案。作者强调：

• 结构化引导至关重要： 由于“语法差距”和范式转移，简单的提示对于声明式 UI 迁移是不够的。结合骨架构建和基于规则的后置修复对于弥合这一差距是必要的。
• 生态系统丰富： ArkTrans 是一个强大的工具，可以通过自动化将现有的高质量 UI 从 Android 和 iOS 移植到鸿蒙，从而快速丰富鸿蒙软件生态系统。
• 范围有限： 作者承认，虽然基准测试涵盖了代表性场景，但可能无法覆盖所有工业规模的边缘情况。他们还指出，由于 ArkTS 中更严格的类型检查和作用域规则，SwiftUI 到 ArkUI 的迁移比 KJC 到 ArkUI 的迁移更具挑战性。

研究结论认为，ArkTrans 有效缓解了无引导 LLM 翻译中观察到的零成功率障碍，为声明式 UI 迁移提供了一条可行的路径。