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

在上一篇文章《什么是开源鸿蒙(OpenHarmony)》中，我们厘清了OpenHarmony、HarmonyOS、HarmonyOS NEXT这三个实体之间的区别。接下来要谈的是实务问题。作为设备搭载的操作系统，OpenHarmony真的能成为一个选项吗？

设备制造商在选择操作系统时，有一些因素会先于功能比较而决定结果。能运行10年的设备，无法搭载只维护2年的操作系统；如果使用的摄像头供应商SDK只提供Windows版本，那么这类操作系统从一开始就不在候选之列。本文将Windows IoT Enterprise LTSC、嵌入式Linux(基于Debian / Yocto)、OpenHarmony三者，从设备的时间轴与采购角度并列比较，并以判断表整理出可以采用的条件与应当放弃的条件。

需要说明的是，本文既不是「推荐使用OpenHarmony的文章」，也不是「劝人放弃OpenHarmony的文章」。我们平时经手的是Windows设备软件，但我们多次见到这样的场景：在没有正确比较各个选项的情况下，仅凭「因为是新技术」或「因为源自中国」就做出了判断。本文的目的是为读者备齐判断所需的材料。

1. 先说结论

• 维护期限是最大的分水岭。OpenHarmony社区的Release分支维护期为2年(主动维护1年＋被动维护1年)，即便是LTS分支也只有3.5年(2年＋1.5年)，这与Windows 11 IoT Enterprise LTSC 2024的10年前提完全不同。¹²
• 而且近年来已不再发布LTS分支。LTS分支在早期确实存在过(1.1.0 LTS、3.0-LTS)，但官方维护计划表中保留的最后一个LTS版本，是2021年9月发布的3.0-LTS。3.1及以后发布的分支全部是Release类型。³⁴
• 因此，把社区版直接原样搭载到产品上的运营模式并不成立。若要采用，就需要购买商用发行版供应商的维护服务，或者自行维护分支并承担直到CVE应对为止的全部工作。华为曾表示「OpenHarmony已发布超过100个商用版本」，这个商用层才是实际的采用去向。⁵
• 资源下限方面，OpenHarmony明显更低。轻量系统最低可在128 KiB的MCU上运行。而Windows 11 IoT Enterprise LTSC面向特定用途设备的最低要求是内存2GB、存储16GB，两者本来就不在同一个量级上。⁶⁷
• 现有的Windows设备软件资产无法直接迁移过来。这里没有与C#/.NET、Win32、COM、WPF/WinForms对应的运行环境，UI要改用ArkTS＋ArkUI，驱动则要改用HDF这一套完全不同的体系。这不是移植，而是重新开发。
• 实际的瓶颈在于供应商SDK。工业相机、运动控制器、PLC通信库的很多产品只提供Windows版本，其次是Linux版本。是否有OpenHarmony对应的驱动，是应当在比较操作系统本身之前就先确认的事项。
• 几乎没有日语的一手资料和支持。官方文档只有中文和英文两种版本，没有日语版。⁸ 团队中要有能够读懂中文或英文技术文档的人员，这实质上是采用的前提条件。
• 确实也存在适合的应用场景。面向中国市场的产品、以多设备协同(DSoftBus)为产品价值核心的设备、希望在带屏IoT设备上使用ArkUI界面的场景，以及希望用同一套体系覆盖从MCU到高性能设备的产品线的场景。⁹

先用一张表汇总「评价维度×选项」的综合判定结果。这是后面各章内容的摘要。符号共分四档：◎=完全适合 / ○=有条件适合 / △=需要注意 / ×=不适合。

如上所示，OpenHarmony得到◎评价的只有资源下限与设备协同这两个维度，而现有资产、SDK、日语资料这三个维度都是×。这种形态并非「优劣之分」，而是说明「能够契合的条件有限」。至于在哪些条件下会契合，第8章的判断表会逐一列出。

2. 统一比较的前提 ── 我们究竟在比较什么

在开始比较之前，先明确比较对象。「操作系统」这个词一旦笼统使用，把处于不同层次的东西并列讨论，就会让论述失焦。

对表中两个术语稍作补充。Yocto并不是一个现成的操作系统，而是一个把「配方」(构建步骤的定义)组合起来、为自家产品构建Linux发行版的框架。LTSC(Long-Term Servicing Channel，长期服务渠道)是Windows的一种发布模式，不引入功能更新，只长期提供安全更新，适合像设备这类希望固定配置的用途。

