三方库移植OpenHarmony过程

战码先锋，PR征集令（以下简称“战码先锋”）第二期正如火如荼地进行中，涉及OpenAtom OpenHarmony（以下简称“OpenHarmony”）主干仓、SIG仓、三方库，共计1000+代码仓任君挑战。

在战码先锋活动中，我们注意到开发者对三方库移植有着浓厚的兴趣。三方库是基于标准Linux系统的C/C++开源库，例如OpenCV、LZMA压缩算法、ZXing-cpp图像处理库，三方库移植能为OpenHarmony项目补齐更多功能或组件，对繁荣生态非常重要。

三方库移植也为参与OpenHarmony贡献提供了另外一种思路，我们希望通过实战经验的分享鼓励更多感兴趣的开发者动手移植自己心仪的三方库。为此，我们邀请目前还是一名大三学生，也是战码先锋优秀贡献者，OpenHarmony啃论文俱乐部优秀学员——贾佳豪（社区网名：离北况归）进行分享，他在完成了一个三方库在OpenHarmony标准系统上的移植工作后，总结了以下经验。

四步实现三方库移植：1、在Linux下编译要移植的三仓库，分析编译过程；2、将要移植的三方库加入编译框架中以及产品引用；3、增量编译出动态链接库和可执行文件推送到开发板上；4、在开发板上验证移植是否成功、API接口导出。

第一步

三方库下载最新分支代码后在Linux下编译，分析编译过程。 观察原生库目录结构或者Readme可以知道该如何编译，一般有如下两种编译方式： ①在原生库根目录中，存在CMakeLists.txt文件。在原生库下新建build目录通过cmake或者cmake-gui生成makeflie然后make。 ②在原生库目录中存在autogen.sh,configure.ac文件，原生库使用Makefile.am构建，./autogen.sh再./configure命令生成Makefile，最后make、make install。

在Linux下编译原生库要配置好编译环境，安装cmake、make、automake等工具。

分析编译过程：

提取编译出动态链接库和测试用的可执行文件需要的源文件和头文件、编译时添加的cflag、编译器参数以及编译需要链接的库。该过程分为如下两种情况：

①在cmake生成makefile的过程中分析build.make、depend.make、flags.make、link.txt等得出三方库对应的依赖关系。

②使用Makefile.am构建的三方库通过分析make.am内容可以直接分析编译动态链接库和测试用的可执行文件需要哪些源文件，而编译需要添加的编译器参数和需要链接的库则通过分析三方库父目录makefile文件提取。

第二步

根据第一步分析得到的结果把三方库加入OpenHarmony编译构建体系。 ①定义子系统并加入编译框架。首先把三方库放置在OpenHarmony源码third_party目录下作为子系统目录。子系统目录下创建ohos.build文件，构建时会先读取该文件。

把子系统配置到build/subsystem_config.json.

②定义组件并加入子系统：在上述定义子系统时添加的ohos.build文件中，我们已经定义好了对应的组件。

module_list所定义的为该组件的目标，上述定义的目标为测试用的可执行文件。

③定义目标并加入组件：在编写gn文的时候，我们定义的动态库以及测试可执行程序都是我们的目标模块，在每个目标模块中添加对应的组件名后即将我们的目标模块加入该组件中。

④产品引用：把子系统及其组件加入产品定义中，以rk3568为例，产品定义文件存在vendor/hihope/rk3568/config.json，以下内容添加到config.json中：

第三步

增量编译出动态链接库和可执行文件，在OpenHarmony源码执行。

./build.sh --product-name rk3568 --ccache --build-target=移植的三方库名称 --target-cpu arm64

（ohos更新到3.2版本后，支持64位系统的编译，默认情况下编译的都是32位系统，在编译命令中添加--target-cpu arm64即可构建64位系统）

第一次编译可能会报错，我们根据报错信息调整编写的gn文件。消除clang编译警告，例如-Wimplicit-function-declaration改为-Wno-implicit-function-declaration添加到gn文的cflags信息里面。不推荐直接全量编译出镜像烧录到开发板上。将耗费较多时间，也不便编译调试。编译成功生成的动态链接库和测试用的可执行文件在out目录下。

第四步

在开发板上验证移植是否成功、API接口导出。

利用hdc_std工具将编译出的so动态链接库和测试用的可执行文件放到开发板上，验证移植的三方库功能是否正常。

API是指应用程序编程接口，通过API接口可以实现指定的功能，而不需要了解其内部实现细节。API接口导出在pc端，需要编译生成的动态链接库和测试用的可执行文件。API接口导出思路如下：

①新建allHeads.h，该头文件中包含所有库对外导出的头文件

②新增allDySos目录，该目录下放置生成的动态库

③新增allTests目录，该目录下放置所有生成的测试用的可执行文件

④新建自动化测试脚本export_interface.sh，脚本如下，执行时需要给脚本传入编译头文件的参数例如./export_interface.sh -I头文件所在路径-D宏定义（编译所有动态库时，cflags/cflags_cc中的参数）

 

cxx="0"：mixed_api() {
    while read line    do        if [ $cxx != "1" -o "$4" == "1" ];then            tmp=$line        else            tmp=`echo $line | sed "s/(.*$//g" | sed "s/^.*:://g"`        fi        res=`cat $2 |grep "$tmp" -F`        if [ "$res" != "" ];then            echo "$line" >> $3        fi    done < $1}

 

 

以上是部分代码展现，阅览全部代码请打开链接

https://gitee.com/openharmony-sig/contest/tree/master/2022_OpenHarmony_thirdparty/speexdsp

再次总结四步要点：1、在Linux下编译要移植的三仓库，分析编译过程；2、将要移植的三方库加入编译框架中以及产品引用；3、增量编译出动态链接库和可执行文件推送到开发板上。4、在开发板上验证移植是否成功、API接口导出。

备注：三方库的移植需要搭建好OpenHarmony南向开发环境，也需要有开发板和掌握hdc_std工具的使用。另外，这样移植有一个前提，与平台无关（即库不涉及对os_api有依赖，不涉及opensl以及opengl，ohos上这两个库和业界的有一定差异，不涉及硬件，不涉及驱动）。