BYTE UNIXBench 鸿蒙 PC 适配全记录：从经典 Unix 基准套件到 HAP_HNP 终端工具

欢迎加入开源鸿蒙 PC 社区：https://harmonypc.csdn.net/

欢迎在 PC 社区平台申请新建项目：https://atomgit.com/OpenHarmonyPCDeveloper

适配开源地址：https://atomgit.com/OpenHarmonyPCDeveloper/ohos_byte-unixbench

一、为什么要适配 BYTE UNIXBench

BYTE UNIXBench 是一套沿用多年的类 Unix 系统综合基准工具。它不只给出一个笼统分数，而是分别考察整数运算、浮点运算、系统调用、管道吞吐、上下文切换、进程创建、execl、文件读写与多并发 Shell 脚本等基础能力。对一个正在完善 Native 生态的新平台而言，这类工具的意义不只是"跑分"，更在于验证编译器、C 运行库、进程模型、文件系统和命令行环境能否在持续负载下共同工作。

HarmonyOS PC 已经具备 HAP 应用形态、Native 编译工具链和系统终端，但传统 Unix 工具并不能因为源码是 C 语言就直接变成可安装应用。UnixBench 上游以 Makefile、Perl 调度器和桌面 Unix 环境为前提，其中还夹杂 X11/GLX 图形测试、运行时编译、可执行文件相对路径和结果目录写权限等假设。本次适配的目标，是保留 UnixBench 原有的终端使用习惯，同时把编译、安装、命令注册和结果落盘整理成一条符合 HarmonyOS PC 交付方式的闭环。

当前适配版本为 6.0.1，BundleName 为 org.byteunixbench.pc，目标设备类型为 2in1，Native ABI 为 arm64-v8a。最终交付物由一个轻量 HAP 说明页和一个 HNP 原生命令包组成：HAP 负责应用入口与中文指引，HNP 负责提供 unixbench 命令及实际测试程序。

二、先划清适配边界：UnixBench 的核心仍然在终端

UnixBench 本身不是桌面图形应用。它的主要交互一直是输入命令、等待各测试项运行、读取终端输出和结果文件。若为了"看起来像 PC 应用"而重新制作一套按钮式跑分界面，不仅会偏离上游用法，还容易让新的界面状态、计时逻辑和分数汇总与原工具产生差异。

因此，本项目没有重写测试引擎，而是采用下面的分层方式：

层次	主要职责	鸿蒙侧实现
HAP 应用壳	提供桌面入口、版本和使用说明	ArkTS Stage 模型页面
HNP 安装层	随 HAP 分发原生命令并注册终端入口	byte-unixbench.hnp 公共 HNP
命令调度层	解析测试项、迭代次数、并发副本和输出选项	POSIX sh 编写的 Run.ohos
Native 测试层	执行计算、进程、管道、文件与 Shell 测试	BiSheng/Clang 编译的 AArch64 程序
结果层	保存可复核的文本和 CSV 数据	用户可写目录下的结果与临时目录

这项边界选择也决定了图形测试的处理方式。上游 2D/3D 测试依赖 X11、GLX、libX11 和桌面 Display Server，当前 HNP 运行环境并不提供这套兼容层。鸿蒙版本会明确报告未适配并正常返回终端，不构造虚假的图形分数，也不会让缺少动态库变成一次无提示崩溃。

三、鸿蒙版本的工程与运行架构

项目把上游源码与鸿蒙交付工程分开维护。UnixBench/ 仍然保留 C 源码、Makefile、原始 Run 和测试数据；ohos/ 负责交叉编译、HNP 打包、HAP 壳构建、资源嵌入与签名。

ohos_byte-unixbench/
├── UnixBench/
│   ├── src/                         # Dhrystone、Whetstone、进程、管道、文件等源码
│   ├── pgms/                        # 测试程序、脚本、数据与原始 ASCII Logo
│   ├── Makefile                     # 增加 HarmonyOS PC 编译分支
│   ├── Run                          # 上游 Perl 调度器
│   └── Run.ohos                     # 面向 HNP 的 POSIX shell 调度器
├── ohos/
│   ├── build_hnp.sh                 # 交叉编译并生成 byte-unixbench.hnp
│   ├── package_hap_with_hnp.sh      # 构建、嵌入 HNP 并签名 HAP
│   ├── verify_hnp.sh                # 校验文件、架构与图形产物隔离
│   ├── verify_shell.sh              # 校验 HAP 壳和命令说明
│   └── entry/src/main/
│       ├── ets/                     # EntryAbility 与中文说明页
│       ├── hnp/arm64-v8a/           # 随 HAP 分发的 HNP
│       └── resources/               # 图标、字符串与页面资源
└── README.OpenHarmony_CN.md

