Dynamic Cross‑Platform (Roma) Architecture and Rendering Process on HarmonyOS

Introduction The article introduces the dynamic cross‑platform solution, referred to as Roma, which enables a single codebase to run on Android, iOS, HarmonyOS, and Web by leveraging a unified JavaScript virtual machine (JS VM) to parse and execute business logic and render views.

Principle Overview Roma follows the same cross‑platform principles as React Native and Weex, extending them with proprietary innovations. Business code is packaged as a JS file, loaded by the JS VM on each platform, which then interprets instructions to invoke native host capabilities for data transfer and view drawing.

HarmonyOS Integration HarmonyOS uses the ArkTS language, which compiles to Ark bytecode (ABC) and cannot directly load JS files. To support Roma, the V8 engine was ported to HarmonyOS, providing a JSVM‑API that offers full JS engine capabilities. The SDK supplies a static library libRomaSdk.so for developers to integrate.

Architecture on HarmonyOS When an app starts, the Roma SDK loads the JS Engine and creates a Jue Instance . This instance manages the runtime environment, including instance creation, task management, virtual DOM (V‑Dom) tree management, and lifecycle handling. A unified JS Engine Interface standardizes interactions across platforms.

Business Example A sample page (ADemo.jue) demonstrates a simple UI with an image and a button that updates the image source and background color. The page is written in a Vue‑like syntax and compiled into ADemo.js for deployment.

Code Example (ADemo.jue) <template style="border-width: 2px;"> <div class="normalClass" style="margin-top: 100px;"> <image class="normalClass" :src="imageUrl" style="height: 200;"></image> <div class="normalClass" :style="{'background-color':bgColor}" style="height:60px;"> <text style="border-width: 2px;width:260px;height:40px;align-self: center;text-align: center;background-color: white;" @click="change()">更新节点数据</text> </div> </div> </template> <script> export default { data() { return { bgColor: "white", imageUrl: "https://static.foodtalks.cn/company/images/434/121logo.png" }; }, methods: { change() { this.bgColor = "red"; this.imageUrl = "https://www.szniego.com/uploads/image/20210202/1612232326.png"; this.updateInstance(); } } } </script> <style scoped> .normalClass { margin: 10px; justify-content: center; align-items: center; align-self: stretch; border-width: 2px; } </style>

Resource Loading Flow The ADemo.jue file is packaged into ADemo.zip , delivered to the client, decompressed, and the resulting ADemo.js is loaded by the JS VM. The flow diagram shows asset retrieval, decryption, and JS execution.

View Rendering Process During rendering, the native side creates three instances (ArkTS, C++, JS) and three threads (UI, background, JS). The JS instance builds a V‑Dom tree, which is sent via JSI to the C++ side to construct a Component Tree, and finally the ArkTS side creates a Render Tree for actual UI rendering. Key steps include creating instances, invoking JRPageManager.createInstance , building V‑Dom nodes with _jr_ydby_new_node_instance , and adding elements to the C++ UI manager via callAddElement .

Update Flow When the button is pressed, the data changes trigger a diff operation that generates a new V‑Dom tree, compares it with the old one, and produces a list of mutations. These mutations are propagated through the same channels to update the Component and Render trees efficiently.

Planning Summary Current implementation uses three threads to avoid blocking the JS and UI threads, but the extra view hierarchy on HarmonyOS and N‑API communication introduce performance overhead. Future work aims to integrate HarmonyOS C‑API directly in the C++ layer to halve the view hierarchy depth and reduce cross‑language costs, improving rendering performance.

Conclusion The Roma solution provides a unified, high‑performance cross‑platform framework that bridges Android, iOS, HarmonyOS, and Web, offering developers a single codebase with native‑level performance and extensibility.