什么是 OpenHarmony——梳理它与 HarmonyOS、HarmonyOS NEXT 的区别

“OpenHarmony 和 HarmonyOS 是同一样东西吗”“HarmonyOS NEXT 上还能运行 Android 应用吗”。这两个问题，需要分开来考虑。

OpenHarmony 是开源的操作系统项目，HarmonyOS 是华为的商用操作系统产品。HarmonyOS NEXT 则是这款商用操作系统去掉 Android 兼容之后那一代的称呼。 先把项目和产品分开，再确认产品的世代，就能把这三个名字相近的东西理清楚。

日文资料里这几者常常混在一起，“鸿蒙＝中国版 Android”“装上 OpenHarmony 就能运行 HarmonyOS 的应用”这类误解已经固化下来。站在为设备挑选操作系统的立场上，这种混乱会造成实际损失。因为无论是要向供应商核实的内容、法务关心的许可证，还是开发者要学的语言，都会随所指对象的不同而完全改变。

本文面向嵌入式设备与业务系统的技术人员，依据 OpenHarmony 官方文档和华为官方发布这两类一手资料，梳理 OpenHarmony / HarmonyOS / HarmonyOS NEXT 三者之间的关系。“能不能成为设备搭载的选项”这一实务判断，放在姊妹篇作为设备搭载的操作系统，OpenHarmony 能否成为选项中讨论。

本文整理的是截至 2026 年 7 月的信息。 下面的数值、版本表和维护计划，也请按这个时间点的记述来读。尤其是世代称呼（NEXT / 5 / 6 / 7）、智能手机与应用市场的地区布局、社区的分支维护计划，都是变动很快的领域。在用于采购或设计决策之前，请打开各节脚注中列出的出处确认日期。

1. 先说结论

OpenHarmony 和 HarmonyOS，公开范围和使用前提都不一样。 OpenHarmony 是由 OpenAtom 基金会（开放原子开源基金会）孵化和运营的项目，源代码任何人都可以获取。HarmonyOS 则是以它为底座、再叠加华为自有框架、应用分发平台和云服务的商用产品，源代码并非全部公开。¹²

谈 HarmonyOS 的时候，还要指明世代。 部署到智能手机上的 2〜4.x 世代，是 AOSP（Android Open Source Project）与 OpenHarmony 组合起来的架构，请把它与去掉 Android 兼容的 NEXT（即 HarmonyOS 5）及以后分开。1.0 则是更早的面向智慧屏的一代。另外，即使应用模型有共通之处，也不能保证 HarmonyOS 的应用能在 OpenHarmony 设备上原样运行（第 4、5 章）。³⁴

在设备上采用时，要确认的不是名字，而是构成与维护。 使用三种系统类型中的哪一种、应用由谁开发、所需年限由谁维护、遵循哪个部件的许可证，这些才是判断材料。欧洲一系的 Eclipse Oniro 也作为另一条脉络单独梳理（第 3、5、7〜9 章）。

按目的选择读法

只想知道区别，就从第 2、4、5 章看起；要考虑在设备上采用，就一直读到第 3、6〜8 章。具体的采用判断，分到了开头介绍的姊妹篇里。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 39 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 把谱系整理成一张图

这一章依次来看“它是谁提供的什么东西”和“它属于哪一代”。OpenHarmony 是项目，HarmonyOS 是商用产品。NEXT 并不是与 OpenHarmony 并列的另一个项目，而是用来区分 HarmonyOS 世代的称呼。

首先，把项目和商用产品分开

不要只拿着“鸿蒙（HarmonyOS）”这个名字往下谈，先确认所指的是下表中的哪一行。

接着，把 HarmonyOS 的世代分开

把表格的行按时间轴重新排列，就能一眼看出“同一个名字的操作系统，内部是在哪里被换掉的”。

timeline
    title HarmonyOS 的世代与 AOSP 的有无
    2019 : HarmonyOS 1.0 : 面向智慧屏
    2021-2024 : HarmonyOS 2〜4.x : AOSP 与 OpenHarmony 混合 : Android 应用可以运行
    2024 : HarmonyOS NEXT ＝ 5 : 移除源自 AOSP 的代码 : Android 应用无法运行
    2025 : HarmonyOS 6 : 去掉“NEXT”这一称呼
    2026 : HarmonyOS 7 : 在 HDC 2026 发布开发者 Beta

图1：HarmonyOS 的世代，以及 Android 应用能否运行的分界线⁴³⁶

