共计 3098 个字符，预计需要花费 8 分钟才能阅读完成。
战码先锋，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…
再次总结四步要点：1、在 Linux 下编译要移植的三仓库，剖析编译过程；2、将要移植的三方库退出编译框架中以及产品援用；3、增量编译出动态链接库和可执行文件推送到开发板上。4、在开发板上验证移植是否胜利、API 接口导出。
备注：三方库的移植须要搭建好 OpenHarmony 南向开发环境，也须要有开发板和把握 hdc_std 工具的应用。另外，这样移植有一个前提，与平台无关（即库不波及对 os_api 有依赖，不波及 opensl 以及 opengl，ohos 上这两个库和业界的有肯定差别，不波及硬件，不波及驱动）。
更多三方库移植办法请参考：《一文带你读懂如何移植三方库到 OpenHarmony》
欢送感兴趣的开发者敌人们一起参加战码先锋和 OpenHarmony 啃论文俱乐部流动！在 Gitee 的 OpenHarmony 代码仓提交 PR 参加流动，和寰球的开发者一起共建 OpenHarmony 的凋敝生态！当初就关上 Gitee，为 OpenHarmony 提 PR，你的一小步，就是 OpenHarmony 开源的一大步。
大家也能够动起手来移植本人感兴趣的三方库到 OpenHarmony，移植的三方库提交至仓库：https://gitee.com/openharmony…。将你对 OpenHarmony 社区的每一份奉献都会被永恒地记录下来。