OpenHarmony 能否成为设备搭载的操作系统——与 Windows IoT、嵌入式 Linux 的比较

是否把 OpenHarmony 列入设备操作系统的候选，要先看维护、SDK 和开发人员，而不是先看功能多少。要运行 10 年的设备，不能直接搭载社区维护 2 年就结束的版本。如果需要的相机 SDK 只有 Windows 版，使用这款相机的方案同样不成立。

本文面向设备制造商，比较 Windows IoT Enterprise LTSC、嵌入式 Linux（基于 Debian / Yocto）和 OpenHarmony。首先把比较对象放到同一层面上，然后按能否支撑产品寿命、能否迁移现有资产、能否推进到量产与出货的顺序逐项确认。在此基础上，用判断表整理出可以采用的条件与应当放弃的条件。

我们平时处理的是 Windows 设备软件，但本文既不是一概推荐 OpenHarmony，也不是一概否定它。判断的依据不是“因为是新技术”或“因为源自中国”，而是它是否契合设备的时间轴、采购和人员。OpenHarmony、HarmonyOS、HarmonyOS NEXT 三者的区别本身，请参阅上一篇《什么是 OpenHarmony》。

本文比较的技术信息与维护计划以 2026 年 7 月为基准。支持期限、支持的开发板和认证要求都会变化，因此对于实际采用的版本和产品，请在做判断之前向一手资料和供应商确认。

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

1. 先说结论：把采用条件和选择理由分开考虑

OpenHarmony 的优势在于能覆盖到很小的设备，以及用标准机制处理多设备协同。另一方面，在现有 Windows 资产、工业领域的供应商 SDK 和日语一手资料方面存在明确的限制。¹²³

采用需要满足下面 3 个条件。只要有一条无法满足，就优先选择 Windows IoT Enterprise LTSC 或带商业支持的嵌入式 Linux。反过来，即使 3 个条件都齐备，也不等于就此决定采用 OpenHarmony。还要同时确认产品需求与 OpenHarmony 的优势相符，以及能够开发和维护这个产品。

flowchart TB
    accTitle: 区分采用条件与产品得到的好处
    accDescr: 把契合产品需求的好处与维护、SDK、人员这些落地条件分开，对照两方面来判断是否采用。
    requirements["设备的市场与产品需求"] --> value["选择 OpenHarmony 的理由"]
    requirements --> conditions["维护、SDK、人员的条件"]
    value --> check["对照两方面判断采否"]
    conditions --> check

图1：把能够运行的条件和选择的理由分开考虑。

按目的选读

综合比较在 2.3 节，分情况的推荐在 7.2 节。即便是判断表中推荐的用途，也不能省略上面这 3 个条件。

2. 把比较对象放到同一层面：只看操作系统的名字无法比较

2.1. Windows IoT、Debian、Yocto、OpenHarmony 各自的定位

首先要对齐的，是使用现成的操作系统产品，还是使用构建自家产品操作系统的基座这一区别。把两者混在一起，就会漏掉为了产品化而必须由自己承担的工作。

Yocto 不是现成的操作系统，而是把配方（对构建步骤的定义）组合起来，构建自家产品所用 Linux 发行版的框架。LTSC（Long-Term Servicing Channel）是 Windows 的一种提供模式：不引入功能更新，长期提供安全更新，适合像设备这样希望固定配置的用途。

OpenHarmony 同样不是 Windows IoT 那种“买来装上去就能用的成品”。它的定位接近 Yocto，属于用基座构建自家产品配置的那一类选项。不过与 Yocto 不同的是，它连 UI 框架和应用模型都一并提供，因此是一套连上层也包含在内的体系。

flowchart TB
    accTitle: 现成的操作系统产品与构建产品配置的基座
    accDescr: 采购商用操作系统产品的路径，与从项目基座出发构建自家产品配置的路径，各自承担的工作并不相同。
    os["搭载到设备上的运行基座"] --> product["采购商用操作系统产品"]
    os --> project["选择开发基座"]
    project --> config["构建产品用的配置"]
    config --> scope["确定自家与供应商的分工"]

图2：同样是操作系统选型，采购成品与自行搭建配置所负责的范围并不相同。

2.2. 内存下限要放在同一系统类型下解读

OpenHarmony 有轻量、小型、标准 3 种系统类型。¹

带 HMI 的设备主要以标准系统为比较对象，传感器节点和通信模块则以轻量系统为比较对象。小型系统的定位更偏向摄像机类产品。

相对于轻量系统最低 128 KiB，Windows 11 IoT Enterprise LTSC 面向特定用途设备的最低要求是内存 2GB、存储 16GB。一般的嵌入式 Linux 也以带 MMU 的处理器和数十 MB 以上的 RAM 为前提。OpenHarmony 能用同一套体系覆盖到 MCU 领域，这是很大的差别。¹⁴