分界线是 2024 年的 NEXT（即 5）。请首先确认，公司内部有没有把接触过这条线之前世代的经验，和这条线之后世代的说法混在一起。

从同一底座分出去的 Oniro 也要区分开

以 OpenHarmony 为底座的另一条脉络，是 Eclipse Oniro。详细的定位在第 9 章说明。

换个说法，OpenHarmony 是“原料”，HarmonyOS 和 Oniro 是“用这份原料做出来的两种不同产品”。想一想 Red Hat Enterprise Linux 和 Debian 相对于 Linux 内核的关系，粒度就比较接近了。不过与 Linux 不同的是，OpenHarmony 不只有内核，还包含 UI 框架和应用模型，是一套相当垂直地叠起来的整体。

3. OpenHarmony 的实体——里面装了什么

OpenHarmony 官方文档对这个项目的说明是：“由 OpenAtom 基金会孵化和运营的开源项目，目标是面向全场景智能设备构建开源的分布式操作系统框架”。¹

这一章按部件名称 → 操作系统的层次结构 → 按设备划分的构成 → 设备间协同 → 开发板的顺序来看。同样是“使用 OpenHarmony”，搭载的设备不同，要选的构成也不同。

先确认术语

这里专有名词比较集中，先给出最小限度的对照。

四层架构

架构自下而上依次是内核层、系统服务层、框架层、应用层这四层。¹

• 内核层：采用多内核设计，按设备的资源约束选择 Linux 或 LiteOS。内核抽象层（KAL）屏蔽实现差异，向上层提供统一的进程、内存、文件系统、网络和外设管理。驱动程序写在 HDF（Hardware Driver Foundation）这一自有的统一驱动框架上。
• 系统服务层：分布式软总线（DSoftBus）、分布式数据管理、分布式调度器、多模输入、图形、安全、AI 等。
• 框架层：面向 C/C++/JS 的应用框架和 Ability 框架，以及面向 JS 的 ArkUI 框架。
• 应用层：系统应用和第三方应用。

内核并不固定为一种

这里的重点是，“多内核”这一设计决定了 OpenHarmony 的性格。虽然是同一个名字的操作系统，在 MCU 上跑的是 LiteOS-M，在资源充裕的设备上跑的是 Linux 内核。对“OpenHarmony 的内核是什么”这个问题，有必要反问一句“说的是哪种系统类型”。

三种系统类型

“四层”是操作系统内部的职责划分，“三种系统类型”是按设备裁剪的构成分类。 这是两个不同的维度。官方文档定义了三种基础系统类型。⁸

从 128 KiB 起步，是这款操作系统的独特之处。官方文档也写着“支持从数百 KiB 到 GiB 级的 RAM”。¹ 它采用组件化设计，把不需要的组件从构成中去掉，再逐层搭起来。

分布式能力这一核心理念

官方在介绍 OpenHarmony 的特点时最先提到的，是以 DSoftBus（分布式软总线） 为中心的设备间协同。¹ 它是发现、连接近距离设备并将其组网、不依赖通信方式传输数据的公共底座，在它之上还叠着分布式数据管理（跨设备的数据同步）和分布式调度器（跨设备的应用启动与迁移）。

用在单台设备上时，要看清真正需要的功能

这种“把多台设备当作一台超级终端来使用”的思路，也是 HarmonyOS 在智能手机、平板电脑和车机之间协同体验的基础。反过来说，如果只是嵌入单台设备使用，OpenHarmony 的招牌功能有一半用不上。这一点在采用判断时会起作用。

开发板与硬件

本文参考的是截至 2026 年 7 月的官方列表，其中社区支持的开发板共 22 款。⁹ 按系统类型分别举例，情况如下。

• 面向标准系统：搭载 Rockchip RK3568 的 HiHope HH-SCDAYU200，搭载 NXP i.MX8M Mini 的 MILOS_Standard0。
• 面向小型系统：搭载 STM32MP157A 的 BearPi-HM Micro。
• 面向轻量系统：Hi3861、STM32F407、ESP32、RISC-V 的 HPM6750 等。

其中不只有中国厂商的 SoC，也包含 ST 和 NXP 的芯片。有些产品还写明面向工业用途，例如 MILOS_Standard0 列出的用途就有“工业和医疗领域的高性能测量仪器、工业控制与 HMI、交通、防灾、楼宇”。⁹

4. HarmonyOS 的实体——AOSP 混合期与 NEXT 之后

