啃论文俱乐部——移植speexdsp到OpenHarmony标准系统④ 原创 精华
- 大家好!我来自南京,在OpenHarmony成长计划啃论文俱乐部,与
华为、软通动力、润和软件、拓维信息、深开鸿
等公司一起,学习和研究操作系统技术
从今年1月11日加入OpenHarmony俱乐部已经有接近8个月时间了。笔者一直在思考啃论文给我带来了些什么,通过啃论文能为OpenHarmony做些什么。笔者利用大二升大三暑假两个月时间移植了Speexdsp这个三方库到OpenHarmony标准系统,而关于前面的问题我似乎找到了答案,现将啃论文和三方库移植分享经验如下:
由于想要分享的内容较多,为避免读者姥爷们失去看下去的耐心,分享将以连载的方式进行。
下期预告:speexdsp功能分析和功能测试
往期回顾:
啃论文俱乐部——移植speexdsp到OpenHarmony标准系统①
啃论文俱乐部——移植speexdsp到OpenHarmony标准系统②
啃论文俱乐部——移植speexdsp到OpenHarmony标准系统③
本期为移植speexdsp到OpenHarmony标准系统
的第④期,主要内容如下:
目录
- 五、在OpenHarmony编译体系下增量编译Speexdsp
- 六、API接口导出
- 1.在export_api目录下新建allHeads.h文件
- 2.新增allDySos目录,该目录下放置生成的动态库:
- 3、新增allTests目录,该目录下放置所有生成的测试文件:
- 4、新建自动化测试脚本export_interface.sh,如下所示:
- 执行脚本导出api接口
- 下期预告:speexdsp功能分析和功能测试
speexdsp移植后已提交至openhamrony sig仓库:https://gitee.com/openharmony-sig/contest/tree/master/2022_OpenHarmony_thirdparty/speexdsp
五、在OpenHarmony编译体系下增量编译Speexdsp
建议先增量编译生成三方库的动态链接库和可执行文件,验证是否成功把三方库加入OpenHarmonybian编译体系。
- 成功编译出so和可执行文件,即成功把三方库加入到ohos编译体系。之后还要验证三方库在ohos运行,功能是否正常。功能正常才能视为移植成功。
推荐增量编译出三方库的动态链接库和测试用例,不推荐的做法是把三方库加入openharmony编译体系后全量编译出烧录ohos用的固件。
- 第一是因为全量编译ohos对电脑的性能,特别是内存要求比较高(笔者的笔记本上的虚拟机内存给到了32G,对学生开发者来讲,编译ohos的硬件门槛还是有点高的。)增量编译对内存要求不是特别高。(笔者的8G内存二合一笔记本都可以编译出来,并且虚拟机内存只给到了4GB左右)
- 第二是因为全量编译花费时间较多(笔者完整编译出一个固件需要3个小时左右。)增量编译需要的时间相对较少(笔者大概只需要花费9分钟左右)
全量编译和增量编译概念
- 全量编译是将所有文件重新编译,重新生成解决方案就是全量编译
- 增量编译只对改动的文件进行编译,执行生成解决方案就是增量编译
ohos3.2beta1
版本开始新增特性,支持64位系统的编译,默认情况下编译的都是32位系统,在编译命令中添加--target-cpu arm64
即可构建64位系统,编译so和可执行文件的执行语句更改为:
在源码目录执行如下命令,进行增量编译:
加快本地编译的一些参数
编译时,适当选择添加以下的编译参数可以加快编译的过程。
- 添加–ccache参数:
- 原理:ccache会缓存c/c++编译的编译输出,下一次在编译输入不变的情况下,直接复用缓存的产物。
- 安装:
- 快速安装:执行sudo apt-get install ccache命令。
- 使用:执行./build.sh --product-name 产品名 --ccache命令。
- 添加–fast-rebuild参数
- 原理:编译流程主要分为:preloader->loader->gn->ninja这四个过程,在本地没有修改gn和产品配置相关文件的前提下,添加–fast-rebuild会让你直接从ninja编译开始。
- 使用:执行./build.sh --product-name 产品名 --fast-rebuild命令。
- 添加enable_notice_collection=false参数
- 原理:省略掉收集开源软件模块的license的过程。
- 使用:执行./build.sh --product-name 产品名 --gn-args --enable_notice_collection=false --ccache命令。
- 添加–build-target参数
- 该参数用于指定编译模块,如何找模块的名字:
- 相关仓下BUILD.gn中关注group、ohos_shared_library、ohos_executable等关键字。
- ./build.sh --product-name 产品名 --build-target 模块名 --build-only-gn生成build.ninja,然后去该文件中查找相关模块名。
- 使用:执行./build.sh --product-name 产品名 --build-target ark_js_host_linux_tools_packages命令。
解决编译报错
(笔者理解移植过程肯定不会是一帆风顺的)
执行编译命令后,有部分报错
1.部分头文件缺失报错
‘speexdsp_config_types.h’ file not found
编译找不到third_party/speexdsp/include/speex目录下的speexdsp_config_types.h文件。
解决办法:
- speexdsp_types.h 是由linux下编译生成的,因此需要在Linux下编译整个Speexdsp源码,然后把在speexdsp原生库目录下build/include/speex目录生成的speexdsp_types.h文件拷贝到要ohos源码下的third_party/speexdsp/include/speex目录下,
2.json文件语法发生错误。
解决方法:
查看out/rk3568目录下build.log文件,检查源码/build/subsystem_config.json文件语法
笔者出现这个问题的原因是json文件语法发生错误,在subsystem_config.json文件第一行的{
没有匹配}
,添加上去就没问题。
编译成功
解决完编译报错后,再次执行编译命令。
编译成功,终端打印信息如下:
(下面只选取关键的一小部分,实际打印出来的信息有两千行左右。)
验证编译结果
编译speexdsp生成的动态链接库和测试用的可执行程序,在openharmony源码目录的out/rk3568下。
out/rk3568/speexdsp目录结构如下:
六、API接口导出
在源码third_party/speexdsp目录下新建export_api文件夹。
1.在export_api目录下新建allHeads.h文件
该头文件中包含所有库对外导出的头文件。speexdsp有5个测试程序testdenoise、testecho、testjitter、testresample、testresample2。
查看这五个测试程序的源文件testdenoise.c、testecho.c、testjitter.c、testresample.c、testresample2.c。
其用到的libspeexdsp_share.z.so的头文件如下:
2.新增allDySos目录,该目录下放置生成的动态库:
3、新增allTests目录,该目录下放置所有生成的测试文件:
4、新建自动化测试脚本export_interface.sh,如下所示:
其中cxx="0"表示根据.c文件进行导出,cxx="1"则表示根据.cpp文件进行导出(如果导出c++的三方库的api接口,使用该脚本就让cxx=1):
执行脚本导出api接口
执行该脚本导出api接口时,需要给脚本传入编译头文件的参数。(运行此api接口导出脚本在PC端)
- 例如
./export_interface.sh -I 头文件所在路径 -D宏定义(编译所有动态库时,cflags/cflags_cc中的参数)
- 头文件所在路径为绝对路径
- D宏定义指的是(编译所有动态库时,cflags/cflags_cc中的参数)
笔者导出speexdsp API接口,在export_api文件夹下打开终端输入了如下命令:
结果是生成export_api.txt(导出so对外api接口)与testd_api.txt(导出测试程序所用到so对外导出api接口 )。
export_api.txt文件内容如下:
tested_api.txt文件内容如下:
增量编译看来比起全量编译的好处确实大很多,如果每次编译都要3小时也太折磨人了。
编译一个ohos固件,虚拟机内训要给到16G以上,硬件门槛还是很高的
这个必须用c开发吗
不需要用到c
一路追下来是真的干货,期待后续测试部分
第五期已更新https://ost.51cto.com/posts/16990
请问增量编译之前需要进行一次全量编译吗?