不过，这并不意味着标准系统的应用能在 128 KiB 上运行。轻量系统用 LiteOS-M，小型系统用 LiteOS-A，标准系统用 Linux，内核和运行环境都不一样。不要认为“既然都是 OpenHarmony，同一个应用就能换着搭载”，而要从产品所需的系统类型出发来选择。

flowchart TB
    accTitle: 从系统类型出发确定运行环境
    accDescr: 先确定产品所需的系统类型，再确认内核与应用的运行环境，不要仅凭内存下限判断应用兼容性。
    need["产品所需的功能"] --> type["确定系统类型"]
    type --> kernel["确认内核与运行环境"]
    kernel --> app["开发适配该环境的应用"]
    minimum["最小内存的数值"] -.-> caution["并不保证应用兼容性"]

图3：128 KiB 这个下限，并不意味着标准系统的应用可以原样运行。

2.3. 综合比较：用同一组维度看优势与限制

在对齐比较对象之后，列出 6 个评价维度。符号分为 ◎=直接契合 / ○=有条件契合 / △=需要注意 / ×=不契合 4 个等级。这张表是对各章说明的归纳，并不是适用于所有设备的优劣排序。

OpenHarmony 拿到 ◎ 的是资源下限和设备协同这 2 个维度，现有资产、SDK、日语资料这 3 个维度则是 ×。这并不是说它是“差的操作系统”，而是说需要挑选采用条件相符的产品。

面向中国市场的产品、以设备发现和数据同步、应用流转为价值核心的产品、使用 ArkUI 的带屏 IoT 设备，以及希望用一套体系覆盖从 MCU 到富设备的产品线，都值得考虑。具体采否可以对照第 7 章的判断表确认。²

flowchart TB
    accTitle: 把综合比较表套到产品需求上
    accDescr: 不要只凭比较表的评价决定操作系统，而要套到产品的核心价值与限制上，再进入采否判断。
    table["通过综合比较掌握优势与限制"] --> req["套到自家产品的需求上"]
    req --> fit["对照 SDK、维护与人员"]
    fit --> decision["进入第 7 章的分情况判断"]

图4：不是去数评价符号，而是套到自家产品的条件上。

3. 敲定维护：确认承担方、结束日期和修复范围

3.1. 首先确定由谁承担产品的维护

比较维护的目的，不是判定 OpenHarmony 本身质量的高低，而是说明把社区版原样搭载到运行 10 年的产品上再放任不管，这种做法不成立。

要采用，就得购买商用发行版的供应商维护服务，或者自行维护分支并承担到 CVE 修复为止的工作。在工业领域的采用中，由供应商自行维护分支并有偿提供的商用层，才是实际的采购对象。华为在 2026 年 6 月的说明中也提到，OpenHarmony 已发布超过 100 个商用版本。⁹

因此，应当问的不是“OpenHarmony 会支持多少年”，而是“这个发行版的哪个分支，维护到什么时候，按什么 SLA 维护”。如果维护条件敲不下来，那么即使技术上能跑起来，采用判断也要搁置。

flowchart TB
    accTitle: 衔接社区维护与产品寿命的承担方
    accDescr: 不要把社区版原样搭载到长期运行的产品上就放任不管，而应由供应商或自家承担产品寿命所需的维护。
    life["产品寿命所需的维护"] --> vendor["签订供应商维护合同"]
    life --> own["自行维护分支并修复 CVE"]
    vendor --> terms["确定分支、结束日期与 SLA"]
    own --> terms
    terms --> adopt["夯实采用判断的前提"]

图5：要问的不是整个操作系统的年数，而是所采购分支及其维护条件。

3.2. 不看总年数，而看结束日期能否覆盖设备的运行期限

嵌入设备中的 PC 和板卡，被要求按与设备本体相同的 10 年左右生命周期持续运行。下面就按这个时间轴比较各操作系统的维护。

本表依据 2026 年 7 月时点的各方官方信息。不仅要看年数，还要确认到表中结束日期为止的时间能否覆盖设备的运行期限。支持期限和结束日期会被修订，因此在做采用判断之前要核对的一手信息如下。

• OpenHarmony：Version Lifecycle Management（生命周期管理策略）和 Version Definitions（分支类别与维护计划表）。⁸¹¹
• Windows：各产品的 Microsoft Lifecycle。⁵
• Debian：Debian Wiki LTS。⁶
• Yocto Project：Releases。⁷

