第1节课程介绍与开源共建理念5分钟大家好欢迎来到《鸿蒙PC开源软件迁移与多语言三方库移植实战》课程我是本课程的主讲嘉宾——CSDN猫哥。个人博客: blog.csdn.net/qq8864视频课程地址https://edu.csdn.net/course/detail/40818首先做一下自我介绍。我一直活跃在鸿蒙PC生态开源社区致力于解决实际项目中的三方库移植问题总结了一套从环境搭建到部署验证的完整方法论。也是开源社区的活跃贡献者希望通过这门课程帮大家降低鸿蒙PC生态的开发门槛。如果有任何问题都欢迎到我的个人博客中留言交流。好我们先来看一下课程的核心设计。一、课程目标与核心收获本课程的目标非常明确掌握鸿蒙PC平台开源命令行软件和三方库移植的完整流程从环境搭建到最终部署验证的全链路能力。通过5小时、18节课的系统学习你将获得以下五大核心能力能力维度具体内容环境搭建能力WSL/虚拟机/DockerQEMU/真机五维环境独立搭建C/C移植能力Autotools/CMake/Meson三大构建系统适配命令行移植能力OpenSSH实战、四种方案灵活选型AI辅助实战能力build_in_harmonyos AI框架NAPI自动封装社区共建能力CI/CD集成、PR规范、知识沉淀二、鸿蒙PC生态全景核心技术栈鸿蒙PC基于Linux内核 musl libc NDK工具链。这意味着底层使用LLVM/Clang工具链链接器使用lldC标准库使用musl而非glibc——这是移植工作中最核心的挑战来源强制ELF签名机制——所有可执行文件和.so都需要签名后才能运行核心挑战musl/glibc ABI兼容差异符号命名、线程本地存储布局、函数行为不同软件依赖管理开源软件默认假设Linux glibc需逐个适配ELF签名机制编译后的二进制必须签名才能部署三、课程结构概览课程设计为五大部分、18节课程部分主题时长节数Part 1课程概述与环境准备25分钟3节Part 2C/C三方库移植实战90分钟5节Part 3命令行工具移植实战60分钟4节Part 4多语言AI辅助迁移90分钟3节Part 5总结与社区共建35分钟3节课程特点实战驱动、案例丰富。每个知识点都配有完整的可复现案例——从libmediainfo到OpenSSH从pngquant到FFmpeg从ujson到build_in_harmonyos。四、开源共建理念移植工作的最大价值不在于一个人把所有库都编完而在于将经验、补丁、脚本沉淀下来贡献回社区。核心理念一个人移植一个库能跑就行一群人移植几百个库生态就成了移植的本质交叉编译器 libc适配 构建系统补丁AI辅助通用范式AI Agent NAPI封装好第1节就到这里。短短5分钟我们对课程和生态有了全景认识。下面进入第2节——多维度开发环境搭建。第2节多维度开发环境搭建15分钟大家好欢迎来到第2节。环境搭建是移植工作的基石构建一个高效的开发和验证环境能让你在后续的移植工作中事半功倍。一、五位一体的开发环境体系我们设计了一套五层开发环境体系从开发、编译到验证形成一个完整的闭环Windows宿主DevEco Studio │ ├── WSL2 (Ubuntu 24.04) ── 本地编译主力 ├── 虚拟机Linux (Ubuntu) ── 环境一致 ├── 云服务器 (Ubuntu) ── 7x24持续编译 ├── 鸿蒙PC 真机 ── 最终验证 └── Docker 容器 ── 低成本沙盒二、环境选型建议最佳推荐组合VS Code (Remote-WSL) Ubuntu 24.04 LTS → 本地编译 Docker QEMU → 快速验证 鸿蒙PC 真机 → 最终部署这个组合兼顾了开发效率、验证成本和部署可靠性。三、Windows宿主环境WSLWindows下强力推荐WSL2作为编译环境。它让你在Windows电脑上拥有完整的Linux终端体验且与VS Code无缝集成。关于WSL的安装详细步骤参见我的个人博客在 Windows 10 上安装和使用 WSL 2 安装 Ubuntu24详细指南安装步骤第一步安装WSL2# 以管理员身份在PowerShell中执行wsl--install-dUbuntu-24.04第二步配置国内镜像源# 替换apt源为国内镜像加速后续软件安装sudosed-is/archive.ubuntu.com/mirrors.ustc.edu.cn/g/etc/apt/sources.listsudoaptupdatesudoaptupgrade-y第三步安装基础编译工具链sudoaptinstall-y\python3 python3-pip\gitcurlcmake ninja-build\makepkg-config automake libtool\gettext autopoint yasm nasm第四步安装VS Code Remote-WSL插件在VS Code中安装Remote - WSL插件然后在WSL终端中输入code .即可打开远程开发窗口。WSL的独有优势与Windows文件系统互访/mnt/c/性能接近原生Linux无需虚拟机开销Docker Desktop可直接使用WSL2后端四、虚拟机Linux环境Ubuntu如果你不使用Windows或者需要独立的编译环境虚拟机是最直接的选择。虚拟机选型建议推荐使用VMware Workstation Pro或VirtualBoxUbuntu 22.04 LTS或24.04 LTS分配至少4核CPU、8GB内存、40GB磁盘与WSL的对比对比项WSL2虚拟机启动速度秒级分钟级内存占用动态分配固定分配图形界面仅终端完整桌面文件系统跨Windows访问独立适用场景日常开发编译全量构建测试五、云服务器环境Ubuntu对于需要长时间编译、或者本地资源不足的场景云服务器是最佳选择。推荐配置腾讯云/华为云轻量应用服务器2核4GB起步Ubuntu 24.04 LTS包年费用约38元新用户优惠优势7x24小时持续运行编译任务不中断性能稳定资源可弹性扩展不占用本地电脑资源随时随地SSH远程登录操作六、DockerQEMU低成本容器验证这是最推荐的验证方案。在没有鸿蒙PC真机的情况下通过DockerQEMU在x86_64服务器上模拟ARM64鸿蒙环境。详细操作步骤参见我的这篇低成本搭建鸿蒙PC运行环境基于 Docker 的 x86_64 服务器关于Ubuntu 系统下docker的安装这里网上有很多资料就不多介绍了。在Ubuntu下只需几条简单安装命令。详细介绍也可以在我的个人博客中搜索到相关内容如Windows10下使用WSL安装 Docker和docker compose完整教程非常不建议直接使用apt get install docker的方式安装。那样安装的是很老的1.x的版本且很可能安装不成功。推荐按猫哥的教程一步步成功安装最新版docker猫哥的博客是平常的实践总结并没有刻意写博都是日常的笔记自己也经常查阅。原理利用Linux内核的binfmt_misc机制将QEMU用户态仿真器注册为ARM64程序的处理程序。当系统尝试执行ARM64格式的程序时内核自动调用QEMU翻译ARM64指令。4步快速搭建步骤1安装Docker可选国内镜像源# 使用国内镜像源脚本安装bash(curl-sSLhttps://linuxmirrors.cn/docker.sh)# 配置华为云源 毫秒镜像registry步骤2注册QEMU多架构支持# 注册ARM64解释器使用国内镜像源加速dockerrun--rm--privilegeddocker.1ms.run/tonistiigi/binfmt--installarm64注服务器重启后需要重新执行此命令。注册成功后宿主机和Docker均可直接运行ARM64二进制程序。步骤3拉取并运行鸿蒙容器# 拉取鸿蒙容器镜像国内镜像加速dockerrun--nameohos-itd--platformlinux/arm64\docker.1ms.run/hqzing/dockerharmony:latest步骤4进入容器体验dockerexec-itohossh# 验证鸿蒙环境uname-a# 输出: OpenHarmony aarch64宿主与容器文件交互# 宿主机→容器dockercp./编译产物 ohos:/root/# 容器→宿主机dockercpohos:/root/验证结果 ./验证演示——运行移植好的二进制# 在Docker容器中测试axel多线程下载工具cd/root ./axel-k-n50https://github.com/Harmonybrew/ohos-neovim/releases/download/0.11.4/neovim-0.11.4-ohos-arm64.tar.gz环境优势总结✅ 极低成本 复用现有x86_64服务器无需购置ARM64硬件✅ 最小可用 提供基础的鸿蒙运行环境✅ 国内网络优化 全程采用国内镜像源加速✅ 灵活便捷 Docker容器易于创建、销毁和复用七、鸿蒙PC真机调试环境最终验证必须在真机上进行。真机调试需要1. 设备连接通过USB线缆或局域网连接鸿蒙PC与开发机。2. hdc调试工具hdcHarmonyOS Device Connector是官方调试工具功能包括# 设备管理hdc list targets# 列出已连接的设备# 文件传输hdcfilesend 本地文件 目标路径# 推送到设备hdcfilerecv 目标路径 本地文件# 从设备拉取# 命令行执行hdc shell# 进入设备终端# 应用安装hdcinstallapp.hap# 安装HAP包3. 权限配置设备端设置→系统→开发者选项→开启开发者模式隐私和安全→高级→开启运行来自非应用市场的扩展程序开发机首次连接需确认设备授权鸿蒙PC关键特性与约束特性说明工具链SDK内置LLVM/Clang链接器使用lldC库兼容musl libc与glibc有差异安全校验强制ELF签名未签名不可执行调试工具hdc统一管理设备连接与文件交互包管理推荐使用Harmonybrew好以上就是第2节的内容。我们完成了五维环境的搭建方法。最后一节我们来学习SDK配置和HNP标准化。第3节SDK配置与HNP标准化5分钟大家好欢迎来到第3节。环境搭建完成后我们需要配置SDK工具链。本节虽然只有5分钟但这是整个课程的技术起点——之后所有编译工作都建立在SDK正确配置的基础上。一、SDK的获取OpenHarmony SDK的官方获取渠道有两处渠道一OpenHarmony社区Release文档https://atomgit.com/openharmony/docs/blob/master/zh-cn/release-notes/OpenHarmony-v6.1-release.md每当OpenHarmony发布新版本Release文档中会附带成套的SDK下载链接。渠道二OpenHarmony社区流水线https://dcp.openharmony.cn/workbench/cicd/dailybuild/dailylist可以下载到任意一天的日构建产物。推荐的下载方式交叉编译选ohos-sdk-full原生编译选ohos-sdk-public二、SDK的下载与解压# 下载SDK以日构建版本为例sdk_download_urlhttps://cidownload.openharmony.cn/version/Daily_Version/\ OpenHarmony_6.1.0.27/20260111_020523/version-Daily_Version-\ OpenHarmony_6.1.0.27-20260111_020523-ohos-sdk-public.tar.gzcurl-oohos-sdk-public.tar.gz$sdk_download_urlmkdirohos-sdktar-zxfohos-sdk-public.tar.gz-Cohos-sdk# 解压工具链cd~/ohos-sdk/linuxunzipnative-linux-x64-6.1.0.27-Beta1.zipunziptoolchains-linux-x64-6.1.0.27-Beta1.zip三、环境变量配置——OHOS_SDK_ROOT这是最重要的配置步骤。在编译脚本中我们需要设置OHOS_SDK_ROOT并导出所有工具链路径exportOHOS_SDK_ROOT/root/ohos-sdk/linux# 编译器路径exportCOMPILER_TOOLCHAIN${OHOS_SDK_ROOT}/native/llvm/bin/exportCC${COMPILER_TOOLCHAIN}clangexportCXX${COMPILER_TOOLCHAIN}clangexportLD${COMPILER_TOOLCHAIN}ld.lldexportAR${COMPILER_TOOLCHAIN}llvm-arexportSTRIP${COMPILER_TOOLCHAIN}llvm-strip# 系统根目录exportSYSROOT${OHOS_SDK_ROOT}/native/sysroot# pkg-config配置exportPKG_CONFIG_SYSROOT_DIR${SYSROOT}/usr/lib/aarch64-linux-ohos# 目标平台exportTARGET_PLATFORMaarch64-linux-ohos# 编译选项exportCFLAGS-fPIC -D__MUSL__1 -D__OHOS__ --target${TARGET_PLATFORM}--sysroot${SYSROOT}四、SDK工具链全家桶工具用途clang / clang交叉编译器musl-clang变体ld.lldELF链接器支持--code-sign参数llvm-strip / llvm-ar符号裁剪与静态库管理binary-sign-tool二进制签名工具hnpcliHNP包构建工具cmake / ninja构建系统含ohos.toolchain.cmake五、二进制自动签名技术鸿蒙系统要求所有ELF文件和共享库必须经过签名才能在设备上运行。传统方式使用binary-sign-tool逐个签名binary-sign-tool sign-selfSign1-inFilemy_program-outFilemy_program但逐个签名在复杂项目中极为繁琐。最新技术栈提供了编译时自动签名——通过封装ld.lld链接器实现# 替换ld.lld为封装脚本cdohos-sdk/linux/native/llvm/binrmld.lld# 移除原始软链接lld_absolute_path$(realpath lld)# 创建封装脚本在链接时自动注入--code-sign参数printf#!/bin/bash\nexec -a $0 %s --code-sign $\n$lld_absolute_pathld.lldchmod0755 ld.lld# 验证签名clang--targetaarch64-linux-ohos hello.c-ohello llvm-readelf-Shello|grepcodesign# 应输出.codesign PROGBITS ...签名段存在签名信息存储在ELF文件的.codesign段中。使用llvm-readelf -S可查看。关于自动签名的详细介绍参考 猫哥的博文鸿蒙PC生态三方软件移植ohos-sdk 生成的库或二进制的自动签名实现六、HNP鸿蒙原生包标准化体系HNP 是 OpenHarmony 的原生包格式本质就是一个 ZIP 包内含二进制、库和 hnp.json 元数据。类比一下就懂了HNP 之于鸿蒙 ≈ DEB 之于 Debian、MSI 之于 Windows——它是一套标准化的软件打包规范。但有个关键认知要澄清HNP 不是必须的。已签名的二进制直接拷贝到鸿蒙 PC 上也能跑就像 Linux 程序不以 .deb 形式存在、直接 ./binary 也行一样。HNP 是锦上添花的规范格式不是离了它不行的铁律。那什么时候需要 HNP当你要通过 HAP 应用分发、走应用市场生命周期管理时才必须打包为 HNP。因为 HNP 嵌入 HAP 后系统能自动完成安装卸载、权限隔离和 PATH 集成带来三个核心能力原子化安装卸载随 HAP 同生命周期卸载 HAP 时 HNP 自动清理权限隔离公有 HNP全局可调vs 私有 HNP仅宿主可调环境自动集成公有 HNP 的软链接自动加入 PATHhnp.json 示例——包的身份证{type:hnp-config,name:pngquant,version:2.18.0,install:{bins:[bin/pngquant],libs:[lib/*.so*]}}后续在 lycium 移植案例中编译完成后框架会自动调用 hnpcli 工具将产物打包为 HNP。更多细节到具体案例中再展开这里先建立概念。参考官方文档https://gitcode.com/openharmony/startup_appspawn/blob/master/service/hnp/README_zh.md拓展内容什么是 HNPHNPOpenHarmony Native Package是 OpenHarmony 的原生包格式用于打包原生程序和库。HNP 包本质上是一个 ZIP 文件包含可执行文件、共享库、配置文件和元数据。HNP是鸿蒙系统为原生应用与库设计的标准化软件包格式。关于HNP包的详细介绍官方文档地址https://gitcode.com/openharmony/startup_appspawn/blob/master/service/hnp/README_zh.mdhttps://gitcode.com/openharmony/startup_appspawn/blob/master/service/hnp/pack/README_zh.mdhnp.json——HNP包的核心元数据位于包根目录定义软件包的身份、依赖关系及安装行为。{type:hnp-config,name:pngquant,version:2.18.0,arch:arm64,os:ohos,summary:A lossy PNG compressor,depends:[libpng 1.6,zlib 1.2],install:{bins:[bin/pngquant],libs:[lib/*.so*]}}HNP的关键价值维度说明统一分发标准简化跨设备、跨架构的依赖管理逻辑提升兼容性降低原生应用与系统的开发和部署成本自动化管控标准化元数据实现安装、升级、卸载全自动化规模化基础为鸿蒙原生生态的规模化发展奠定基础在使用lycium框架时HNP是个基础设施。在后续每个移植案例中编译完成后框架默认会使用hnpcli工具将产物打包为HNP包# 打包HNPhnpcli pack-ipackage_dir/-ooutput.hnp# 打包tar.gztar-zvcfohos_package.tar.gz package_dir/但初学者肯定有个疑问,hnp包是必须的吗必须有它吗不打成这个包没法用吗如何安装它其实也非必须打包成它看你的用途了。比如vcpkg移植中就没有提到它。你需要清楚的是啥时候需要用它。直接拷贝一个命令行到鸿蒙PC上如果经过了签名直接运行也是没问题的。HNP包安装使用:可参考下DevBox这个应用。hnp包其实就是个压缩包。可以用zip软件打开查看。系统会将hap包校验解压到对应目录下。我觉得当前它的主要作用是方便app包对其进行生命周期管理。但是这个包呢截至目前我没找到有啥命令可以直接安装它网上你看到的文章中的说可以命令行安装这个描述是错的。如果你知道有啥命令行可以安装hnp包可以告诉我下据我所知当前的HNP不能单独装都必须打包成HAP或APP的应用包才行。关于HNP包的一个更好的理解其实就记住一句话就是对比一下windows或linux系统windows系统下有msi的安装包linux系统下有deb的安装包你说我的三方库或命令行必须打包为HNP吗当然你可以打包也可以以文件的形式也行这跟应用运行是否依赖它无关系。对比了下其他系统你是不一下子就豁然开朗了注意只是类似帮助你理解。其实HNP包有它都有的特色功能HNP包本质上是一种特殊的鸿蒙原生软件包格式它允许开发者将编译好的二进制文件、依赖库和配置文件 打包成标准化容器。与传统的软件分发方式不同HNP包具有以下核心优势原子化安装卸载HNP包作为HAP应用的组成部分支持与宿主应用同生命周期管理权限隔离机制通过public/private类型区分实现精细化的命令访问控制环境自动集成安装后自动创建软链接无需手动配置PATH环境变量参考链接https://blog.csdn.net/transformer2023/article/details/155594592 https://blog.csdn.net/m0_57525346/article/details/154846430 https://blog.csdn.net/qq8864/article/details/157426019也可以在在hap应用中访问Native二进制以c语言为例可以在hap应用代码中通过execv、execve等函数执行二进制。默认公有hnp包软链接路径为/data/service/hnp/bin默认软链接路径已加入环境变量中。私有hnp请使用实际路径/data/app/xxx.org/xxx_yyy/{二进制文件在hnp包中的相对路径如bin/hnpsample}其中xxx对应hnp.json中“name”yyy对应hnp.json中“version”。示例代码如下pid_t child fork(); if (child 0) { OH_LOG_ERROR(LOG_APP, fork for child process failed %d, errno); return; } if (child 0) { // do execv int ret execv(/data/app/test.org/test_1.1/bin/testBin, NULL); OH_LOG_ERROR(LOG_APP, execv failed errno %d, errno); exit(errno); } else { int status; if (waitpid(child, status, 0) -1) { OH_LOG_ERROR(LOG_APP, waitpid failed errno %d, errno); return; } // process child exit ... }hdc shell执行方法操作步骤从应用市场下载Native软件包hap应用并安装。通过数据线连接设备执行hdc shell访问设备。公有hnp包安装后的物理路径为/data/app/el1/bundle//hnppublic私有hnp包安装后的物理路径为/data/app/el1/bundle//hnpuserid默认为100。可以进入这些目录下找到安装的Native包文件目录执行相关二进制。想了解更多细节可以到https://gitcode.com/openharmony仓查阅感兴趣的文档。更详细的关于HNP包的介绍参见猫哥的博客HarmonyOS鸿蒙原生HNP包全解析从规范到实战的完整指南好以上就是第3节的内容。我们完成了SDK的获取配置、工具链全家桶的学习、二进制自动签名技术和HNP标准化体系。至此第一部分课程结束后续我们将正式进入第二部分——C/C三方库移植实战。第1节回顾课程目标、鸿蒙PC生态全景、五大部分结构、开源共建理念第2节回顾五位一体环境WSL/虚拟机/云服务器/真机/Docker容器、DockerQEMU低成本方案、hdc真机调试第3节回顾SDK获取配置、OHOS_SDK_ROOT环境变量、工具链全家桶、二进制自动签名、HNP标准化欢迎进入第二部分——C/C三方库移植实战