当前位置:首页>鸿蒙APP>知识驱动、自动修复:东北大学团队为开源鸿蒙 C/C++软件库移植打造自动化工具链——开源技术课题成果展播第5期

知识驱动、自动修复:东北大学团队为开源鸿蒙 C/C++软件库移植打造自动化工具链——开源技术课题成果展播第5期

  • 2026-10-15 13:17:10
知识驱动、自动修复:东北大学团队为开源鸿蒙 C/C++软件库移植打造自动化工具链——开源技术课题成果展播第5期

🔹课题名称:面向OpenHarmony平台的C/C++软件库自动移植技术

🔹挑战方向:以用户为中心、场景感知的应用软件新形态

🔹揭榜年份:2025年

🔹揭榜单位:东北大学开源鸿蒙技术俱乐部

🔹课题负责人:王莹,东北大学开源鸿蒙技术俱乐部主任、教授

1

C/C++软件库的跨平台移植挑战

随着信息技术的自主可控需求日益增强,国产操作系统生态建设已成为国家战略的重要组成部分。开源鸿蒙作为面向全场景的分布式操作系统,正逐步构建起覆盖各类智能终端的底座能力。然而,一个操作系统的成功不仅取决于内核与框架的先进性,更依赖于丰富、高质量的软件生态——尤其是大量成熟、高性能的C/C++软件库,如图形处理、音视频编解码、网络通信等,它们是上层应用开发的基石。

当前,这些软件库主要基于Linux/GNU生态开发。将其高效、正确地移植至开源鸿蒙上,是快速补齐其底层软件供应链的关键路径。然而,移植工作面临一系列独特且严峻的挑战。开源鸿蒙社区虽提供了Lycium交叉编译框架以简化构建流程,但缺乏自动化诊断跨平台不兼容性(CPI)问题并生成适配代码的能力。开发者面临“错误信息诊断难”与“适配方案制定难”的双重困境——移植工作高度依赖人工经验,效率低下、质量参差不齐,严重制约了生态库的规模化引入。

东北大学软件学院王莹教授团队揭榜的“面向OpenHarmony平台的C/C++软件库自动移植技术”课题,正是面向这一场景展开攻关。团队提出了一套知识驱动的自动化移植技术方案CROSS2OH,通过大规模实证研究归纳CPI问题根因、构建结构化适配知识库、研发静态分析驱动的自动诊断与补丁生成工具,实现了从“人工反复调试”到“一键自动适配”的范式转变。目前课题已顺利结题,相关成果发表于ASE 2025(CCF A类会议),工具已成功完成40个来自主流移动应用的核心C/C++库的移植,其中29个已通过开源鸿蒙社区审核并合入仓库。

·

2

这事儿为什么难?主要源于以下三大核心挑战

课题组在深入研究后发现,从Linux到开源鸿蒙的C/C++库移植面临一系列由系统架构根本性差异引发的挑战,主要体现在三个层面:

🔹第一,系统库与运行时环境差异显著。 Linux标准发行版依赖GNU C库(glibc)及标准内核系统调用,而开源鸿蒙采用Musl C库(musl)并对Linux内核进行了深度定制与裁剪。两者在原生API支持范围、头文件包含路径、文件系统层次结构等方面存在显著不同。例如,开源鸿蒙不支持部分Linux特有的系统调用接口,头文件组织方式与glibc存在差异,某些硬件平台的电量读取等底层接口的精度和可用性也不尽相同。这些差异在交叉编译过程中会引发大量编译错误,而错误信息往往晦涩难懂,难以直接定位根因。

🔹第二,构建系统不兼容性突出。 主流C/C++库通常基于CMake/Make构建,而开源鸿蒙的官方构建框架为GN+Ninja,其交叉编译工具链在字符符号性、指令集架构配置、条件编译宏、C++语言标准要求等方面均有特殊设定。开发者需要手动将CMake构建逻辑转换为GN构建配置,处理ISA相关的编译选项差异,配置C++版本标准,并确保条件编译宏能够正确识别开源鸿蒙平台——任何一个环节的疏漏都可能导致编译失败或运行时异常。

🔹第三,移植过程高度依赖人工经验,缺乏系统化指导。 目前,开源鸿蒙社区虽提供了Lycium交叉编译框架以简化构建流程,但其本质上是一个构建辅助工具,而非智能化的移植助手。当编译错误发生时,开发者只能凭借自身经验逐条分析错误日志、查阅文档、尝试修改代码,反复迭代直至编译通过。这一过程不仅耗时费力,而且质量参差不齐——经验丰富的开发者可能需要数天完成一个库的移植,而新手可能因无从下手而放弃。更关键的是,每次移植积累的经验和解决方案散落在个人手中,无法被系统化复用,导致“重复踩坑”现象普遍存在。

·

3

东北大学团队为此提出系统化方案