flowchart TB
    accTitle: 对照设备的运行期限与操作系统的维护结束日期
    accDescr: 不仅看操作系统的支持年数，还要确认所采用版本的结束日期能否覆盖设备的运行期限。
    device["设备计划的停用时间"] --> compare["对照结束日期"]
    osend["所采用版本的维护结束日期"] --> compare
    compare --> enough{"能否支撑运行期限"}
    enough -->|"不够"| contract["考虑维护合同或其他选项"]
    enough -->|"够用"| scope["再确认修复范围"]

图6：不要只看“10 年支持”这个说法，而要把该版本的结束日期和设备的运行计划相比。

3.3. 把主动维护和被动维护分开来看

OpenHarmony 的 Release 分支是主动维护 1 年＋被动维护 1 年，LTS 分支是主动维护 2 年＋被动维护 1.5 年。请不要只看合计年数就下判断。⁸

基于这一差别，本文认为实质上“可以放心使用的期间”应当按 Release 1 年、LTS 2 年来估计。社区维护的总年数，与可以期待高强度维护的期间是两回事。⁸

flowchart TB
    accTitle: OpenHarmony 维护阶段的变化
    accDescr: 主动维护阶段有计划地提供 Tag 版本，被动维护阶段的修复范围和提供方式受限，最后进入维护结束。
    active["主动维护"] --> passive["被动维护"]
    passive --> eol["维护结束"]
    active -.-> regular["有计划的 Tag 版本与修复"]
    passive -.-> limited["修复严重及以上的漏洞与缺陷"]

图7：同在维护期限之内，后半段也未必继续提供同样范围的修复。

3.4. 确认所采用分支的记载

在本文参照的 2026 年 7 月这个时点，近年并没有再拉出 LTS 分支。官方维护计划表中列出的最后一个 LTS 是 3.0-LTS（2021 年 9 月），3.1、3.2、4.0、4.1 都是 Release。¹¹

并不是一开始就没有 LTS。发行说明索引中还保留着 1.1.0 LTS（2021 年 4 月）及其系列，但它们都已 End of Life。3.0-LTS 的系列同样有记载，3.1 以后则都是 Release 类别。¹²

此外，同一时点的维护计划表中没有 5.x 系列和 6.x 系列的记载。不要用其他版本去断定表中没有的版本的维护期限。应当以期限尚未确定为前提，逐一确认该版本的情况。

Windows 11 IoT Enterprise LTSC 2024 采用固定生命周期，结束日期已确定为 2034 年 10 月 10 日；Debian 公布了常规支持和 LTS 期限，Yocto Project 公布了 4 年的 LTS 支持。相比之下，OpenHarmony 需要逐个确认“所采用的分支会维护到什么程度”。⁵⁶⁷

flowchart TB
    accTitle: 不要推断表中没有的版本的维护
    accDescr: 先查维护计划表中是否列有所采用的版本，没有记载时不要套用其他版本的期限，而要单独确认。
    branch["确定所采用的版本与分支"] --> listed{"维护表中是否有记载"}
    listed -->|"有"| dates["确认该版本的期限与结束日期"]
    listed -->|"没有"| ask["视为期限未定并单独确认"]
    ask --> hold["维护条件敲定前搁置判断"]

图8：不要凭 LTS 这个名称或其他版本的年数，去断定未列出版本的维护情况。

4. 调查能否迁移：SDK、应用、驱动程序与人员

4.1. 比较操作系统之前，先盘点依赖的 SDK

工业相机、运动控制器、PLC 通信、图像处理等 SDK 与中间件，很多都是先有 Windows 版，其次能有 Linux 版就不错。面向 OpenHarmony 的提供，从一开始就不是可以指望的状况。

因此，第一项工作是下面这轮盘点。

列出设备所需的外围设备和中间件，逐一确认它们对 OpenHarmony 的支持情况。

如果缺少必需的 SDK，而缺的部分又无法自行开发，那么这套方案就放弃采用 OpenHarmony。先只看比较表上的功能做出选择、再去调查 SDK，方案会在后续工序中垮掉。我们接受设备软件咨询时，也是从制作这份清单开始的。

flowchart TB
    accTitle: 从必需的 SDK 缩小操作系统候选
    accDescr: 列出设备所需的外围设备和中间件，在没有 OpenHarmony 版 SDK 时确认缺少的部分能否自行开发。
    devices["列出外围设备与中间件"] --> sdk{"必需的 SDK 是否齐备"}
    sdk -->|"齐备"| next["进入移植范围的确认"]
    sdk -->|"不齐备"| make{"缺少的部分能否自行开发"}
    make -->|"能"| next
    make -->|"不能"| stop["该设备方案下放弃采用"]

图9：既没有 SDK 又无法自行补齐时，继续比较功能，设备方案也不会成立。

