戰碼先鋒，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上這兩個庫和業界的有一定差異，不涉及硬件，不涉及驅動）。