HarmonyOS 是华为的商用操作系统产品。这里要抓住的是，同样叫“HarmonyOS”，各个世代的内部却不一样。

HarmonyOS 1.0（2019 年）

它最先搭载的不是智能手机，而是智慧屏（Honor Vision）。这一代早于 OpenHarmony 捐赠给 OpenAtom 基金会，并没有作为智能手机操作系统流通。⁴

HarmonyOS 2〜4.x（2021〜2024 年）

这是部署到智能手机上的世代。它是 AOSP 与 OpenHarmony 组合起来的架构，这一代终端既能运行 Android 应用（APK），也能运行 HarmonyOS 应用。日本之所以流传“HarmonyOS 不就是 Android 的中国版吗”这种理解，正是因为这一代的实际情况看上去就是如此。³

HarmonyOS NEXT（即 HarmonyOS 5，2024 年）

AOSP 兼容层和 Android 库被移除，Android 应用不再能运行。能运行的只有 HarmonyOS 原生应用。³

“HarmonyOS 原生应用”并不意味着只能用 ArkTS 来写。 可以组合用 C/C++ 编写的 Native API（NDK）模块，华为自研的语言仓颉（Cangjie）也作为 HarmonyOS 应用开发的选项提供。¹⁰¹¹

HarmonyOS 6 及以后（2025 年〜）

“NEXT”这一称呼被去掉，直接叫 HarmonyOS 6。在 2026 年 6 月 12 日的 HDC 2026（东莞）上，华为宣布 HarmonyOS 7 的开发者 Beta 启动，并公布 HarmonyOS 6 的设备数突破 6600 万台、注册开发者超过 1100 万人、应用市场可获取的应用和服务超过 40 万个、HarmonyOS 已成为中国第二大智能手机操作系统。⁶

不要把 HarmonyOS 的装机量与 OpenHarmony 的商用版本数混为一谈

在同一场发布中，华为还就 OpenHarmony 一侧表示“已发布超过 100 个商用版本”。⁶ 也就是说，对华为而言，OpenHarmony 既是自家智能手机的底座，同时也是其他厂商打造工业产品的供给源。

地区差异要按“终端类型”分开考虑

从日本来看，实务上真正起作用的是地区差异，但把终端一概而论就会判断失误。需要分开的是智能手机与应用分发的生态，以及可穿戴设备等周边设备的固件。

• 智能手机与应用市场以中国为中心。HarmonyOS 6 的产品页面放在面向中国的网站上，¹² 而华为面向全球消费者的网站（consumer.huawei.com/en/harmonyos/）截至 2026 年 7 月仍然是 HarmonyOS 2 的介绍页面。¹³ 面向 NEXT 系智能手机的 HarmonyOS 原生应用及其分发市场，实质上可以当成中国国内的事情来看。
• 另一方面，HarmonyOS 这个品牌也搭载在中国以外的终端上。华为向全球市场的智能手表同样推送了 HarmonyOS 5 系、6 系的固件更新，因此还不能说“HarmonyOS 5 以后＝仅限中国国内”。¹⁴

因此，日本企业如果要谈“开发并分发 HarmonyOS 应用”，那就必然与面向中国市场的业务判断绑在一起。另一方面，OpenHarmony 则不分地区，任何人都可以获取源代码来使用，所以这两件事在决策上应当完全分开对待。

5. “OpenHarmony 应用”和“HarmonyOS 应用”是一回事吗

有共通的语言和应用模型，与应用能原样搬过去，是两回事。 这一章把共通的部分和华为一侧自有的部分分开。

共通的是应用模型的骨架

共通的是 ArkTS（在 TypeScript 基础上扩展的声明式 UI 语言）、ArkUI（声明式 UI 框架）和 Ability（应用的执行单元）所构成的应用模型骨架。翻开 OpenHarmony 6.0 Release 的发行说明可以看到，ArkUI 的布局能力扩展、ArkWeb 的 Chromium 内核从 114 升级到 132、新增 AppServiceExtensionAbility、支持 Kiosk 模式等条目，与 HarmonyOS 的功能新增十分相似。¹⁵

不同的是 SDK、分发平台和云 API

不同的是周边。HarmonyOS 应用是以华为的 HarmonyOS SDK 和 DevEco Studio、以及 AppGallery 这一分发平台和 HMS（Huawei Mobile Services）的云 API 为前提开发的。单独的 OpenHarmony 并不会附带整套华为商用环境。因此，