4.2. Windows 设备软件无法原样搬过去

把开发体系的差别并列出来，就能看清对现有资产的影响。

用 C#/.NET、Win32、COM、WPF/WinForms 编写的 Windows 设备软件，在 OpenHarmony 上实质等于重写。因为没有与之对应的运行环境，UI 要改成 ArkTS＋ArkUI，底层要改成 C/C++，这是另一套体系。

如果以沿用现有资产为前提，换到 Windows IoT Enterprise LTSC 更现实。选择嵌入式 Linux 时，Windows 的 UI 等同样要重写，但 C/C++ 的测量与控制逻辑较容易移植，只要把范围限定在已提供所需 Linux 版 SDK 的设备上，就可以纳入考虑。

另外，表中 OpenHarmony 的驱动程序一栏写的是 HDF，但这并不意味着现有的 Linux 驱动程序全都要重写。从普通 Linux 接口使用与从 OpenHarmony 框架使用之间的区别，在下面的 4.3 节说明。

flowchart TB
    accTitle: 划分现有 Windows 资产的迁移范围
    accDescr: 把原样沿用现有 Windows 软件的路径，与为其他操作系统重写 UI 和运行环境的路径分开，在 Linux 上则确认 SDK 的提供情况和 C/C++ 逻辑的可移植性。
    assets["现有 Windows 设备软件"] --> reuse["原样沿用现有资产"]
    assets --> port["为其他操作系统重写"]
    reuse --> windows["考虑 Windows IoT LTSC"]
    port --> scope["划分 UI、运行环境与 SDK"]
    scope -.-> logic["在 Linux 上考虑复用 C/C++ 逻辑"]

图10：更换操作系统时，不要把 UI 与运行环境、测量与控制逻辑、SDK 混为一谈。

4.3. 区分使用 Linux 驱动程序的路径与适配 HDF 的工作

OpenHarmony 的 HDF（Hardware Driver Foundation）是与平台无关、与内核无关的统一驱动基座，适用于全部系统类型。²

另一方面，标准系统的内核是 Linux。因此，把现有的 Linux 内核驱动程序集成进来，并从 V4L2、输入设备这类普通 Linux 接口使用，本身是可行的。

如果已有 Linux BSP，就不需要按“把全部驱动程序用 HDF 重写”来估算。先确定哪些设备需要向 OpenHarmony 框架公开，再把这部分范围计入工时。

另外，即便还没采购开发板，也可以先用 QEMU 确认结构和启动流程。相关入口以及采用后的着手顺序，汇总在第 8 章。

flowchart TB
    accTitle: 复用 Linux 驱动程序与适配框架
    accDescr: 在标准系统上使用现有 Linux 驱动程序时，按是从普通 Linux 接口使用，还是经由 HDI 向 OpenHarmony 框架公开，来区分额外的工作。
    driver["标准系统的 Linux 驱动程序"] --> normal["普通 Linux 接口"]
    driver --> hdi["经由 HDI 使用"]
    normal --> direct["集成现有驱动程序的方案"]
    hdi --> adapt["向 OpenHarmony 一侧适配"]
    adapt --> framework["系统服务与框架"]

图11：不是重写全部驱动程序，而是估算需要向 OpenHarmony 一侧公开的范围。

4.4. 准备开发环境，以及能读技术文档的人员

设备开发的入口是图形界面的 DevEco Device Tool 和 CLI。DevEco Device Tool 的形态是并用方式：在 Windows 上编辑代码、调试和烧录，在 Ubuntu 上编译。获取源代码使用 repo 工具，官方给出了 gitcode.com、gitee.com 和 GitHub 的镜像。¹³¹⁴

官方文档只有中文和英文两种，没有日语版。社区讨论和商用发行版的供应商也以中国一方为主，能用日语获得一手支持的窗口很有限。有人能读完中文或英文技术文档，不是开发启动后的辅助条件，而是实质上的采用条件。³

flowchart TB
    accTitle: 源代码获取与设备开发的运行环境
    accDescr: 使用 repo 获取的源代码进行设备开发时，有 CLI 和 DevEco Device Tool 两个入口，后者把 Windows 上的编辑、调试、烧录与 Ubuntu 上的编译组合起来。
    source["用 repo 获取源代码"] --> cli["用 CLI 开发"]
    source --> ide["DevEco Device Tool"]
    ide --> win["在 Windows 上编辑、调试与烧录"]
    ide --> ubuntu["在 Ubuntu 上编译"]

图12：除了准备工具，还需要能够持续阅读中文或英文技术文档的团队。

5. 确认能否采购：支持的开发板与量产条件

5.1. 支持的开发板中也包括 NXP 和 ST 的 SoC