安装后的运行链路如下：

签名 HAP 安装
    ├── Byte UnixBench 说明页
    └── byte-unixbench.hnp
           └── 注册 unixbench / unixbench-run / execl
                  └── Run.ohos
                         ├── 调度 arm64-v8a 测试程序
                         ├── 汇总 RESULT / SUMMARY
                         └── 写入文本报告与可选 CSV

build_hnp.sh 使用 HarmonyOS Native SDK 中的 aarch64-unknown-linux-ohos-clang 编译测试程序，并以 UB_PLATFORM=ohos 进入专用 Makefile 分支。这个分支保留系统类测试，主动排除 gfx-x11 和 ubgears。随后，脚本把测试二进制、multi.sh、tst.sh、测试数据与原始 ASCII Logo 组织到 HNP 目录，再通过 hnpcli 生成 byte-unixbench.hnp。

四、在 HarmonyOS PC 真机上验证核心功能

以下五张截图来自当前仓库构建并签名的 HAP，在 HarmonyOS PC 真机安装后的实际运行画面。测试设备为 HUAWEI MateBook Pro（HAD-W32，2in1），系统版本为 HAD-W24 6.1.0.117，屏幕分辨率为 3120×2080。终端测试直接调用随 HAP 安装的 HNP 命令，没有在开发机上用同名脚本代替。

1. HAP 页面给出安装后的使用入口

启动 org.byteunixbench.pc 后，页面显示 BYTE UNIXBench 6.0.1、上游 ASCII Logo、已安装命令、终端示例及结果目录。这个页面保持轻量，不参与计时，也不在应用进程里复制一套测试调度逻辑。

HAP 壳的价值在于让命令行工具进入标准应用安装流程。用户可以从桌面确认版本和用法，实际测试仍在 HiShell 中完成，二者职责清晰，也便于后续单独升级 HNP 内的原生程序。

2. 终端帮助确认命令已经由 HNP 注册

在系统 HiShell 中执行 unixbench -h，可以看到 -i、-c、system、graphics 以及用于缩短冒烟测试时间的环境变量。命令能被系统直接找到，说明 HAP 安装、HNP 解包与命令链接已经连通。

其中 -i 控制迭代次数，-c 控制同一测试的并发副本数。UB_TEST_SECONDS 和 UB_SHELL_SECONDS 用于快速验证链路，不应拿缩短时长后的结果与正式默认配置分数横向比较。

3. 对 X11/GLX 能力做明确、可恢复的降级

执行 unixbench graphics 后，终端准确说明 2D X11 与 3D GLX/ubgears 没有进入当前 HNP，并给出缺少 X11/GLX 运行时这一原因。命令随后回到提示符，没有缺库崩溃，也没有输出无依据的图形成绩。

这里特意保留 graphics 命令入口，是为了让从上游文档迁移过来的使用者能得到直接反馈。相比删除命令或静默跳过，这种行为更利于自动化脚本识别平台差异。

4. 启动系统类基准测试并进入真实负载

为控制文档验证时长，本次真机冒烟测试执行：

UB_TEST_SECONDS=2 UB_SHELL_SECONDS=2 unixbench -i 1 -c 1 system

终端先输出上游 Logo、版本、结果目录和临时目录，随后从 Dhrystone 开始逐项运行。截图中的 /storage/Users/currentUser/byte-unixbench-results 与 byte-unixbench-tmp 是 HiShell 当前用户目录下实际创建的路径。

这一步验证的不只是一个 C 程序能启动。Run.ohos 需要依次完成参数解析、目录创建、后台副本调度、输出采集和单位换算，任一环节对 HNP 路径或 Shell 行为判断错误，测试都无法继续推进。

5. 完成进程、文件和 Shell 测试并写入报告

完整冒烟流程最终返回 HiShell 提示符。真机结果中可以看到 Process Creation、Execl Throughput、文件写入、读取、复制以及 1 路和 8 路 Shell Scripts 的 RESULT 与 SUMMARY。本次短时验证得到的部分结果包括：文件读取 1314008 KBps、文件复制 410029 KBps、单路 Shell Scripts 51 lpm；这些数值只用于证明测试确实执行，不作为正式基准结论。

