惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

小众软件
小众软件
博客园_首页
博客园 - 聂微东
T
Tailwind CSS Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
J
Java Code Geeks
The Cloudflare Blog
aimingoo的专栏
aimingoo的专栏
Martin Fowler
Martin Fowler
D
Docker
人人都是产品经理
人人都是产品经理
WordPress大学
WordPress大学
博客园 - 三生石上(FineUI控件)
Microsoft Azure Blog
Microsoft Azure Blog
Recent Announcements
Recent Announcements
Apple Machine Learning Research
Apple Machine Learning Research
阮一峰的网络日志
阮一峰的网络日志
B
Blog RSS Feed
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Microsoft Security Blog
Microsoft Security Blog
L
LangChain Blog
Jina AI
Jina AI
博客园 - Franky
D
DataBreaches.Net

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
鸿蒙PC三方库测试验证HPKCHECK 深度解读 – 人人都是产品经理,
nutpi · 2026-04-17 · via 人人都是产品经理

OpenHarmony生态中的三方库适配面临一个关键挑战:如何确保交叉编译的产物能在真实设备上正确运行?HPKCHECK作为质量守门人,通过设备端测试彻底解决了这一痛点。本文将深入解析HPKCHECK的运行机制与编写规范,揭秘华为在开源生态建设中的工程实践智慧。

在 OpenHarmony 三方库适配中,HPKBUILD 负责把源码编译成产物,HPKCHECK 负责验证产物是否真的能用。

你可能会想:编译没报错不就行了?问题是,交叉编译出的 ARM 可执行文件无法在 x86 开发机上运行,你根本不知道它编译出来能不能正常工作。HPKCHECK 就是把测试程序推到真实 OpenHarmony 设备上执行,确保功能正确。

这篇文章把 HPKCHECK 的结构、执行流程、编写方法讲清楚。

HPKCHECK 文件内容

SHA 库的 HPKCHECK 内容如下:

# Copyright (c) 2023 Huawei Device Co., Ltd.

# Licensed under the Apache License, Version 2.0 (the “License”);

# …

# Contributor: huangminzhong <huangminzhong2@huawei.com>

# Maintainer: huangminzhong <huangminzhong2@huawei.com>

source HPKBUILD > /dev/null 2>&1

logfile=${LYCIUM_THIRDPARTY_ROOT}/${pkgname}/${pkgname}_${ARCH}_${OHOS_SDK_VER}_test.log

openharmonycheck() {

cd$builddir/$ARCH-build

ctest > ${logfile} 2>&1

res=$?

cd$OLDPWD

return$res

}

只有三个有效部分,下面逐个拆解。

逐部分解读

1. source HPKBUILD — 加载构建配置

source HPKBUILD > /dev/null 2>&1

通俗理解:把 HPKBUILD 里的变量和函数”搬”过来,这样 HPKCHECK 就能知道包名、构建目录等信息。

  • source:在当前 Shell 环境中执行文件(不是启动子进程)
  • &gt; /dev/null 2>&1:静默执行,不输出 HPKBUILD 的内容

加载后可用的关键变量:

2. logfile — 测试日志路径

logfile=${LYCIUM_THIRDPARTY_ROOT}/${pkgname}/${pkgname}_${ARCH}_${OHOS_SDK_VER}_test.log

通俗理解:定义测试日志文件的位置和名称。

展开后类似:thirdparty/sha/sha_arm64-v8a_10_test.log

日志文件名包含三个关键信息:

  1. sha:哪个库
  2. arm64-v8a:哪个架构
  3. 10:哪个 SDK 版本

这样不同配置的测试结果不会混在一起。

3. openharmonycheck() — 核心测试函数

openharmonycheck() {

cd $builddir/$ARCH-build

ctest > ${logfile} 2>&1

res=$?

cd $OLDPWD

return $res

}

通俗理解:进入构建目录,运行 CTest,记录结果,返回原目录。

CTest 会执行什么? 由 CMakeLists.txt 中的 add_test() 定义:

enable_testing()

add_test(NAME test_hmac COMMAND hmac)

add_test(NAME test_pwd2key COMMAND pwd2key)

add_test(NAME test_sha COMMAND sha_test)

三个测试用例分别验证 HMAC、密钥派生和 SHA 算法的正确性。

为什么需要单独的 HPKCHECK?

HPKBUILD 中的 check() 为什么不够?

HPKBUILD 里确实有个 check() 函数:

check() {

echo “The test must be on an OpenHarmony device!”

# ctest

}

但 ctest 被注释掉了,因为交叉编译环境无法运行测试