本文参照的社区支持开发板清单共 22 款。下面摘出其中可能与设备相关的型号。¹⁵

SoC 供应商并不只有中国厂商。其中也有 NXP i.MX8M Mini 和 ST 的 STM32 系列，日本的设备制造商有可能在自己已经采用的 SoC 系列上进行评估。

不过，这张表给出的是文档中设想的用途。它并不保证 10 年的供货、在日本国内的流通，也不保证 OpenHarmony 官方支持量产用的板卡。

flowchart TB
    accTitle: 区分支持清单与量产的采购条件
    accDescr: 支持开发板清单只是技术评估的入口，并不保证日本国内流通、供货年限以及对量产板卡的官方支持。
    list["支持开发板清单"] --> candidate["技术评估的候选"]
    candidate --> sale["确认实际销售与日本国内流通"]
    sale --> supply["确认量产批量与供货年限"]
    list -.-> note["并不是长期供货的保证"]

图13：清单上有名字，与在产品寿命期间都能采购到，是两件需要分别确认的事。

5.2. 订购评估板之前，先确认采购条件

清单上以评估板为主，其中不少面向中国市场，未必能在日本国内的代理商处正常买到。订购评估板之前，要问清下面 3 点。

1. 开发板供应商的销售页面或跨境电商是否有售。
2. 日本国内是否有销售代理商。
3. 量产时的最小批量和供货年限是怎样的。

即使列在支持清单里，如果采购不到需要的板卡，真机上的技术验证也推进不下去。请在确认操作系统维护期限的同时，一并确认板卡的供货条件。

如果要搭载到自研板卡上，移植工作由自家或发行版厂商承担。这与在 Windows IoT 下从 OEM 代理商采购许可证、使用供应商提供的驱动程序相比，负责的范围不同。如果 SoC 已经确定，那么与其去找评估板，不如估算向该 SoC 移植的工时，有时这样更实际。

flowchart TB
    accTitle: 评估板与自研板卡分开准备
    accDescr: 使用评估板时要调查获取难度和量产条件，使用自研板卡或已确定的 SoC 时要估算移植的承担方与工时。
    hardware["产品所用的硬件"] --> board["考虑使用评估板"]
    hardware --> own["自研板卡或已确定的 SoC"]
    board --> procure["确认获取难度与量产条件"]
    own --> port["确认移植承担方与工时"]
    procure --> plan["结合操作系统维护一起规划"]
    port --> plan

图14：采购计划里不只有评估板的购买，还要包含搭载到产品硬件上的工作。

6. 确认出货的条件：许可证、认证与生态

6.1. 逐一确认所集成范围的 LICENSE

OpenHarmony 并非单一许可证。要列出集成到产品中的仓库，按范围逐一确认。

如果笼统地认为“OpenHarmony 是 Apache 2.0，所以没问题”，就会漏掉标准系统中 Linux 内核部分的 GPL 义务。与通过商业许可证采购操作系统的 Windows IoT 相比，实务上的差别也体现在这种逐个组成部分确认许可证的工作上。

flowchart TB
    accTitle: 从产品包含的范围出发确认许可证
    accDescr: 不要把整个 OpenHarmony 视为一个许可证，而应列出集成到产品中的仓库，确认各自的 LICENSE 以及分发时的应对。
    product["集成到产品中的构成"] --> repos["列出相关仓库"]
    repos --> licenses["确认各个 LICENSE"]
    licenses --> delivery["梳理分发时的应对"]
    delivery --> legal["与法务和知识产权部门确认"]

图15：不要只凭 Apache 2.0 下判断，而要按实际集成的每个组成部分逐一确认。

6.2. 区分修改内核与把设备分发给客户

GPLv2 产生义务的时点不是修改的时候，而是分发（distribution）的时候。只是在公司内部的验证机上修改内核并运行，不会产生提供源代码的义务。

把设备交付给客户时，就产生了向接收方提供与所分发二进制文件对应的源代码（含修改部分）的义务。对设备制造商来说“交付＝分发”，因此在量产和交付环节必须处理。请把并非从公司内部试制阶段起就有公开义务与向客户交付时必须处理这两件事分开。具体的合规做法，要与本公司的法务和知识产权部门确认。

flowchart TB
    accTitle: 区分公司内部修改内核与向客户分发
    accDescr: 在考虑 GPLv2 的源代码提供义务时，要把仅限公司内部使用的情形，与把含有内核二进制文件的设备分发给客户的情形分开。
    kernel["包含 Linux 内核的构成"] --> internal["仅限公司内部验证与使用"]
    kernel --> distribute["把设备分发给客户"]
    internal --> no["仅内部修改不产生提供义务"]
    distribute --> corresponding["按要求提供对应的源代码"]