输出末尾给出了真实报告路径：/storage/Users/currentUser/byte-unixbench-results/ohos-unixbench-20260816-120401.txt。报告文件与终端内容来自同一次执行，便于后续留档、比对或导入其他分析流程。

五、适配过程中遇到的关键困难

难点一：上游 Perl 调度器不适合作为 HNP 的默认依赖

上游 Run 以 Perl 为主控，负责发现环境、检查程序、组织测试和生成结果。若把它原样设为入口，目标设备还必须具备版本和模块都可控的 Perl 环境，这会把一个原生基准包变成额外的解释器部署问题。

本项目新增 Run.ohos，用 POSIX sh 重新组织 HarmonyOS PC 所需的核心调度：参数解析、系统测试集合、并发副本、临时目录、结果采集、文本报告和 CSV 都在脚本内完成。上游 Perl 文件仍然保留，便于对照行为和在传统平台使用，但 HNP 的 unixbench 默认进入不依赖 Perl 的鸿蒙调度器。

难点二：交叉编译必须彻底区分构建机与目标机

UnixBench 的 Makefile 会根据宿主系统选择参数，也可能在运行前检查或重建测试程序。macOS 构建机上的 uname、编译器和库不能泄漏到 HarmonyOS 目标产物中。适配通过 UB_PLATFORM=ohos 明确选择目标分支，并显式传入 HarmonyOS Clang、HZ=100 与优化参数；HNP 运行时则设置 UB_SKIP_BUILD=1，避免在设备上再次调用不存在的本地构建链。

校验脚本会检查关键测试程序的 AArch64 架构，并确认 HNP 中包含命令、Runner、测试数据和必要脚本。这样可以防止"包构建成功，但里面混入开发机二进制"的隐蔽错误。

难点三：HNP 中的相对路径与系统命令链接并不天然一致

命令通过 HNP 链接暴露后，$0 可能指向系统命令目录，而测试程序、数据和脚本仍在包内目录。如果简单使用当前工作目录拼接 pgms/，spawn、execl、文件测试和 Shell 测试会在不同阶段找不到依赖。

入口脚本先解析实际链接位置，再把包内 bin 目录传给 Run.ohos。Runner 对每个测试建立独立临时工作目录，并在执行 execl 时使用 HNP 命令目录作为可执行文件搜索位置。测试资源和用户输出由此分离：程序从安装目录读取，报告写到用户可写目录。

难点四：并发、计时与结果汇总要保持基准工具语义

-c 不是简单地把同一程序顺序执行多次。Runner 需要同时启动指定数量的副本，等待所有子进程结束，再从每个日志的 COUNT 行提取数值、累加得分并保留单位。若临时文件名、PID 或退出状态处理不严谨，并发测试很容易互相覆盖结果。

Run.ohos 为每个测试、副本、迭代和进程建立隔离路径，以后台进程并行执行，再统一生成 RESULT 和 SUMMARY。UB_TEST_SECONDS 与 UB_SHELL_SECONDS 只覆盖持续时间，不改变测试程序本身，既便于短时真机验收，也保留默认配置用于正式测试。

难点五：图形测试不能用"编译过去了"代替运行时成立

ubgears 和 2D 测试依赖的不只是 OpenGL 头文件，还包括 X11 窗口、GLX 上下文、Display 连接和对应动态库。把这些源码勉强编译进包，并不能说明它们能在 HarmonyOS PC 的 HNP 终端环境中运行。

当前方案在三处设置保护：Makefile 的鸿蒙分支不生成图形二进制；HNP 校验拒绝 gfx-x11 与 ubgears 混入；Runner 对图形测试名称统一输出能力说明后正常退出。这让系统类测试保持完整，同时把尚未具备的桌面兼容条件讲清楚。

难点六：结果目录必须服从终端用户的写权限

HNP 安装目录适合放程序，不适合保存每次测试结果；应用沙箱路径又不一定是 HiShell 用户最方便访问的位置。入口默认使用当前目录下的 byte-unixbench-results 和 byte-unixbench-tmp，在 HiShell 中会自然落到当前用户存储。对于自动化或受限目录，还可以通过 UB_RESULTDIR 与 UB_TMPDIR 指定其他可写位置。

Runner 在开始测试前先创建并规范化两个目录。创建失败时会立即提示用户修改环境变量，而不是运行到文件吞吐测试中途才以模糊错误终止。

六、构建、校验与真机安装

工程使用 DevEco Studio 所带的 HarmonyOS SDK、Hvigor、HNP CLI 和 Native Clang。当前脚本默认从以下位置读取工具：