面对这三大挑战,团队采用“实证研究驱动+知识库构建+静态分析自动化”的综合研究方法,设计了一套从问题诊断到补丁生成的全自动移植工具链。方案的核心逻辑可以概括为:先通过大规模实证研究摸清CPI问题的类型与规律,再构建结构化的跨平台适配知识库,最后基于静态分析实现问题的精准定位与补丁的自动生成。

🔹实证研究:先摸清“敌人”底细

在动手解决问题之前,团队首先对开源鸿社区中已成功移植的92个C/C++库进行了大规模实证研究。研究思路是“逆向工程”——收集这些库的适配补丁(*.patch文件),移除补丁后使用Lycium重新交叉编译,观察编译过程产生的错误日志,通过分析错误类型和补丁代码来归纳CPI问题的根因。

通过这一方法,团队从201个真实CPI实例中识别出Linux与开源鸿蒙的差异可归为三大核心方面——系统库/运行时环境、构建系统、第三方库版本要求——并进一步细化为八个具体维度的CPI问题类型。在此基础上,深入分析开发者的适配代码,总结出解决这八类问题的八种通用适配策略,涵盖了从API替换、头文件路径映射到编译配置调整等多个层面。这一系统性分类体系和适配策略库,为后续的自动化诊断提供了精确的“靶点”和“弹药”。

🔹适配知识库:将专家经验结构化

有了对问题类型的系统认知,团队着手构建结构化的跨平台适配知识库。知识库的内容涵盖四个层面:开源鸿蒙不支持的305个原生API及其替代方案、1599个头文件的物理路径映射、平台特定的构建逻辑与编译器环境配置、以及18万余条已移植库的API签名信息。这一知识库如同一位资深移植专家的“经验大脑”——它知道哪些API在开源鸿蒙上不可用、该用什么替代,知道glibc特有的头文件路径在musl环境下应该映射到哪里,也知道不同平台下编译选项和宏定义应该如何调整。

🔹CROSS2OH工具链:让移植从“手工作坊”走向“自动化流水线”

在知识库的支撑下,团队研发了核心工具CROSS2OH,其技术流程分为三个步骤:

🔹问题定位。 工具利用Tree-Sitter解析C/C++源码的抽象语法树,识别原生API调用并与知识库进行交叉比对,发现不支持的API调用;通过正则表达式匹配识别glibc特有的逻辑路径模式(如sys/、gnu/、bits/),定位路径不兼容问题;静态分析char变量的定义和赋值,检测字符类型符号性配置问题;同时静态分析CMakeLists.txt、Makefile等构建文件,提取ISA编译选项、C++版本设置和条件编译宏,检查是否存在开源鸿蒙特有的配置缺失。

🔹适配方案生成。 针对定位到的每种问题类型,查询知识库中对应的适配策略,自动生成代码片段。例如,对于不支持的API调用,自动替换为知识库中记录的等价替代API;对于逻辑路径,自动映射为开源鸿蒙兼容的物理路径;对于字符类型符号性问题,自动在构建配置中注入-fsigned-char选项。所有适配代码最终被封装为符合开源鸿蒙社区规范的*.patch文件。

🔹技术增强。 除了核心的CPI问题修复,CROSS2OH还针对实证研究中发现的移植痛点进行了功能增强:自动识别库的构建方法(CMake/Make/Autotools)并解析依赖声明;自动修正非标准安装命令和路径重定向;针对64位整数在不同平台下格式化符不一致的问题,自动推荐并使用inttypes.h中的标准化宏。这些增强功能进一步降低了移植过程中的人工介入需求。

·

4

成果验证:从实验室走向真实应用生态

课题成果已在多个维度得到验证。

评估指标方面,以111个真实C/C++库为基准进行测试,CROSS2OH在CPI问题解决上实现了94.2%的召回率和90.7%的精确率,远超人工移植的效率和稳定性。

实用性验证方面,团队从Google Play Store热门应用列表中选取了下载量破亿的流行应用(如微信、Microsoft Excel、Bilibili、Trip.com等),通过BinaryAI工具追溯其依赖的C/C++开源库,最终确定了48个在Linux环境下可编译通过的候选库。CROSS2OH成功完成了其中40个库的交叉编译,并通过了开源鸿蒙开发板的内置测试流程,整体适配成功率达83.3%。这些成果已提交PR至OpenHarmony-SIG仓库,其中29个已通过官方审核并完成代码合入。

学术影响力方面,相关论文《CROSS2OH: Enabling Seamless Porting of C/C++ Software Libraries to OpenHarmony》已被ASE 2025(CCF A类会议)正式接受并发表。工具及数据集已开源。

课题组寄语

知难而进,做生态拓荒的“破壁者”

从Linux到开源鸿蒙,看似只是一次跨平台编译,实则是系统底层逻辑的深刻重构。当海量成熟的C/C++软件库横亘在生态迁移之路上,我们深知,靠人工逐行调试、反复“踩坑”的传统方式,无法支撑起一个新兴操作系统对丰富软件生态的迫切渴求。