图16：把修改的时点与向客户交付设备的时点分开，逐一确认义务。

6.3. 区分能跑起来与自称兼容 OpenHarmony

除了许可证方面的处理之外，还要确认对外声明兼容性所需的手续。

6.3.1. 公司内部验证与产品的兼容性声明

只是公司内部验证或用在单台设备上时，不需要兼容性认证。反之，若要以产品的身份对外宣称“兼容 OpenHarmony”，或者希望被视为生态的一员，就要按通过 OpenAtom 基金会兼容性测评的前提来估算工时。

技术基础是兼容性测试套件群 XTS（X Test Suite）。流程是由申请方完成适配开发和自测，附上测试报告后提交申请。²¹⁹

flowchart TB
    accTitle: 声明兼容性的产品的认证准备
    accDescr: 对外宣称兼容 OpenHarmony 的产品，要确认被要求的测试，准备适配开发、自测与报告，再向兼容性测评提交申请。
    claim["声明兼容 OpenHarmony"] --> required["确认申请时点的测试要求"]
    required --> test["适配开发与自测"]
    test --> report["准备测试报告"]
    report --> apply["向兼容性测评提交申请"]

图17：在公司内部确认过能运行，与可以声明产品的兼容性，并不是一回事。

6.3.2. ACTS、HATS、DCTS 要结合资料差异来确认

在本文参照的 2026 年 7 月这个时点，不同资料对 XTS 的构成说法不一。

官方资料把 DCTS 归为将来提供，社区资料则把它当作现有构成部分来说明。不要预设 DCTS 是必需项，请向认证窗口确认申请时点实际要求的套件。这种记述上的差异，以及没有日语一手资料，都会变成采用时的沟通成本。²¹⁹

6.4. 确认客户要求的生态与采购方针

如果客户要求的是 AppGallery 分发或与 HarmonyOS 应用的协同，OpenHarmony 无法满足这些要求。AppGallery、HMS 和 HarmonyOS SDK 都不包含在 OpenHarmony 中，也不保证 HarmonyOS 应用的兼容性。需要的是支持 HarmonyOS 的产品和 HarmonyOS SDK，这与“兼容 OpenHarmony”的认证是两回事。

flowchart TB
    accTitle: 区分兼容 OpenHarmony 与 HarmonyOS 的要求
    accDescr: 先区分客户要求的是兼容 OpenHarmony，还是 AppGallery 分发与 HarmonyOS 应用协同，后者应按支持 HarmonyOS 的产品与 SDK 的要求来处理。
    customer["客户提出的要求"] --> oh["兼容 OpenHarmony"]
    customer --> harmony["AppGallery 分发与 HarmonyOS 协同"]
    oh --> cert["OpenHarmony 的兼容性测评"]
    harmony --> commercial["支持 HarmonyOS 的产品与 SDK"]

图18：OpenHarmony 的兼容性认证，替代不了 HarmonyOS 一侧的分发与协同要求。

在采购方针上，也要区分针对运营主体的限制和针对代码来源的限制。若属于前者，处于欧洲基金会治理之下的 Eclipse Oniro 系可以列入候选，但在本文的基准时点 2026 年 7 月它仍是 Incubating，社区规模也无法与 OpenHarmony 本体相比。若属于后者，即“不得包含源自中国的代码”，由于 Oniro 同样构建在 OpenHarmony 的基座层之上，限制并不会因此解除。

flowchart TB
    accTitle: 针对运营主体的限制与针对代码来源的限制
    accDescr: 区分采购方针针对运营主体和针对代码来源的两种情形，并确认即便是欧洲治理的 Oniro，代码源自 OpenHarmony 这一条件也不会改变。
    policy["采购方针的限制"] --> governance["运营主体与治理"]
    policy --> origin["代码的来源"]
    governance --> oniro["有条件地考虑 Oniro 系"]
    origin --> remain["换成 Oniro 也无法解除限制"]
    oniro -.-> maturity["同时确认 2026 年 7 月时点的成熟度"]

图19：不要把更换运营主体和更换代码来源混为一谈。

7. 决定采否：对照产品需求与能够承担的条件

7.1. 从市场与产品需求开始依次判断

确认前提的顺序是先看市场与产品需求，后做技术评估。在此之上，再确认 SDK、维护，以及能读技术文档的人员。即便技术上做得出来，只要维护条件没敲定，就无法决定在设备上采用。