这里需要把握的一点是，OpenHarmony并不是像Windows IoT那样「买来即可搭载的成品」。就定位而言，它更接近Yocto，是一个「以此为基础，构建自家产品配置」的框架。不过与Yocto不同的是，它把UI框架和应用模型也一并定死了，因此在层级上已经堆叠得更高。

OpenHarmony的系统类型定义如下。⁶

在设备嵌入式开发的语境下，主要的比较对象是标准系统(带HMI的设备)和轻量系统(传感器节点、通信模块)。小型系统则更偏向摄像头类产品的定位。

3. 维护期限比较 ── 哪一个更符合设备的时间轴

嵌入到设备中的PC或主板，需要与设备本体一样，在大约10年的生命周期内持续运行。从这个角度并列比较各个选项，差距一目了然。

本表基于截至2026年7月的各官方信息编制。支持期限与结束日期会被修订，因此在做出采用决定之前，请务必查阅一手资料加以确认。确认渠道如下。

• OpenHarmony：Version Lifecycle Management(生命周期管理政策)与Version Definitions(分支类型与维护计划表)¹³
• Windows：Microsoft Lifecycle(各产品的生命周期)²
• Debian：Debian Wiki LTS¹⁰
• Yocto Project：Releases¹¹

尤其是OpenHarmony，如后文所述，5.x系列与6.x系列目前尚未列入维护计划表。如果要考虑本表中未列出的版本，请以「期限尚未确定」为前提来看待。

还有两点需要进一步说明。

第一点，OpenHarmony的「被动维护期」质量会下降。根据官方的生命周期管理政策，在主动维护期内，社区会有计划地发布带标签的版本，修复缺陷与安全漏洞；而一旦进入被动维护期，就不再有计划性的标签版本发布，只有严重级别以上的安全漏洞和缺陷才会被纳入修复范围。¹ 也就是说，实质上「可以放心使用的期限」应当理解为：Release分支1年，LTS分支2年。

第二点，近年来已不再发布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)。⁴ 此外，5.x系列与6.x系列目前尚未列入这份维护计划表。以10年的设备生命周期为前提来看，「某个分支能获得多长时间的维护」这一点，在每一次发布时都无法预先确定的状态还在持续。

相比之下，Windows 11 IoT Enterprise LTSC 2024采用固定生命周期政策，2034年10月10日这一结束日期从一开始就已确定。² Debian也公布了各版本的常规支持期与LTS期间，Yocto Project同样明确表示LTS版本会获得4年支持。¹⁰¹¹

这并不是说OpenHarmony的质量低。只是这套维护模型本来就没有设想「把社区版原样搭载到产品上、之后放任不管」这种用法。在实际的产业应用中，商用发行版的供应商会自行维护分支，并以付费方式提供维护服务。在考虑采用时应当确认的问题，不是「OpenHarmony的支持期是几年」，而是「该发行版的供应商，会对哪个分支、维护到什么时候、按怎样的SLA提供维护」。

4. 硬件选项

社区公开支持的开发板共有22款。¹³ 挑选出与设备相关性较高的几款，如下表所示。

重要的是，SoC供应商并不只有中国厂商。NXP i.MX8M Mini和ST的STM32系列也被列入支持清单，这对日本的设备制造商来说具有现实意义，因为这意味着有可能用已经有过采用实绩的SoC系列来进行评估。

但同样存在不小的注意事项。

• 支持列表和实际能买到的工业用主板是两回事。这里列出的以评估板为主，OpenHarmony是否官方支持带有10年供货保证的工业用主板，需要另行确认。表中的「目标用途」只是文档上的定位，并不代表供货保证，也不代表在日本国内有流通渠道。
• 能否购到，需要从日本这边逐一确认。这份清单中的开发板以面向中国市场为主，并不一定能通过国内代理商正常购买。在安排评估用样机之前，请就以下三点通过咨询加以确认：(1)开发板供应商的销售页面及跨境电商上的经销情况，(2)国内是否有销售代理商，(3)量产时的最低起订量与供货年限。如果这一步卡住，后续的技术验证就全部无法推进。
• 如果要搭载到自家硬件上，移植工作需要自行完成。换成Windows IoT的话，只需「通过OEM代理商购买许可证，驱动由供应商提供」就能解决，而在OpenHarmony上，这部分工作需要由自己或发行版供应商来承担。
• 驱动的处理方式会因「从哪里调用」而不同。OpenHarmony拥有名为HDF(Hardware Driver Foundation)的统一驱动框架，其设计与平台无关、与内核无关，适用于所有系统类型。⁹ 不过由于标准系统的内核是Linux，因此把现有的Linux内核驱动原样接入、通过V4L2或输入设备等常规Linux接口来使用，这本身是可行的。只有当你希望让OpenHarmony的系统服务或框架通过HDI来处理该设备时，才需要进行适配工作。如果已经有现成的Linux BSP，就不必按「把所有驱动都用HDF重写一遍」来估算工作量。应先决定要向OpenHarmony框架暴露哪些设备，再只把这部分范围计入工时。