• 无法把 AppGallery 上的应用装进搭载 OpenHarmony 的自家设备。
• 为 HarmonyOS 开发的应用，也不保证能在 OpenHarmony 真机上原样运行。需要逐个确认所依赖的 API 究竟是华为扩展还是 OpenHarmony 标准。

在设备上要确认应用由谁开发、依赖哪些 API

设备上采用 OpenHarmony 时，正确的做法是按“在它上面运行的应用由己方（或所采用发行版的供应商）开发”这一前提来做规划。若抱着“可以复用中国的应用资产”的期待去做采用判断，就会落空。

6. 版本号与 API 等级的读法

这一章把确认版本号和 API 等级与确认 OpenHarmony 和 HarmonyOS 之间的兼容性分开。编号相近，并不意味着环境相同。

把 OpenHarmony 的版本与 API 等级对应起来

OpenHarmony 的版本都对应着 API 等级，官方文档仓库的 README 里有一份列表。¹⁶

下表是截至 2026 年 7 月参考的 README 上的列表。“最新版本”是该 README 上的归类，仅凭这张表并不能确定当前的最新发行版或维护状况。

把 README 与发行说明索引对照着看

这份列表来自文档仓库的 README，但同一仓库的发行说明索引里还列着更新的 6.1 Release（2026 年 3 月 8 日）以及 6.0.0.1 / 6.0.0.2。¹⁷ 即便是官方文档，“最新版本”的记载也可能没有跟上，所以要确定版本时，不要只看 README，也要看发行说明索引。

即使 API 等级相同，也未必是同一套 API 集合

HarmonyOS 一侧同样标注了 API 等级，华为的开发者文档按版本公开了发行说明。¹⁸ 由于编号体系接近，很容易混淆，但OpenHarmony 的 API Level 20 与 HarmonyOS 的 API Level 20，未必指向同一套 API 集合。确认规格时，请始终留意自己读的是哪一边的文档。

7. 维护周期——做设备的人最先要确认的数字

能取得源代码，和能在所需年限内一直获得修复，是两回事。 这一章按社区的维护方针、各个分支的日期、设备的运行周期的顺序来确认。

首先，确认 Release 与 LTS 的维护方针

OpenHarmony 社区对分支的生命周期（从发布到停止维护的时长）定义如下。¹⁹

• Release 分支的生命周期为 2 年（主动维护 1 年＋被动维护 1 年）
• LTS 分支的生命周期为 3.5 年（主动维护 2 年＋被动维护 1.5 年）
• 主动维护期是社区有计划地发布 tag 版本、修复缺陷和安全漏洞的时期
• 被动维护期不再计划和发布 tag 版本，只修复严重及以上等级的安全漏洞和缺陷

接着，确认所采用分支的维护期限

本文参考的截至 2026 年 7 月的维护计划表如下。²⁰ 这只是表中所列分支的清单，并不意味着 OpenHarmony 整体已经停止维护。

把这张表和发行说明索引合起来看，有 3 点需要确认。

1. LTS 分支最后一个是 3.0-LTS（2021 年 9 月）。在此之前也有过 LTS，发行说明里还留着 1.1.0 LTS（2021 年 4 月）及其系列（1.1.x LTS）。¹⁷ 但 3.1 之后发布的分支全部是 Release，也就是说维护期为 2 年。
2. 表中列出的分支，截至 2026 年 7 月全部已经停止维护。5.x 系和 6.0 Release 还没有出现在这张表里。
3. 这与要运行 10 年的设备的前提，数量级都不一样。与 Windows 11 IoT Enterprise LTSC 2024 支持到 2034 年 10 月、长达 10 年相比，可以看出两者的设计思路本来就不同。

最后，决定由谁来支撑设备的运行周期

这并不是说 OpenHarmony 更差，而是说它没有设想“把社区版原样放进产品然后不管”这种用法。在实际的工业采用中，形式是由商用发行版的供应商自行维护分支，并把这份维护有偿出售。华为说“OpenHarmony 已发布超过 100 个商用版本”，指的正是这一层的厚度。⁶

8. 许可证与获取途径

许可证

OpenHarmony 不是单一许可证的项目，各个仓库并不相同。

嵌入产品时，原则是逐一确认己方实际链接到的那些仓库的 LICENSE。如果笼统地归结为“OpenHarmony 是 Apache 2.0，放心用”，就会漏掉内核部分的 GPL 义务。

把修改与再分发的条件和出货时的声明分开确认