因此,我们选择了一条“知识驱动、智能修复”的攻关之路。回首课题攻关的日日夜夜,我们团队面对的是数百个真实CPI问题的迷雾、数万条API差异的鸿沟,以及构建系统天壤之别的挑战。我们没有选择捷径,而是以实证研究为“探照灯”,逆向剖析每一个移植补丁背后的逻辑;以结构化知识库为“大脑”,将专家的宝贵经验固化为可复用的资产;最终,CROSS2OH工具链的诞生,让移植工作从依赖个人经验的手工作坊,迈向了“一键诊断、自动生成补丁”的自动化流水线。

展望前路,生态建设永无止境,我们深知当前成果只是万里长征的第一步。正如陈海波老师所说,未来五年,智能化将成为终端操作系统发展的主旋律,开源鸿蒙正从千行百业走向千家万户,加速迈向全球。未来,我们将持续追踪鸿蒙SDK的演进,将CROSS2OH深度融入社区构建工具链,并推动更多三方库的规模化适配与长期维护。我们期待,有更多开发者能加入这场生态共建的接力赛中,用智慧和工具,共同跨越平台壁垒,让开源鸿蒙的软件生态之树更加枝繁叶茂。

最后,衷心感谢开源鸿蒙技术社区提供的平台与机遇,感谢每一位在移植一线贡献智慧与代码的开发者。鸿蒙新故事,我们一起写!

——东北大学开源鸿蒙技术俱乐部

全体课题组师生

2026年8月

写在最后

本课题为开源鸿蒙生态补充了面向C/C++软件库自动移植的关键基础设施。系统性归纳的CPI问题分类学与适配策略、结构化的跨平台适配知识库、以及CROSS2OH自动化工具链,均可直接服务于社区的库移植工作,显著降低开发者的移植门槛和重复劳动。

后续计划包括:持续跟踪开源鸿蒙SDK版本演进和社区适配案例变化,扩展适配知识库的覆盖范围;推动CROSS2OH与Lycium框架的深度集成,作为可选插件或扩展模块提供统一的命令行接口与IDE支持;选择更多尚未适配的C/C++软件,按社区规范提交移植成果,进一步丰富开源鸿蒙三方库生态;引入更多运行时测试,进一步验证适配后软件的功能正确性,推动已移植库的长期维护机制的建立。

附录

课题组围绕开源鸿蒙(OpenHarmony)生态的关键工程技术问题,在三方库智能适配(JavaScript/TypeScript → ArkTS、C/C++ 软件库移植)、鸿蒙应用智能适配("安卓转鸿蒙")与开源鸿蒙软件供应链安全治理等方向持续开展研究,形成系列研究成果与教学成果。已公开成果如下:

一、开源项目地址:

(1) C/C++ 移植工具平台(https://cross2oh.github.io/CROSS2OH/)

(2) 开源鸿蒙移植软件库中心仓(目前已适配391个核心软件库):https://gitee.com/ArkTSCentralRepository

(3) 开源鸿蒙星闪 AIoT 智能家居实践教学开发板及其配套教学资源(与 AtomGit 联合研发):https://atomgit.com/xiaohong-ai/vendor_atomgit/tree/OpenHarmony-6.1.0.31-Release/xiaohong-se

二、发表论文:

[1] [ASE'25] Qian Zhang#, Tsz On Li#, Ying Wang*, Li Li, Shing-Chi Cheung. CROSS2OH: Enabling Seamless Porting of C/C++ Software Libraries to OpenHarmony[C], ASE 2025, 1-13, December 2025, Seoul.

[2] [ISSTA'25] Bo Zhou, Jia Shi, Ying Wang*, Li Li, Tsz On Li, Hai Yu, Zhiliang Zhu. Porting Software Libraries to OpenHarmony: Transitioning from TypeScript or JavaScript to ArkTS[C], ISSTA 2025, 1445-1466, June 2025, Trondheim.

[3] [ISSTA'26] Meiqiu Xu, Xibin Zhao, Wenxuan Yu, Zhiliang Zhu*, Li Li, Heqing Huang, Ying Wang. DeepSCA: Dependency-Aware Software Composition Analysis for C/C++ Based on a Curated Code Feature Database[C], ISSTA 2026, 1-21,October 2026, Oakland.

[4] [软件学报'25] 徐美秋, 王舒婧, 王莹*, 于海, 朱志良. CAnalyzer: 面向C/C++源代码的软件成分分析技术[J], 软件学报, 37(7): 2808-2830.

[5] 开源教育教材(配全套教学资源):《开源软件构建技术:理论与实践》,王莹、黎立、王伟、朱志良,电子工业出版社,ISBN:9787121523618.

本文经AI辅助,人工审校后发布。

最新文章

随机文章