国际视角看 OpenHarmony 开发

出品丨GOSIM 开源创新汇

OpenHarmony 对于所有中国开发者而言，可谓是非常熟悉。据官方数据统计，截至 2024 年 6 月 30 日，OpenHarmony 社区已经累计超过 7900 名贡献者，共 70 家共建单位，产生 37 万多个 PR ，2.6 万多个 Star ，8.3 万多个 Fork ，59 个 SIG 。 

在 GOSIM 2024 欧洲站的 APP&WEB 论坛，一直致力于 OpenHarmony 开发的 Jonathan Schwender 为全球开发者深入分享了《面向下一代移动的 OpenHarmony》主题演讲。

作为华为德累斯顿研究中心的软件工程师，Jonathan 一直致力于鸿蒙内核、可信执行环境 SDK 和 OpenHarmony 操作系统的项目开发。同时，他也是 Corrosion 开源项目和高效并发组件库 libvsync 的维护者。

以下是 Jonathan Schwender 演讲的主要内容

OpenHarmony 并不是 Android

HarmonyOS 是华为手机、平板、智能手表等设备所使用的操作系统。关于它的新闻流传已久，被称为全新的操作系统。但细心的使用者可能会发现，Android 应用仍然可以在 HarmonyOS 上运行。难道只是重新命名的 Android 吗？Jonathan 在此否认了这一说法：OpenHarmony 并不是 Android，两者完全无关。

OpenHarmony 是 HarmonyOS 应用所依赖的新框架。当你为 OpenHarmony 编写一个应用，它不仅能在 HarmonyOS 上运行，也能在其他第三方的发行版上运行。两者的关系，类似Linu与Fedora。

不过，今年年底，HarmonyOS 将迈进下一阶段：彻底移除 Android 兼容层。这意味着只有 OpenHarmony 应用能在 HarmonyOS 手机上运行。此外，在内核抽象层，开发者不一定以 Linux 内核为基础，而可以依据一个轻量级的操作系统。

Jonathan Schwender 随后谈到了 OpenHarmony 的其他发行版。虽然大多才刚起步，但已经有很多第三方厂商在尝试创建自己的发行版，涉及到很多领域，如矿业、商业领域等，有的甚至尝试融入教育应用和政府终端。目前大多数聚焦在中国。

应用迁移势不可挡

Jonathan Schwender 表示，用 ArkUI 和 ArkTS 重写应用程序十分重要。如果要发布一款搭载 HarmonyOS 的手机，每个人都会期待它能覆盖自己喜欢的应用。Jonathan Schwender 指出，中国正在大力推动近 5000 款排名靠前的应用迁移到 HarmonyOS，这将打造一个更大的生态系统库，有助于创建新应用。HarmonyOS 的另一个关键特征是其拥有一个定制内核，不基于 Linux 运行，但仍然可兼容。

华为目前投入大量精力进行大规模迁移工作，Jonathan Schwender 进一步阐述了迁移进展：5000 个应用中，已有 4000 个应用正在或已经完成迁移，剩下的 1000 个应用也正在与开发者讨论以实现迁移。

Jonathan Schwender 表示应用迁移工作的另一个关键点是流行于中国的小程序。小程序使得大量应用触手可及，一个超级应用，如微信，即可拥有所有小程序。他还提到，TypeScript 语言可以使迁移工作更加顺畅，并解释了 ArkTS 或 TypeScript 变体使 TypeScript 变成一种更好语言的原因。

揭秘 OpenHarmony 的开发流程

OpenHarmony 的开发是什么样的呢？Jonathan Schwender 介绍道，有一个官方的 IDE ，基于 JetBrains ，类似于 Android Studio 。由于没有得到官方支持，目前缺少 Rust 插件，希望未来能添加这一功能。

他展示了创建项目到运行的流程。样板项目开始生成后，就可以得到很多文件。在构建配置文件中，人们可以在 HarmonyOS 或 OpenHarmony 运行操作系统之间切换。但包的签名会影响运行与否。理论上，OpenHarmony 应用可以在所有 OpenHarmony 的设备上运行，但出于安全考虑，应用必须被签名，签名是否被信任取决于 OpenHarmony 的发行版。

Jonathan Schwender 还分享了 OpenHarmony 应用的情况。基本上而言，一个应用的发型可以包含至少一个 HAP（HarmonyOS Ability Package）。

大多数情况下，只会含有一个 HAP。一个 HAP 对应一个能力阶段，可以包含多个 UI 能力或扩展能力（指那些没有界面的功能）。假设现在有一个 UI 能力，包含多个页面。在开发应用时，可以预期有很多源数据文件、通用元数据和包清单。重要的是，在你的模块下方有一个 json5 文件用于模块描述，eTS 中有你的类型脚本文件，CPP 中有你的潜在原生代码。

