本文是开源鸿蒙 PC 专项积分赛「实战复盘 · 路径 C」方向的第 4 篇。对应 PRhttps://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/merge_requests/19802归档目录archives/l/libfvad/1.0/一、为什么选 libfvad前一篇复盘里我们把 soundio 2.0.0 适配进了鸿蒙 PC解决了「音频怎么进出设备」的问题。但一个真实的语音应用链路是这样的麦克风采集soundio → 这一帧到底有没有人说话VAD → 唤醒/发包/推理中间那一步就是 VADVoice Activity Detection语音活动检测。Android、iOS、Windows上它基本是系统能力鸿蒙 PC 上没有对等的公开 API所以只能自己带库。libfvad 是 WebRTC VAD 算法的独立 C 提取版维度libfvad说明依赖标准 C 库 libm没有 sndfile / fftw / 任何三方依赖体积源码 ~300 KB产物静态库 ~150 KB适合塞进应用侧API4 个函数fvad_new/free/set_mode/set_sample_rate/process心智负担接近零许可BSD-3-Clause商用友好对鸿蒙 PC 来说它还有个额外好处它不碰任何平台音频子系统。它只吃int16_tPCM 帧所以在没有完整音频 HAL 的环境里也能跑通、能测通。二、上游工程结构决定了配方怎么写从 tag 拉下来的目录是这样的libfvad-1.0/ ├── configure.ac # autotools 工程 ├── Makefile.am ├── libfvad.pc.in # 会生成 pkg-config 文件 ├── include/fvad.h # 唯一公共头文件 ├── src/ │ ├── Makefile.am # 内部 libfvad_int.la 公共 libfvad.la │ ├── fvad.c │ ├── signal_processing/ │ └── vad/ ├── tests/ # 13 个 check_PROGRAMS wavtest.sh └── examples/ # fvadwav可选依赖 libsndfile三个关键事实git 归档里没有configure。GitHub 的 tag tarball 不含 autotools 生成物必须先autoreconf -fi。configure.ac里写着LT_INIT([disable-static pic-only])——默认只产.so。tests/Makefile.am里TESTS 13 个 check_PROGRAMS wavtest.sh共 14 项。三、配方设计的三个决策以及为什么本节先给出整条构建链路的流程图再逐一拆解三个关键决策。图中每个节点都对应配方里的一段代码读图时可以先建立整体印象再看细节。先看整条构建链路后面三个决策分别对应图中的不同节点tag 归档无 configureautoreconf -fitool_requires automake/libtoolconfigure--target/--sysroot 进 cflagsldflags、--disable-examplesmake -j1libfvad.a fvad.h libfvad.pctest_package 交叉编译链接上图可以按「准备 → 配置 → 编译 → 产物 → 验证」五段来读准备段A→Btag 归档里没有configure所以先autoreconf -fi生成构建脚本这一步依赖tool_requires补进来的 automake 与 libtool。配置段Cconfigure阶段把--target/--sysroot同时注入 cflags 与 ldflags并用--disable-examples切断 libsndfile 这条可选依赖。编译段D固定make -j1规避 HMDFS 上 jobserver fifo 的权限问题。产物段E最终得到libfvad.a、fvad.h、libfvad.pc三件套。验证段F由test_package交叉编译链接消费者程序承担「适配后能不能用」的证明责任。交叉构建下make check被跳过上游 14 项测试全是目标架构二进制宿主跑不了所以build()里用cross_building(self)门控只在非交叉构建时执行make check「适配后能不能用」改由末端的test_package承担——它用被测包导出的头文件和库编译链接一个消费者程序交叉构建时只编译链接真机/CI 上再执行。决策 1autoreconf -fi tool_requires 补齐 automake/libtoolCI worker 上只有 autoconf 家族autoconf/autoheader/autom4te没有automake、aclocal、libtoolize。直接跑autoreconf -fi会挂在aclocal: command not found。所以配方里显式声明构建期依赖defbuild_requirements(self):# git 归档没有 configurebootstrap 需要 automake libtoolize。# 这两个包以 build profile 解析因此 CI 需 -pr:h/-pr:b 双 profile。self.tool_requires(automake/1.18)self.tool_requires(libtool/2.5.4)defgenerate(self):tcAutotoolsToolchain(self)# 关键--target / --sysroot 同时进 cflags 与 ldflags见决策 3flags[f--target{self.settings.arch}-linux-ohos]sysrootself.conf.get(tools.build:sysroot,check_typestr)ifsysroot:flags.append(f--sysroot{sysroot})tc.cflags.extend(flags)tc.cxxflags.extend(flags)tc.ldflags.extend(flags)tc.configure_args[--disable-examples,# 见坑 4别拖进 libsndfile--disable-dependency-tracking,]envtc.environment()env.define(NOCONFIGURE,1)# 防止 configure.ac 里自动重跑 autogentc.generate()defbuild(self):# 归档里没有 configure先 bootstrapself.run(autoreconf -fi,envconanbuild)autotoolsAutotools(self)autotools.configure()autotools.make(args[-j1])# 见坑 3HMDFS 上 -jN 会 EPERM为什么不用 patch 塞一个现成的 configure生成的configure有 20 万行、带时间戳与宿主路径塞进归档既不可评审也不可复现。让构建时 bootstrap才是与上游一致的做法。决策 2默认产静态库而不是.so上游LT_INIT([disable-static pic-only])的意思是「我要动态库」但鸿蒙应用侧的实际情况反过来.so放进 HAP 后必须带签名段才能dlopen否则Permission denied签名要额外调binary-sign-tool产物不可移植静态库直接链进应用的可执行文件没有部署路径、没有签名、没有 soname 问题VAD 是个纯计算库不存在「多进程共享一份」的收益。因此配方暴露shared选项并默认False交给AutotoolsToolchain自动生成--disable-shared --enable-static它会把disable-static的默认值覆盖回来options{shared:[True,False],fPIC:[True,False]}default_options{shared:False,fPIC:True}决策 3--target/--sysroot必须同时进 cflags 和 ldflags这是最容易踩的坑。交叉编译时如果只把--targetaarch64-linux-ohos加到cflagsconfigure的链接探针那些checking whether the C compiler works...仍然会用宿主链接器。结果是「编译过了」但产物是宿主架构——测试在设备上直接Exec format error。所以flags[f--target{target}]ifsysroot:flags.append(f--sysroot{sysroot})tc.cflags.extend(flags)# 编译tc.cxxflags.extend(flags)tc.ldflags.extend(flags)# 链接缺这一行就会出现「假通过」--host用aarch64-linux-ohosconfig.sub 内置*-linux-ohos模式与 clang 的 triple 共用同一个字符串避免cannot guess build type。四、踩坑记录坑 1tag 根本不存在第一版conandata.yml我按直觉写了v1.3.0下载 404。查 GitHub tags API 才发现这个仓库只有v1.0一个 tagcurl-HUser-Agent: curl/8https://api.github.com/repos/dpirch/libfvad/tags# [{name:v1.0, ...}]教训写conandata.yml之前必须用 API 或git ls-remote --tags确认 tag 真实存在不要凭版本号直觉拼 URL。坑 2交叉编译不能跑make check上游 14 项测试全是目标架构二进制宿主跑不了。所以autotools.make(args[-j1])ifnotcross_building(self):autotools.make(targetcheck,args[-j1])那「适配后到底能不能用」靠什么证明靠test_package——它是 Conan 标准机制conan create时用被测包导出的头文件和库编译一个消费者程序交叉构建时只编译链接真机/CI 上再执行。坑 3make -j在 HMDFS 上会 EPERMmake -jN依赖 jobserver fifoHMDFS鸿蒙分布式文件系统对 fifo 的权限处理不同会直接Permission denied。所以整个仓库的配方都固定-j1。坑 4--enable-examples会拖进 libsndfile上游的fvadwav示例要读 wav 文件configure --enable-examples会走PKG_CHECK_MODULES([sndfile], [sndfile])。VAD 本体根本不需要它所以显式--disable-examples别让一条可选路径污染依赖链。五、测试设计12 项断言覆盖「数值 边界」test_package/test.c不打印任何「hello」全部是对库行为的断言#断言为什么要测1fvad_new()非 NULL链接到fvad_*符号不是只编过头文件2fvad_set_mode(0..3)返回 0合法区间3fvad_set_mode(4)返回 -1边界必须拒绝否则上层传错值会静默降级4fvad_set_sample_rate(8000/16000/32000/48000)返回 0四个合法采样率全覆盖5fvad_set_sample_rate(44100)返回 -144100 是「看起来合理」的错误值最容易漏测6全零 20ms 帧160 样本 8k→ 0静音判定7100 样本非法帧长→ -1上游对帧长硬校验8未set_sample_rate直接process→ -1状态机前置条件9fvad_reset()后仍可用状态机不残留10同一帧连续process两次结果一致无隐藏内部状态漂移11正弦波 1kHz 帧 → 1有声判定不只是「不崩」12fvad_free()不崩生命周期闭环这张表可以按三类来读接口契约1–5验证参数校验与边界拒绝行为正确性6、11用静音帧与正弦波帧两头钉住判定结果状态机与生命周期7–10、12覆盖非法帧长、前置条件、reset 与释放。12 项断言、退出码非 0 即失败CI 直接判定。其中 6 与 11 是一对只测静音会漏掉「永远返回 0」的实现只测有声会漏掉「永远返回 1」的实现必须两头都钉住。六、结果开发界面如下运行效果如下PR#19802归档archives/l/libfvad/1.0/conanfile.py / conandata.yml / manifest.yaml /notes.md / test_package 三件套构建产物libfvad.a约 148 KBaarch64-linux-ohosfvad.hlibfvad.pc上游测试清点14 项13 unittest wavtest.sh源文件与命令逐条登记在test_package/MANIFEST.yml新增消费者测试12 项断言交叉构建下编译链接通过真机执行全绿依赖树conan graph info显示运行时依赖为空仅 libc / libm构建期依赖为 automake libtool不进最终产物七、总结这次 libfvad 1.0 的适配本质上不是「把一个库编译过去」而是把一条可复现的构建链路固化下来。回看整个过程可以提炼成四点先读上游再写配方。configure.ac里的LT_INIT([disable-static pic-only])、tests/Makefile.am里的 14 项测试、examples/对 libsndfile 的依赖这三处信息直接决定了后面三个决策比试错快得多。归档里没有的东西构建时补。configure不进归档改用autoreconf -fitool_requires既保持与上游一致也让产物可评审、可复现。交叉编译的坑集中在「链接」而不是「编译」。--target/--sysroot只进 cflags 会得到「假通过」的宿主产物必须同时进 ldflagsmake check同理宿主跑不了目标二进制只能靠test_package兜底。验证要能证伪。12 项断言里既有合法值也有非法值既有静音也有有声任何一侧缺失都会让「永远返回 0」或「永远返回 1」的实现蒙混过关。从结果看产物是约 148 KB 的libfvad.a加一个头文件和一个 pkg-config 文件运行时依赖为空构建期依赖不进最终产物——这正是「能装进采集链路」的形态。下一篇复盘换一种构建系统LibXtract 是纯手写 Makefile没有 configure坑全在变量优先级和平台探测上那是另一套完全不同的坑。 本文是开源鸿蒙 PC 专项积分赛「实战复盘 · 路径 C」方向的第 4 篇。对应 PRhttps://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/merge_requests/19802归档目录archives/l/libfvad/1.0/一、为什么选 libfvad前一篇复盘里我们把 soundio 2.0.0 适配进了鸿蒙 PC解决了「音频怎么进出设备」的问题。但一个真实的语音应用链路是这样的麦克风采集soundio → 这一帧到底有没有人说话VAD → 唤醒/发包/推理中间那一步就是 VADVoice Activity Detection语音活动检测。Android、iOS、Windows上它基本是系统能力鸿蒙 PC 上没有对等的公开 API所以只能自己带库。libfvad 是 WebRTC VAD 算法的独立 C 提取版维度libfvad说明依赖标准 C 库 libm没有 sndfile / fftw / 任何三方依赖体积源码 ~300 KB产物静态库 ~150 KB适合塞进应用侧API4 个函数fvad_new/free/set_mode/set_sample_rate/process心智负担接近零许可BSD-3-Clause商用友好对鸿蒙 PC 来说它还有个额外好处它不碰任何平台音频子系统。它只吃int16_tPCM 帧所以在没有完整音频 HAL 的环境里也能跑通、能测通。二、上游工程结构决定了配方怎么写从 tag 拉下来的目录是这样的libfvad-1.0/ ├── configure.ac # autotools 工程 ├── Makefile.am ├── libfvad.pc.in # 会生成 pkg-config 文件 ├── include/fvad.h # 唯一公共头文件 ├── src/ │ ├── Makefile.am # 内部 libfvad_int.la 公共 libfvad.la │ ├── fvad.c │ ├── signal_processing/ │ └── vad/ ├── tests/ # 13 个 check_PROGRAMS wavtest.sh └── examples/ # fvadwav可选依赖 libsndfile三个关键事实git 归档里没有configure。GitHub 的 tag tarball 不含 autotools 生成物必须先autoreconf -fi。configure.ac里写着LT_INIT([disable-static pic-only])——默认只产.so。tests/Makefile.am里TESTS 13 个 check_PROGRAMS wavtest.sh共 14 项。三、配方设计的三个决策以及为什么本节先给出整条构建链路的流程图再逐一拆解三个关键决策。图中每个节点都对应配方里的一段代码读图时可以先建立整体印象再看细节。先看整条构建链路后面三个决策分别对应图中的不同节点tag 归档无 configureautoreconf -fitool_requires automake/libtoolconfigure--target/--sysroot 进 cflagsldflags、--disable-examplesmake -j1libfvad.a fvad.h libfvad.pctest_package 交叉编译链接上图可以按「准备 → 配置 → 编译 → 产物 → 验证」五段来读准备段A→Btag 归档里没有configure所以先autoreconf -fi生成构建脚本这一步依赖tool_requires补进来的 automake 与 libtool。配置段Cconfigure阶段把--target/--sysroot同时注入 cflags 与 ldflags并用--disable-examples切断 libsndfile 这条可选依赖。编译段D固定make -j1规避 HMDFS 上 jobserver fifo 的权限问题。产物段E最终得到libfvad.a、fvad.h、libfvad.pc三件套。验证段F由test_package交叉编译链接消费者程序承担「适配后能不能用」的证明责任。交叉构建下make check被跳过上游 14 项测试全是目标架构二进制宿主跑不了所以build()里用cross_building(self)门控只在非交叉构建时执行make check「适配后能不能用」改由末端的test_package承担——它用被测包导出的头文件和库编译链接一个消费者程序交叉构建时只编译链接真机/CI 上再执行。决策 1autoreconf -fi tool_requires 补齐 automake/libtoolCI worker 上只有 autoconf 家族autoconf/autoheader/autom4te没有automake、aclocal、libtoolize。直接跑autoreconf -fi会挂在aclocal: command not found。所以配方里显式声明构建期依赖defbuild_requirements(self):# git 归档没有 configurebootstrap 需要 automake libtoolize。# 这两个包以 build profile 解析因此 CI 需 -pr:h/-pr:b 双 profile。self.tool_requires(automake/1.18)self.tool_requires(libtool/2.5.4)defgenerate(self):tcAutotoolsToolchain(self)# 关键--target / --sysroot 同时进 cflags 与 ldflags见决策 3flags[f--target{self.settings.arch}-linux-ohos]sysrootself.conf.get(tools.build:sysroot,check_typestr)ifsysroot:flags.append(f--sysroot{sysroot})tc.cflags.extend(flags)tc.cxxflags.extend(flags)tc.ldflags.extend(flags)tc.configure_args[--disable-examples,# 见坑 4别拖进 libsndfile--disable-dependency-tracking,]envtc.environment()env.define(NOCONFIGURE,1)# 防止 configure.ac 里自动重跑 autogentc.generate()defbuild(self):# 归档里没有 configure先 bootstrapself.run(autoreconf -fi,envconanbuild)autotoolsAutotools(self)autotools.configure()autotools.make(args[-j1])# 见坑 3HMDFS 上 -jN 会 EPERM为什么不用 patch 塞一个现成的 configure生成的configure有 20 万行、带时间戳与宿主路径塞进归档既不可评审也不可复现。让构建时 bootstrap才是与上游一致的做法。决策 2默认产静态库而不是.so上游LT_INIT([disable-static pic-only])的意思是「我要动态库」但鸿蒙应用侧的实际情况反过来.so放进 HAP 后必须带签名段才能dlopen否则Permission denied签名要额外调binary-sign-tool产物不可移植静态库直接链进应用的可执行文件没有部署路径、没有签名、没有 soname 问题VAD 是个纯计算库不存在「多进程共享一份」的收益。因此配方暴露shared选项并默认False交给AutotoolsToolchain自动生成--disable-shared --enable-static它会把disable-static的默认值覆盖回来options{shared:[True,False],fPIC:[True,False]}default_options{shared:False,fPIC:True}决策 3--target/--sysroot必须同时进 cflags 和 ldflags这是最容易踩的坑。交叉编译时如果只把--targetaarch64-linux-ohos加到cflagsconfigure的链接探针那些checking whether the C compiler works...仍然会用宿主链接器。结果是「编译过了」但产物是宿主架构——测试在设备上直接Exec format error。所以flags[f--target{target}]ifsysroot:flags.append(f--sysroot{sysroot})tc.cflags.extend(flags)# 编译tc.cxxflags.extend(flags)tc.ldflags.extend(flags)# 链接缺这一行就会出现「假通过」--host用aarch64-linux-ohosconfig.sub 内置*-linux-ohos模式与 clang 的 triple 共用同一个字符串避免cannot guess build type。四、踩坑记录坑 1tag 根本不存在第一版conandata.yml我按直觉写了v1.3.0下载 404。查 GitHub tags API 才发现这个仓库只有v1.0一个 tagcurl-HUser-Agent: curl/8https://api.github.com/repos/dpirch/libfvad/tags# [{name:v1.0, ...}]教训写conandata.yml之前必须用 API 或git ls-remote --tags确认 tag 真实存在不要凭版本号直觉拼 URL。坑 2交叉编译不能跑make check上游 14 项测试全是目标架构二进制宿主跑不了。所以autotools.make(args[-j1])ifnotcross_building(self):autotools.make(targetcheck,args[-j1])那「适配后到底能不能用」靠什么证明靠test_package——它是 Conan 标准机制conan create时用被测包导出的头文件和库编译一个消费者程序交叉构建时只编译链接真机/CI 上再执行。坑 3make -j在 HMDFS 上会 EPERMmake -jN依赖 jobserver fifoHMDFS鸿蒙分布式文件系统对 fifo 的权限处理不同会直接Permission denied。所以整个仓库的配方都固定-j1。坑 4--enable-examples会拖进 libsndfile上游的fvadwav示例要读 wav 文件configure --enable-examples会走PKG_CHECK_MODULES([sndfile], [sndfile])。VAD 本体根本不需要它所以显式--disable-examples别让一条可选路径污染依赖链。五、测试设计12 项断言覆盖「数值 边界」test_package/test.c不打印任何「hello」全部是对库行为的断言#断言为什么要测1fvad_new()非 NULL链接到fvad_*符号不是只编过头文件2fvad_set_mode(0..3)返回 0合法区间3fvad_set_mode(4)返回 -1边界必须拒绝否则上层传错值会静默降级4fvad_set_sample_rate(8000/16000/32000/48000)返回 0四个合法采样率全覆盖5fvad_set_sample_rate(44100)返回 -144100 是「看起来合理」的错误值最容易漏测6全零 20ms 帧160 样本 8k→ 0静音判定7100 样本非法帧长→ -1上游对帧长硬校验8未set_sample_rate直接process→ -1状态机前置条件9fvad_reset()后仍可用状态机不残留10同一帧连续process两次结果一致无隐藏内部状态漂移11正弦波 1kHz 帧 → 1有声判定不只是「不崩」12fvad_free()不崩生命周期闭环这张表可以按三类来读接口契约1–5验证参数校验与边界拒绝行为正确性6、11用静音帧与正弦波帧两头钉住判定结果状态机与生命周期7–10、12覆盖非法帧长、前置条件、reset 与释放。12 项断言、退出码非 0 即失败CI 直接判定。其中 6 与 11 是一对只测静音会漏掉「永远返回 0」的实现只测有声会漏掉「永远返回 1」的实现必须两头都钉住。六、结果开发界面如下运行效果如下PR#19802归档archives/l/libfvad/1.0/conanfile.py / conandata.yml / manifest.yaml /notes.md / test_package 三件套构建产物libfvad.a约 148 KBaarch64-linux-ohosfvad.hlibfvad.pc上游测试清点14 项13 unittest wavtest.sh源文件与命令逐条登记在test_package/MANIFEST.yml新增消费者测试12 项断言交叉构建下编译链接通过真机执行全绿依赖树conan graph info显示运行时依赖为空仅 libc / libm构建期依赖为 automake libtool不进最终产物七、总结这次 libfvad 1.0 的适配本质上不是「把一个库编译过去」而是把一条可复现的构建链路固化下来。回看整个过程可以提炼成四点先读上游再写配方。configure.ac里的LT_INIT([disable-static pic-only])、tests/Makefile.am里的 14 项测试、examples/对 libsndfile 的依赖这三处信息直接决定了后面三个决策比试错快得多。归档里没有的东西构建时补。configure不进归档改用autoreconf -fitool_requires既保持与上游一致也让产物可评审、可复现。交叉编译的坑集中在「链接」而不是「编译」。--target/--sysroot只进 cflags 会得到「假通过」的宿主产物必须同时进 ldflagsmake check同理宿主跑不了目标二进制只能靠test_package兜底。验证要能证伪。12 项断言里既有合法值也有非法值既有静音也有有声任何一侧缺失都会让「永远返回 0」或「永远返回 1」的实现蒙混过关。从结果看产物是约 148 KB 的libfvad.a加一个头文件和一个 pkg-config 文件运行时依赖为空构建期依赖不进最终产物——这正是「能装进采集链路」的形态。下一篇复盘换一种构建系统LibXtract 是纯手写 Makefile没有 configure坑全在变量优先级和平台探测上那是另一套完全不同的坑。