另外，即便还卡在开发板采购阶段，验证工作也可以先启动。在购买实机之前，先用QEMU确认系统结构与启动流程的具体步骤，已列在第9章中。此外，如果自家板卡所用的SoC已经确定，比起去寻找评估板，先估算移植到该SoC所需的工时，有时反而更实际。

5. 开发环境与语言 ── 现有资产能否沿用

从设备软件资产的角度来看，问题很单纯。用Windows编写的设备软件，无法直接搬到OpenHarmony上。C#/.NET、Win32、COM、WPF都没有对应的运行环境。UI需要改用ArkTS和ArkUI重写，底层则改用C/C++重写。

更现实的障碍在于供应商SDK的支持状况。工业相机SDK、运动控制器库、PLC通信中间件、图像处理库──这些产品大多首先提供Windows版本，能有Linux版本已经算好的了，这就是现实情况。基本无法期待会提供OpenHarmony版本。因此，

在比较操作系统之前，先列出设备所需的周边设备与中间件清单，逐一确认它们对OpenHarmony的支持状况。

如果不做这一步，只靠操作系统比较表来讨论，后续工程必然会出问题。我们在接受设备软件相关咨询时，也是从制作这份清单开始入手的。

开发环境提供了两个入口：图形化的DevEco Device Tool(在Windows上编辑代码、调试与烧录，在Ubuntu上编译的组合方案)，以及基于CLI的操作流程。¹⁴ 源码获取使用repo工具，官方给出了gitcode.com、gitee.com、GitHub的镜像地址。¹⁵

6. 许可证与知识产权

OpenHarmony并非单一许可证。需要按嵌入范围逐一确认。

如果简单地认为「OpenHarmony是Apache 2.0，所以放心」，就会忽略标准系统内核部分的GPL义务。原则上应当列出要搭载到设备上的各个仓库范围，逐一确认其LICENSE文件。这一点与Windows IoT(仅靠一份商用许可证即可完结)存在实务上的差异。

关于GPLv2补充一点。义务产生的时间点是分发(distribution)之时，而不是改动之时。如果只是在公司内部的验证机上改动内核并运行，并不会产生提供义务；而在把该设备交付给客户的那一刻，就会产生向接收方提供与所分发二进制文件相对应源代码的义务。对设备制造商而言，「交付＝分发」，因此终究还是需要应对，但请注意区分：并非从公司内部试制阶段起就负有公开义务(具体的合规方法请与本公司的法务・知识产权部门确认)。

7. 认证与生态参与

要在产品层面对外宣称「兼容OpenHarmony」，需要通过OpenAtom开源基金会的兼容性测评。其技术基础是OpenHarmony的XTS(X Test Suite)，官方文档中的说明是「提供OpenHarmony兼容性测试套件群，包括当前已支持的应用兼容性测试套件(ACTS)，以及未来将支持的设备兼容性测试套件(DCTS)」。⁹ 也就是说，按照官方文档的表述(截至2026年7月)，目前提供的是ACTS，DCTS属于未来提供的定位。

而另一方面，社区的认证流程资料将XTS描述为ACTS、HATS(硬件抽象层兼容性)、DCTS三部分构成，这与官方文档的表述并不一致。¹⁹ 不过申请者自行进行适配开发与自测、并附上测试报告提交申请，这一流程本身在两者之间是共通的。

在估算工时时，请不要把DCTS当作必需要求来预设。哪些套件在申请时会被实际要求，最保险的做法是直接向认证窗口确认。这种「官方文档与社区资料不一致」的状况，再加上没有日语一手资料这一点，都应当作为采用时的沟通成本预先计入。

如果只是用于公司内部验证或单次性的设备，认证并非必须；但如果是对外宣称兼容性的产品，或者希望被视为生态一员的产品，通过认证就是前提条件。这是应当从一开始就纳入工时估算的项目。

8. 判断表 ── 可以采用的条件，应当放弃的条件

在进入判断表之前，先用一张图梳理通往判断结果的判定流程。确认前提的顺序很重要，先看市场・产品需求，后做技术评估。即便技术上能够实现，如果无法通过合同把维护固定下来，也不能搭载到设备上。