eTS 文件夹包含了模块的能力和页面，通常会包含用 ArkTS 编写的 UI 能力。ArkTS 基本上是一种严格的 TypeScript 风格，非常高性能与高效，旨在易于阅读并防止常见错误。

在 ArkTS 中，必须进行强制初始化。此外，要求所有类型在编译时是已知的。ArkTS 还可以实现 ArkUI 特定的扩展。当人们想构建一个用户界面时，它的扩展十分简单易懂。ArkTS 还增加了额外的内置组件，方便使用者将不同对象组合起来，从而得到一个可组合的用户界面。

随后，Jonathan Schwender 举例展示了 C++ 代码。使用过 Node API 的人会很熟悉所涉及到的样板代码。首先要利用构造函数注册函数，随后可以提取构造函数大部分内容的实际参数。

在 Rust 方面，宏可以帮助抽象掉很多冗余内容。那如何集合已经构建起来的 Rust 库呢？Jonathan Schwender 介绍了最简单的方法之一，就是进行手动预构建，并将其放置在 IDE 会查找的特定路径下，然后通过设置 IDE 来调用 cargo 构建并复制它。也可以使用 corrosion ，因为我们知道 C / C++ 代码使用 CMake 构建。

他本人负责维护 corrosion 的 CMake 模型——在 Windows、Linux、Mac 上运行得都还不错。它能够基本查看 cargo 元数据，然后自动导入任何具有静态库或动态 CDY 库的 Crates ，可以自动设置正确的链接器和 Rust 编译器目标，因此在幕后为人们做了很多额外的工作。但总的来说，目前最可靠的方法是直接在 IDE 或其他工具中添加一个构建脚本，并将其复制到硬编码的库路径中。

Servo 在 OpenHarmony 上如何实现？

Jonathan Schwender 继续介绍了 Servo 。Servo 是一个用 Rust 编写的运行引擎，主要的 Servo 组件大约有 240k 行 Rust 代码，但它也有很多依赖项。如果查看列表，你会发现它有超过 700 个 Rust 和 C++ 依赖项。用 cargo vendor 计算总代码量，发现大约有 400 万行 Rust 代码和各自超过 100 万行的 C 和 C++ 代码。其中面临的一个挑战是如何处理包括 cc-rs、CMake、autotools 的多个构建系统。在 UI 方面表现较好，只需要一个浏览器窗口，不需要后退按钮或前进按钮。

那么，构建或迁移一个应用需要多少工作量呢？Jonathan Schwender 详细解释了步骤：第一步，创建一个依赖于 LibServo 的虚拟库，暴露所有库，并解决所有的编译与链接错误。接着，弄清楚构建 C / C++ 依赖所需的所有环境变量，因此必须设置诸如 C 编译器 、C++编译器 、链接器、PKG 配置等。第二步，对那些无法构建的 Rust 依赖项进行同样的处理。最后，有时确实需要针对 OpenHarmony 以不同方式实现东西，比如窗口的大小。作为第一步，可以先简单地创建一个桩，解决编译错误，了解工作量。接下来，解决链接错误，通常是从源码构建库，之后就可以将应用刷入设备。

Jonathan Schwender 又谈到了 XComponent 组件——OpenHarmony 用于渲染原生窗口的组件。在最简单的情况下，只需创建一个 X 组件，就可以原生地渲染到窗口。

随后，他在自己的手机上展示了 Servo 浏览器在 OpenHarmony 上的运行情况。他指出，由于目前还没有实现屏缓冲区外的部分，所以一些尚未解决的问题会导致崩溃。这些问题主要集中在 WebGL 支持方面。此外，缺少 Fling 支持，且无法回调到 ArkTS ，ArkTS UI 目前还无法工作。

总结与未来工作

Jonathan Schwender 在演讲的最后对一些所需要的改动进行了总结。他认为，将 ArkTS 转换为 LibServo 布局非常简单。由于交易系统的存在，仅需回调实现一些交易，也可以将它们实现为无操作，留待以后处理。 

特定于操作系统的窗口初始化更具挑战性，但文件可以稍作改进，整体来说 OpenHarmonyOS 的文档非常不错。因为 OpenHarmonyOS 在字体处理方式上与 Android 和 Linux 不同，字体加载方式仍需调整。总体来说，Rust 在 OpenHarmony 上的支持相当不错，但仍需一些类似于 Android 的手动工作，需要下载一个 SDK ，预构建标准库。

对于未来的工作，Jonathan Schwender 表示，希望能让 Rust 真正成为 OpenHarmony 代码的首选语言，让宏能正常运作，力争上游。他还计划制作更多的绑定，以便可以安全地访问所有 OpenHarmony API 。另一个重要的工作是创建一个可重复使用的 GitHub CI 操作，并在 QEMU 中运行。最后，他期望在未来继续探索将 async-runtime 与 function flow runtime kit（FFRT）整合，实现基于 coroutine 的调度。