修改和再分发本身，在哪一种许可证下都没有被禁止。 但需要按用到的部分分别满足条件。

Apache 2.0 在允许修改和再分发的同时，要求随附许可证全文、保留版权声明等归属声明、在改动过的文件中注明改动，以及在存在 NOTICE 文件时将其一并传递。⁵

BSD 3 条款要求重新载明版权声明、条件条文和免责声明（只分发二进制时，就写进用户手册等随附材料里），并禁止拿权利人的名称为产品背书。²¹

也就是说，嵌入设备出货时，一定会产生在产品侧准备“许可证声明”的工作。是放在用户手册末尾、机身设置界面的“许可证信息”里，还是放进随附的文本文件，请在设计阶段就决定用哪一种来满足要求。

内核的源代码提供和文档的署名也要确认

如果修改标准系统的 Linux 内核后再分发，还会依据 GPLv2 另外产生提供对应源代码的义务。把文档转载到公司内部资料时，需要按 CC BY 4.0 标注署名。²²

源代码的获取

区分获取开发版的示例与固定到发行版

源代码用和 Android 相同的 repo 工具获取。官方文档记载的步骤如下。² 这个示例用 -b master 获取的是开发版。 要固定到发行版时，就换成后面提到的分支名或标签。

repo init -u https://gitcode.com/openharmony/manifest.git -b master --no-repo-verify
repo sync -c
repo forall -c 'git lfs pull'

托管方面，官方指引了 gitcode.com、gitee.com 和 GitHub 镜像，SSH 与 HTTPS 两种都有。² 想固定到发行版获取时，就把分支名换成 OpenHarmony-6.0-Release 这样的版本名，或者换成标签（refs/tags/OpenHarmony-v6.0-Release）。没有特别的注册或许可手续。

买开发板之前先用 QEMU 确认结构

如果想在买实际开发板之前先确认结构，也备有在 QEMU 上运行这条路径。device_qemu 仓库提供了 Arm Virt（LiteOS-A / Linux）、Cortex-M4（mps2-an386）、Cortex-M55（mps3-an547）、RISC-V（riscv32_virt）、Xtensa（esp32）、C-SKY（SmartL_E802）的模拟步骤。²³

9. 欧洲一系的分支——Eclipse Oniro

以 OpenHarmony 为底座、另行推进扩展的项目

日本的技术人员容易忽略的，是 Eclipse Foundation 运营的 Oniro 项目。项目页面明确写着“Eclipse Oniro for OpenHarmony 构建在 OpenHarmony 的基础层之上，OpenHarmony 是由 OpenAtom 基金会孵化和运营的开源项目”，并给出了面向欧洲及全球市场追加 React Native 支持、基于 Eclipse Theia 的 IDE、Servo 网页引擎等的方针。许可证为 Apache 2.0 和 MIT，项目状态截至 2026 年 7 月为 Incubating。⁷

治理归属的差异与采用风险要分开评估

对于存在“源自中国的操作系统在采购方针上不好办”这类约束的组织来说，知道同一脉络中还有一个处在欧洲基金会治理之下的选项，作为拓宽备选范围是有价值的。不过，它仍处于 Incubating 阶段、社区规模与 OpenHarmony 本体完全不在一个量级，这些会直接成为采用风险。

10. 总结——把三者分开来谈

• OpenHarmony 是 OpenAtom 基金会的开源操作系统项目。它用同一个体系覆盖从 128 KiB 的 MCU 到 128 MiB 以上的高配设备，源代码任何人都可以获取。要考虑是否在设备上采用的，就是它。
• HarmonyOS 是华为的商用操作系统产品。部署到智能手机上的 2〜4.x 世代与 AOSP 混合，能运行 Android 应用；但从 NEXT（即 5）开始 AOSP 被去掉，进入只有 HarmonyOS 原生应用的世界。开发语言并不限于 ArkTS。智能手机与应用市场以中国为中心，但要与可穿戴设备等在海外的布局分开来看（第 4 章）。
• Eclipse Oniro 是以 OpenHarmony 为底座、源自欧洲的一条脉络。截至 2026 年 7 月还处在 Incubating 阶段，但从治理归属这个角度看，它是另一个选项。

把产品的名字区分清楚之后，再依次确认构成、应用的依赖对象、维护责任方和许可证。 这就是把本文接到采用评估上的读法。