flowchart TB
    accTitle: 把 OpenHarmony 作为设备操作系统采用的主要判定
    accDescr: 先确认市场要求或设备协同的价值，再确认 SDK、维护和能读技术文档的人员，条件无法满足时则考虑 Windows IoT 或嵌入式 Linux。
    S["选择搭载到设备上的操作系统"] --> Q1["是否面向中国市场或被指定兼容"]
    Q1 -->|"是"| Q3["SDK 是否齐备或能否自行开发"]
    Q1 -->|"否"| Q2["设备协同是否为产品价值的核心"]
    Q2 -->|"是"| Q3
    Q2 -->|"否"| OTH["Windows IoT LTSC / Linux"]
    Q3 -->|"齐备 / 能自行开发"| Q4["能否敲定维护条件"]
    Q3 -->|"不齐备"| NG["放弃 OpenHarmony"]
    Q4 -->|"能敲定"| Q5["是否有人能读中文或英文"]
    Q4 -->|"不能敲定"| NG
    Q5 -->|"有"| OH["正式考虑 OpenHarmony"]
    Q5 -->|"没有"| NG
    NG --> OTH
    OH -.-> vendor["通过商用发行版采购"]
    OTH -.-> assets["按现有资产与 SDK 支持情况选择"]

图20：以市场与产品需求为入口，依次核对 SDK、维护和人员的条件。

实际上，在 Q3（供应商 SDK）和 Q4（维护合同）处无法满足条件的项目很多，这就是本文的主旨。此图给出的是主要判定的流程。MCU 用途、产品线统一、采购方针等个别条件，要结合下面的表一起判断。

7.2. 分情况的判断表

表中的支持年数是各版本的生命周期。是否与设备的运行期限相符，请结合第 3 章的结束日期一并确认。另外，即便是表中推荐使用 OpenHarmony 的用途，也不等于可以免去 SDK、维护和人员方面的条件。

8. 如果仍是候选，用 7 项工作把它落到实处

如果在判断表中仍然留作候选，就进入下面 7 项工作。在 QEMU 或真机上跑起来了，与作为产品可以采用，是两回事。在维护条件尚未确定的情况下，不要仅凭技术验证成功就敲定采用。

1. 盘点外围设备和中间件。确认相机、I/O、通信、运动控制、图像处理等是否支持 OpenHarmony。如果在这里卡住，推进其他工序就没有意义。
2. 确定系统类型。在轻量、小型、标准之中定下一个。内核（LiteOS-M / LiteOS-A / Linux）和应用的写法都会随之改变。
3. 用 QEMU 确认结构。在购买真机之前，可以在 device_qemu 的 Arm Virt（LiteOS-A / Linux）、Cortex-M4、Cortex-M55、RISC-V 等环境上确认构建与启动的流程。²⁰
4. 固定维护分支，确保构建可复现。固定 repo 的清单（指定 tag 最为可靠），自建内部镜像，做到 5 年后仍能重新生成同样的二进制文件。上游托管以 gitcode.com 为主，从业务连续性的角度看，这也是需要自建镜像的理由。¹⁴
5. 盘点许可证。列出要集成的仓库，梳理 Apache 2.0 / BSD / GPL 各自的义务。
6. 谈妥维护合同。与商用发行版的供应商敲定“维护哪个分支、维护到什么时候、按什么 SLA”。谈不拢就搁置采用判断。
7. 判断是否需要兼容性测评。如果要对外宣称兼容 OpenHarmony，就从一开始把基于 XTS 的适配开发、自测和申请的工时计入预算。

flowchart TB
    accTitle: 把技术验证接到产品的采用条件上
    accDescr: 先确定外围设备和系统类型并用 QEMU 确认结构，再把构建可复现性、许可证、维护合同和认证必要性敲定，然后进入采用判断。
    inventory["盘点设备与 SDK"] --> type["确定系统类型"]
    type --> qemu["用 QEMU 确认结构与启动"]
    qemu --> reproduce["固定分支与构建可复现"]
    reproduce --> conditions["确认许可证、维护与认证"]
    conditions --> decision["作为产品的采用判断"]

图21：不要止步于运行验证，还要把将来的重新构建和出货后的维护落到实处。

8.1. 小结：选择契合设备时间轴、采购与人员的操作系统

OpenHarmony 用一套体系覆盖从 128 KiB 的 MCU 到 128 MiB 以上的富设备，并标准内置基于 DSoftBus 的设备协同，在技术上是条理清晰的设计。面向工业用途的支持开发板中，也包含 NXP 和 ST 的 SoC。¹²¹⁵

另一方面，对于要运行 10 年的设备，社区维护的 Release 2 年、LTS 3.5 年明显不够。再加上在本文的基准时点，3.0-LTS 之后没有再拉出 LTS，因此在没有商用发行版的维护、也没有自行完成 CVE 修复的团队时，它并不是一个可以采用的选项。⁸¹¹¹²