/Applications/DevEco-Studio.app/Contents/sdk
/Applications/DevEco-Studio.app/Contents/tools/hvigor/bin/hvigorw

只构建并校验 HNP：

./ohos/build_hnp.sh
./ohos/verify_hnp.sh
./ohos/verify_shell.sh

构建包含 HNP 的完整签名 HAP：

./ohos/package_hap_with_hnp.sh

最终安装包位于：

ohos/entry/build/default/outputs/default/entry-default-hnp-signed.hap

连接 HarmonyOS PC 后安装并启动：

HDC=/Applications/DevEco-Studio.app/Contents/sdk/default/openharmony/toolchains/hdc

"$HDC" list targets
"$HDC" install -r \
  ohos/entry/build/default/outputs/default/entry-default-hnp-signed.hap
"$HDC" shell aa start \
  -a EntryAbility \
  -b org.byteunixbench.pc

构建脚本支持通过 DEVECO_SDK_HOME、HVIGORW、OHOS_SDK_PATH 等环境变量覆盖默认工具位置。迁移到其他开发机时，还应使用与目标设备匹配的有效签名材料。

七、日常使用与结果解读

安装完成后，在 HiShell 中直接执行：

unixbench

指定三轮迭代和一个并发副本：

unixbench -i 3 -c 1

只运行单项测试：

unixbench dhry2reg
unixbench whetstone-double
unixbench spawn

生成 CSV：

UB_OUTPUT_CSV=true unixbench

指定结果与临时目录：

UB_RESULTDIR=/path/to/results \
UB_TMPDIR=/path/to/tmp \
unixbench

当前系统测试集合包括 Dhrystone、Whetstone、System Call Overhead、Pipe Throughput、Pipe-based Context Switching、Process Creation、Execl Throughput、文件读写/复制以及 1 路和 8 路 Shell Scripts。不同测试使用 lps、MWIPS、KBps、lpm 等不同单位，应在相同设备状态、相同测试时长、相同副本数和相同版本之间比较，不能把不同项目的原始数值直接相加。

正式测试建议关闭无关高负载任务，保持电源与性能模式一致，并使用默认测试时长。UB_TEST_SECONDS=2 这类参数适合确认命令链路与产物可执行性，不适合作为设备性能排名依据。

八、当前能力与明确限制

当前版本已经完成：

• HAP/HNP 一体化构建、嵌入、签名、安装和命令注册；
• HarmonyOS arm64-v8a 原生测试程序交叉编译；
• 不依赖 Perl 的 POSIX Shell 调度器；
• 迭代次数、并发副本、系统集合与单项测试；
• Dhrystone、Whetstone、系统调用、管道、上下文切换、进程、execl、文件与 Shell 测试；
• 文本报告、可选 CSV、自定义结果目录和临时目录；
• HAP 中文说明页、原始 ASCII Logo 与终端使用指引；
• X11/GLX 图形命令的明确降级和无崩溃返回。

仍需明确的限制包括：

• 2D X11、3D GLX 与 ubgears 未适配，不会产生图形评分；
• HAP 页面是安装与使用说明，不是实时跑分面板；
• 当前 Run.ohos 聚焦核心系统测试，并不等同于上游 Perl Runner 的所有历史选项；
• 短时环境变量会改变测试持续时间，所得数值只能用于冒烟验证；
• 性能数据受电源策略、后台负载、温控和存储状态影响，跨设备比较需要统一条件。

九、总结

BYTE UNIXBench 的鸿蒙 PC 适配并不是把一组 C 文件换个编译器重新生成。真正需要处理的是上游调度器依赖、交叉编译边界、HNP 命令链接、子进程并发、临时目录、结果落盘，以及 X11/GLX 能力缺口如何对用户透明表达。

当前方案让 HAP 承担标准应用入口，让 HNP 承担原生命令交付，再用 Run.ohos 把已经验证的系统测试组织起来。五张真机截图从说明页、命令帮助和能力边界，连续展示到系统测试启动、多个原生负载完成和报告写入，证明适配已经形成可安装、可执行、可留存结果的实际闭环。

这条路线也适合其他以终端为主要交互的开源工具：先尊重上游形态，再解决平台交付和运行依赖；对可以工作的核心能力做完整验证，对暂时缺失的桌面运行时明确降级。这样得到的不是一个只会启动的演示壳，而是一项在 HarmonyOS PC 上能够被开发者真正使用和复核的工具。