一旦能做到不把这三者混为一谈，公司内部的讨论就会具体得多。因为问题可以从“我们要不要采用 HarmonyOS”，翻译成“把 OpenHarmony 的标准系统，配上哪家商用发行版的维护，搭载到哪颗 SoC 上”。再往后的实务判断——把维护周期、硬件选项、开发环境和采购难易度与 Windows IoT、嵌入式 Linux 并排比较——分到了姊妹篇里。

相关文章

• 作为设备搭载的操作系统，OpenHarmony 能否成为选项——与 Windows IoT、嵌入式 Linux 的比较
• 工业用 PC 应该装哪种 Windows——Windows IoT Enterprise / LTSC 实践指南
• Windows 10 停止支持之后的现实解

相关咨询领域

合同会社小村软件承接设备和业务系统所搭载的操作系统与运行平台的选型、既有 Windows 应用能否迁移的判定，以及以长期运行为前提的架构评审。从“有新的操作系统进入候选，但判断材料不够”这个阶段起就可以来咨询。

• 技术咨询与设计评审
• Windows 应用开发
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

OpenHarmony 和 HarmonyOS 是同一样东西吗？

不是同一样东西。OpenHarmony 是由 OpenAtom 基金会（开放原子开源基金会）孵化和运营的开源操作系统项目，源代码任何人都可以获取，并以 Apache License 2.0 等开源许可证发布。而 HarmonyOS 是华为的商用操作系统产品，它以 OpenHarmony 为底座，在其上叠加了华为自有的框架、应用分发平台（AppGallery）和云服务（HMS）。并不是“OpenHarmony 公开了，所以 HarmonyOS 的源代码就能全部读到”，也不是“装了 OpenHarmony 的设备就能安装 AppGallery 里的应用”。把它类比成 Linux 内核与商用 Linux 发行版之间的关系，会比较好理解。

HarmonyOS NEXT 是什么？它与 HarmonyOS 5、6 是什么关系？

HarmonyOS NEXT 是去掉了源自 Android（AOSP）代码的那一代 HarmonyOS 的称呼，就产品版本而言相当于 HarmonyOS 5。部署到智能手机上的 HarmonyOS 2〜4.x 世代，是 AOSP 与 OpenHarmony 组合起来的架构，Android 应用（APK）也能运行（再往前的 HarmonyOS 1.0，是 2019 年面向智慧屏推出的一代）。NEXT 之后不再有 AOSP 兼容层，能运行的只有 HarmonyOS 原生应用。这里说的原生应用并不限于 ArkTS，用 C/C++ 编写的 Native API（NDK）以及华为自研语言仓颉（Cangjie）也都在选项之内。到了随后的 HarmonyOS 6，“NEXT”这一称呼本身不再使用，而是直接叫 HarmonyOS 6。在 2026 年 6 月的 HDC 2026 上，华为发布了 HarmonyOS 7 的开发者 Beta。

用 OpenHarmony 做的设备，能安装 HarmonyOS 的应用吗？

不要认为可以。OpenHarmony 和 HarmonyOS 拥有 ArkTS、ArkUI 这一共同的脉络，API 等级的编号也取值相近，但 HarmonyOS 应用是以华为的 HarmonyOS SDK 和 AppGallery 为前提开发的，单独的 OpenHarmony 环境里并没有这些东西。反过来，为 OpenHarmony 开发的应用也不保证能在 HarmonyOS 真机上原样运行。设备上采用 OpenHarmony 时，请按应用由己方（或所采用发行版的供应商）针对 OpenHarmony 的 API 自行开发这一前提来做规划。

OpenHarmony 的支持周期有多长？

按社区的生命周期策略，Release 分支为 2 年（主动维护 1 年＋被动维护 1 年），LTS 分支为 3.5 年（2 年＋1.5 年）。不过 LTS 分支最后一个是 2021 年 9 月的 3.0-LTS（更早还有 1.1.0 LTS），3.1 之后发布的分支全部是 Release。如果要在工业设备这类以运行 10 年为前提的产品上使用这款操作系统，仅靠社区的维护周期是不够的，需要购买商用发行版供应商的维护服务，或者建立由己方维护分支的体制。

日本的开发者要上手 OpenHarmony，该怎么做？

源代码可以用 repo 工具从 gitcode.com、gitee.com 或 GitHub 镜像获取，不需要账号注册或出口许可之类的特别手续。官方文档提供中文和英文两种，没有日语版。在买实际开发板之前，也可以先在 QEMU 上运行来确认结构。比较现实的做法是，先从英文文档的“Device Development”入口进去，确定要面向的系统类型（轻量/小型/标准）。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。