日本的设备制造商应当确认的是所用设备的 SDK、能读技术文档的人员，以及支撑产品寿命的维护。这些条件不齐备时，Windows IoT Enterprise LTSC 或带商业支持的嵌入式 Linux 更现实。反过来，如果中国市场的要求、设备协同、从 MCU 到富设备的体系统一直接关系到产品价值，那么 OpenHarmony 就值得正式考虑。

操作系统选型不是判断“哪个更优秀”，而是判断哪个契合设备的时间轴、采购和人员。Windows 一侧的选型标准，整理在《工业用 PC 应该安装哪种 Windows》中。

相关文章

• 什么是 OpenHarmony——梳理它与 HarmonyOS、HarmonyOS NEXT 的区别
• 工业用 PC 应该安装哪种 Windows——Windows IoT Enterprise / LTSC 实践指南
• Windows 10 停止支持后的现实解决方案
• Windows 信息亭模式（Assigned Access）实务指南

相关咨询领域

小村软件有限公司提供设备运行基座的选型支持、现有 Windows 设备软件能否迁移的判定，以及以长期运行为前提的架构评审。从“有新的操作系统进入候选，但公司内部没有可供比较的材料”这个阶段起，就可以来咨询。

• 技术咨询与设计评审
• 软实时 Windows 应用程序开发
• Windows 应用程序开发
• 联系我们

参考链接

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

工业设备的操作系统可以采用 OpenHarmony 吗？

取决于条件。决定性因素是维护期限的处理方式：OpenHarmony 社区的 Release 分支生命周期为 2 年（主动维护 1 年＋被动维护 1 年），即使是 LTS 分支也只有 3.5 年。把社区版原样搭载到运行 10 年的设备上，安全修复会在产品寿命的中途停止。要采用，前提是购买商用发行版的供应商维护服务，或者自行维护分支并具备完成 CVE 修复的团队。如果准备不出这样的团队，Windows IoT Enterprise LTSC（10 年）或商用嵌入式 Linux 的长期支持合同更契合设备的时间轴。

OpenHarmony 和嵌入式 Linux 哪个更轻？

OpenHarmony 的下限更低。OpenHarmony 的轻量系统可以在 Arm Cortex-M 和 32 位 RISC-V 的 MCU 上、最低 128 KiB 内存下运行，小型系统为 1 MiB 以上，标准系统为 128 MiB 以上。一般的嵌入式 Linux 以带 MMU 的处理器和数十 MB 以上的 RAM 为前提，因此能用同一套操作系统体系覆盖到 MCU 领域是 OpenHarmony 的特点。不过轻量系统的内核是 LiteOS-M，与标准系统所用的 Linux 在运行环境上完全不同，所以请注意，并不是“同一个操作系统，所以同一个应用就能跑”。

现有的 Windows 设备软件能移植到 OpenHarmony 吗？

实质上等于重写。用 C#/.NET、Win32、COM、WPF/WinForms 编写的设备软件，在 OpenHarmony 上没有与之对应的运行环境。UI 要改用 ArkTS＋ArkUI，底层要改用 C/C++，驱动程序则要改用 HDF（Hardware Driver Foundation）这一套不同的体系重写。此外，工业相机和运动控制器的供应商 SDK 往往只提供 Windows 版（其次是 Linux 版），这才是移植中真正的瓶颈。如果以沿用现有资产为前提，换到 Windows IoT Enterprise LTSC，或者把范围限定在已提供 Linux 版 SDK 的设备上使用嵌入式 Linux，更为现实。

要宣称支持 OpenHarmony，需要什么认证吗？

要以产品的身份自称“兼容 OpenHarmony”，需要通过 OpenAtom 基金会的兼容性测评（认证）。技术基础是 OpenHarmony 的 XTS（X Test Suite）这一测试套件群。不过具体构成因资料而异：2026 年 7 月时点的官方文档写的是“当前已支持的 ACTS（应用兼容性测试套件）和未来将支持的 DCTS（设备兼容性测试套件）”，而社区的认证流程资料则在此基础上加入 HATS（硬件抽象层兼容性）来说明。估算工时时，不要预设 DCTS 是必需要求，而应向认证窗口确认申请时点实际要求的套件。只在公司内部验证使用时不需要认证，但对外宣称兼容性的产品则必须认证。

日语方面的支持和资料有多少？

官方文档只有中文和英文两种，没有日语版。社区讨论也以中文为主。商用发行版的供应商同样以中国企业为主，能用日语获得一手支持的窗口很有限。因此，公司内部有人能读完中文或英文技术文档，实质上就是采用的条件。与 Windows 和主流 Linux 发行版相比，这一点是明显的差距。

作者简介

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

Go Komura

小村软件有限公司 代表

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