flowchart TD
    S["选择设备搭载的操作系统"]
    Q1["是否面向中国市场的产品，或者<br/>需求明确要求兼容OpenHarmony"]
    Q2["基于DSoftBus的多设备协同，<br/>是否是产品价值核心"]
    Q3["周边设备与中间件的供应商SDK<br/>能否在OpenHarmony上凑齐<br/>不足部分能否自行开发"]
    Q4["维护能否通过合同固定下来<br/>商用发行版供应商，<br/>或自建直到CVE应对的体制"]
    Q5["是否有能够读懂中文或英文<br/>技术文档的人员"]
    OH["正面评估OpenHarmony<br/>通过商用发行版渠道采购"]
    OTH["选择Windows IoT LTSC或嵌入式Linux<br/>依据现有资产与供应商SDK的支持情况决定"]
    NG["放弃OpenHarmony"]

    S --> Q1
    Q1 -->|"是"| Q3
    Q1 -->|"否"| Q2
    Q2 -->|"是"| Q3
    Q2 -->|"否"| OTH
    Q3 -->|"凑齐 / 可自行开发"| Q4
    Q3 -->|"凑不齐"| NG
    Q4 -->|"可以固定"| Q5
    Q4 -->|"无法固定"| NG
    Q5 -->|"有"| OH
    Q5 -->|"没有"| NG
    NG --> OTH

图1：是否采用OpenHarmony的判定流程。各分支的依据对应下方判断表的各行

在这些分支中，实际上因Q3(供应商SDK)和Q4(维护合同)而被淘汰的案例最多，这正是本文想要传达的主旨。下面的判断表，是把此图中的各个分支展开为具体情况后的结果。

9. 若决定采用，首先要做的事

如果判断表的结果偏向「采用」，着手顺序如下。

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的manifest(指定标签是可靠的做法)，建立公司内部镜像，打造出即使5年后也能重新生成相同二进制文件的状态。¹⁵ 上游托管以gitcode.com为主这一点，从业务连续性的角度来看，也是应当拥有自建镜像的理由之一。
5. 清点许可证。列出要嵌入范围内的各个仓库，梳理Apache 2.0 / BSD / GPL各自的义务。
6. 谈判维护合同。与商用发行版供应商就「维护哪个分支、维护到什么时候、按怎样的SLA」通过合同固定下来。如果这一点无法确定，就应当搁置采用的决定。
7. 判断是否需要兼容性测评(XTS)。如果要对外宣称兼容性，就应当从一开始就把相应工时计入计划。

10. 总结

• OpenHarmony在技术上具有逻辑自洽的设计，用同一套体系覆盖从128 KiB的MCU到128 MiB以上的高性能设备，并标配设备协同(DSoftBus)。也存在面向工业用途的支持开发板，其中包括NXP和ST的SoC。
• 但从设备10年生命周期的角度来看，社区维护期(Release 2年、LTS 3.5年)明显不够，而且LTS分支自2021年的3.0-LTS之后就再未发布过。若要采用，前提是要有商用发行版供应商的维护支持。
• 对日本的设备制造商而言，实质性的采用条件有三个：(1)供应商SDK是否支持OpenHarmony，(2)公司内部是否有能读懂中文或英文技术文档的人员，(3)是否有能通过合同固定维护的供应商。只要缺少其中任何一项，Windows IoT Enterprise LTSC或带商用支持的嵌入式Linux都更符合设备的时间轴。
• 反过来，对于面向中国市场的产品、设备协同是产品价值核心的产品，以及希望用同一套体系覆盖从MCU到高性能设备的产品线，则值得正面加以评估。

操作系统选型并非「哪个更优秀」的问题，而是「哪个更契合设备的时间轴、采购与人员配置」的问题。关于Windows一侧的选型标准，已整理在《工业用PC应该安装哪种Windows》一文中。

相关文章

• 什么是开源鸿蒙(OpenHarmony) ── 梳理它与鸿蒙(HarmonyOS)、HarmonyOS NEXT 之间的关系
• 工业用PC应该安装哪种Windows ── Windows IoT Enterprise / LTSC 实践指南
• Windows 10 停止支持后的现实解决方案 ── ESU・LTSC・更换设备的判断表
• 用信息亭模式固化业务终端 ── Assigned Access・Shell Launcher 的选择方法与运维设计

相关咨询领域

合同会社小村软件承接设备搭载运行基础的选型支持、现有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 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。