Resumen Técnico: Portabilidad de UI Declarativa a HarmonyOS mediante ArkTrans

Planteamiento del Problema

El surgimiento de HarmonyOS ha creado una demanda crítica para la migración de software desde plataformas establecidas como Android e iOS. Sin embargo, el panorama del desarrollo de Interfaces de Usuario (UI) ha pasado de paradigmas imperativos (p. ej., XML, UIKit) a marcos de trabajo declarativos: Kotlin Jetpack Compose (KJC) para Android, SwiftUI para iOS y ArkUI para HarmonyOS. Los enfoques existentes de traducción automática de programas no son adecuados para esta tarea porque se centran principalmente en la lógica de backend o en UIs imperativas heredadas.

La aplicación directa de Modelos de Lenguaje de Gran Escala (LLMs) para traducir KJC/SwiftUI a ArkUI enfrenta dos desafíos salientes:

1. Desconocimiento del Lenguaje de Programación (PL): ArkUI es un marco de trabajo relativamente nuevo (lanzado oficialmente en 2023) con un corpus escaso en plataformas de alojamiento de código en comparación con los PL maduros. En consecuencia, los LLMs de vanguardia (SOTA) carecen de suficientes datos de entrenamiento para dominar la sintaxis específica y el paradigma de programación de ArkUI.
2. Caos Sintáctico Severo: Debido a este desconocimiento, los LLMs tienden a copiar la sintaxis del PL de origen o a mezclar las sintaxis de origen y destino durante la traducción. Estudios empíricos indican que el 40% de los fallos de prompting directo se deben a errores sintácticos, e incluso con guía, más del 50% de los errores sintácticos permanecen sin resolver.

Metodología: ArkTrans

Para abordar estos desafíos, los autores proponen ArkTrans, un enfoque de LLM guiado por heurísticas para la migración automática de UI. ArkTrans opera a través de un pipeline de cuatro etapas:

1. Extracción de Metadatos (ME)

El sistema analiza los archivos de UI de origen (KJC o SwiftUI) en un Árbol de Sintaxis Abstracta (AST) para extraer jerárquicamente metadatos. Filtra la lógica que no es de UI (p. ej., ganchos de ciclo de vida, envoltorios de propiedades) y construye un árbol de UI estructural. Cada nodo en este árbol es una tupla que contiene el tipo de componente, propiedades (pares clave-valor), modificadores (llamadas encadenadas) e hijos. Este proceso aísla la declaración de UI pura del código de soporte (boilerplate).

2. Construcción de Esqueleto (SC)

Utilizando el árbol de UI extraído, ArkTrans sintetiza un esqueleto de ArkUI determinista. Este paso realiza un mapeo de componentes entre PLs utilizando un diccionario predefinido para traducir componentes, propiedades y modificadores conocidos a sus contrapartes de ArkUI. Los elementos desconocidos se preservan como comentarios. El resultado es una estructura de código ArkUI parcial que define la topología de la UI y las restricciones de diseño, asegurando la máxima preservación de los metadatos que no pueden migrarse heurísticamente.

3. Traducción Impulsada por LLM (LT)

Se invoca a un LLM para poblar el esqueleto generado con código ejecutable. La estrategia de prompting incluye:

• Rol de Sistema y Contexto: Proporcionar el esqueleto de ArkUI y las constantes de color extraídas.
• Aprendizaje de un Solo Ejemplo (One-Shot Learning): Suministrar un ejemplo de demostración que traduce un esqueleto similar a código ArkUI. Este ejemplo cubre errores sintácticos comunes (asignación de propiedades, encadenamiento de modificadores, expansión de diseño, gestión de estado) para guiar el aprendizaje en contexto del LLM.

4. Post-Corrección (PF)

Reconociendo que los LLMs aún producen errores sintácticos, ArkTrans aplica un motor de post-corrección basado en reglas. Esta etapa ejecuta transformaciones deterministas basadas en patrones de error revelados empíricamente:

• Inlining de Constantes (CI): Resuelve referencias no resueltas a tokens de diseño externos (p. ej., clases de color) mediante el inlining de valores literales y la eliminación de definiciones de clases no utilizadas.
• Rectificación Léxica (LR): Reemplaza tokens léxicos específicos del PL de origen (p. ej., toInt() en Kotlin) con sus equivalentes en ArkUI (p. ej., Number() en ArkTS).
• Rectificación de Propiedades de Diseño (LPR): Expande propiedades de abreviatura direccional (p. ej., padding(horizontal)) en propiedades explícitas de ArkUI (p. ej., left, right).
• Validación de Integridad Estructural (SIV): Valida las reglas de colocación de componentes (p. ej., asegurar que los componentes Blank solo estén dentro de diseños lineales como Row o Column) y repara delimitadores desequilibrados.