HPKCHECK 的设计就是为了在真实设备上执行测试,而不是在开发机上。

完整的测试生命周期

开发机上:

HPKBUILD prepare() → build() → package() → archive()

(编译完成,但无法运行测试)

OpenHarmony 设备上:

HPKCHECK openharmonycheck()

(部署产物,运行测试,收集结果)

执行流程详解

HPKCHECK 通过 test.sh 脚本触发执行:

cd lycium && ./test.sh sha

完整执行流程

./test.sh sha

├─ 1. 设置环境变量(LYCIUM_ROOT、LYCIUM_THIRDPARTY_ROOT、OHOS_SDK_VER)

├─ 2. checktestenv():检查 cmake/make/ctest/perl 是否存在

├─ 3. getcpuarchitecture():检测 CPU 架构(arm64-v8a 或 armeabi-v7a)

├─ 4. setloaddynamiclibrarypath():设置 LD_LIBRARY_PATH

├─ 5. 查找 sha 库目录

└─ 6. checkhpk():遍历测试

├─ 进入 thirdparty/sha/

├─ source ./HPKCHECK

│ ├─ source HPKBUILD(加载变量)

│ ├─ 设置 logfile

│ └─ 定义 openharmonycheck()

├─ 检查是否有 checkprepare()(可选的测试前准备)

├─ 调用 openharmonycheck()

│ ├─ cd$builddir/$ARCH-build

│ ├─ ctest > ${logfile} 2>&1

│ ├─ res=$?

│ └─ cd$OLDPWD

├─ 判断结果:成功 → successlibs / 失败 → failedlibs

└─ 收集日志到 LOG_PATH

执行前提条件

  1. 已编译:先在开发机上执行 ./build.sh sha
  2. 已部署:将编译产物推送到 OpenHarmony 设备
  3. 工具就绪:设备上有 cmake、make、ctest、perl(可通过 CItools 部署)

规范写法与模板

标准 HPKCHECK 模板

# Copyright (c) 2023 Huawei Device Co., Ltd.

# Licensed under the Apache License, Version 2.0 (the “License”);

# …

source HPKBUILD > /dev/null 2>&1

logfile=${LYCIUM_THIRDPARTY_ROOT}/${pkgname}/${pkgname}_${ARCH}_${OHOS_SDK_VER}_test.log

# 可选:测试前的准备工作

checkprepare() {

return 0

}

# 必需:在 OpenHarmony 设备上执行测试

openharmonycheck() {

cd$builddir/$ARCH-build

ctest > ${logfile} 2>&1

res=$?

cd$OLDPWD

return$res

}

不同测试框架的写法

常见问题

Q1:测试必须在 OpenHarmony 设备上运行吗?

是的。 交叉编译出的 ARM 可执行文件无法在 x86 开发机上运行。如果开发机也是 ARM 架构的鸿蒙 PC,则可以直接运行。

Q2:如何部署测试工具到设备?

cd lycium/CItools && ./env_build.sh

这会把 cmake、make、ctest 等工具部署到 OpenHarmony 设备上。

Q3:测试失败如何调试?

  1. 查看日志文件:cat ${logfile}
  2. 检查设备上是否安装了所有依赖库
  3. 确认 LD_LIBRARY_PATH 设置正确
  4. 手动在设备上运行测试程序

Q4:如果三方库没有测试用例怎么办?

  • 编写简单的测试程序验证基本功能
  • 在 HPKCHECK 中跳过测试,但要在文档中说明原因
  • 向上游项目贡献测试用例

Q5:checkprepare() 什么时候需要?

当测试前需要做额外准备时,比如:

  • 创建测试数据文件
  • 设置特殊的环境变量
  • 启动依赖的服务

对于 SHA 这种简单库,不需要 checkprepare()。

与其他文件的关系

HPKCHECK

├─ source HPKBUILD ← 加载构建变量

├─ ctest ← 执行 CMakeLists.txt 中定义的测试

└─ test.sh ← 被 test.sh 调用

总结

HPKCHECK 是 OpenHarmony 三方库质量把关的关键文件:

核心要点

  • HPKCHECK 必须在 OpenHarmony 设备上执行,因为交叉编译的产物无法在开发机运行
  • openharmonycheck() 是必须定义的函数,由 test.sh 调用
  • checkprepare() 是可选的测试前准备函数
  • 测试结果通过返回码传递:0 表示成功,非 0 表示失败

编译通过只是第一步,测试通过才是真正的成功。

本文由人人都是产品经理作者【nutpi】,微信公众号:【nutpi】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议