Contribuciones Clave

1. Construcción de Benchmark: Los autores construyeron el primer benchmark de migración de UI a nivel de archivo, consistente en 100 muestras a través de ocho escenarios de aplicación (p. ej., E-commerce, Redes Sociales). Estas muestras incluyen archivos de código KJC y SwiftUI equivalentes, verificados manualmente para consistencia funcional y visual.
2. Estudio Empírico: Un análisis exhaustivo de los fallos de traducción de KJC/SwiftUI a ArkUI, identificando que los LLMs SOTA fallan completamente sin guía y que los errores sintácticos persisten incluso con la guía basada en esqueletos.
3. Marco de Trabajo ArkTrans: La propuesta de un marco de traducción mejorado con construcción de esqueleto y post-corrección diseñado específicamente para la migración de UI declarativa.
4. Sistema de Evaluación Progresiva: El establecimiento de un sistema de evaluación multidimensional que mide tanto la Ejecutabilidad del Código (Tasa de Éxito de Compilación) como la Fidelidad Visual (métricas globales como CLIP/Histograma de Color y métricas locales como Integridad de Posición, Tamaño, Color y Texto).

Resultados Experimentales

Los autores evaluaron ArkTrans utilizando LLMs SOTA (GPT-5.2, DeepSeek-V3.2, Kimi-K2-Turbo, GLM-5) frente a las líneas base de Prompting Directo y Prompting de Un Solo Ejemplo (One-Shot).

• Tasa de Éxito de Compilación (CSR): El prompting directo y el de un solo ejemplo fallaron en generar un solo archivo compilable (0.00% CSR). En contraste, ArkTrans logró una CSR de 53.33%–90.67%. Específicamente, la traducción de KJC a ArkUI alcanzó el 90.67%, mientras que la de SwiftUI a ArkUI alcanzó el 53.33%.
• Fidelidad Visual: ArkTrans superó significativamente a las líneas base en consistencia visual. Para KJC a ArkUI, logró una Similitud CLIP de 78.89% y una Similitud de Histograma de Color de 56.01%. Las métricas locales (Posición, Tamaño, Color, Texto) también mostraron alta fidelidad, con la Integridad de Texto alcanzando el 82.50%.
• Estudios de Ablación:
  • El Esqueleto de ArkUI fue el principal motor para romper la barrera del 0% de CSR.
  • Los ejemplos de un solo paso (One-Shot) mejoraron significativamente el rendimiento, particularmente en la fidelidad visual.
  • La Post-Corrección proporcionó el impulso más sustancial en la ejecutabilidad, resolviendo los errores sintácticos restantes que impedían la compilación.
  • Se encontró que los metadatos de color en los prompts eran indispensables para mantener la integridad visual.
• Generalizabilidad: ArkTrans demostró efectividad a través de diversas arquitecturas de LLM, mejorando consistentemente el rendimiento independientemente del modelo subyacente, aunque el rendimiento varió ligeramente según la capacidad de razonamiento inherente del modelo.

Significado y Reivindicaciones

El artículo afirma que ArkTrans es el primer enfoque que aborda con éxito la migración de UI como un problema de traducción directa de código entre marcos declarativos modernos. Los autores enfatizan que:

• La Guía Estructurada es Crítica: El prompting simple es insuficiente para la migración de UI declarativa debido a la "brecha sintáctica" y los cambios de paradigma. La combinación de la construcción de esqueletos y la post-corrección basada en reglas es necesaria para cerrar esta brecha.
• Enriquecimiento del Ecosistema: ArkTrans sirve como una herramienta poderosa para enriquecer rápidamente el ecosistema de software de HarmonyOS mediante la automatización de la portabilidad de las UIs de alta calidad existentes de Android e iOS.
• Alcance Modesto: Los autores reconocen que, si bien el benchmark cubre escenarios representativos, puede no cubrir todos los casos de borde a escala industrial. También señalan que la migración de SwiftUI a ArkUI sigue siendo más desafiante que la de KJC a ArkUI debido a las reglas de comprobación de tipos y de alcance más estrictas en ArkTS.

El trabajo concluye que ArkTrans mitiga eficazmente la barrera de éxito cero observada en la traducción de LLM sin guía, ofreciendo una vía viable para la migración de UI declarativa.