- 在三方庫移植之NAPI開發[1]—Hello OpenHarmony NAPI一文中,筆者開發的是一個
包的napi工程。該工程需要編譯燒錄固件,C ++的動态庫會內建到開發闆的ROM中。rom
- 在本篇文章中,筆者使用三方庫移植之NAPI開發[1]—Hello OpenHarmony NAPI中一樣的hellonapi.cpp和index.ets源碼,通過IDE開發一個
包的NAPI工程(內建C ++的動态庫到開發闆的RAM中),直接編譯安裝hap包到開發闆即可。兩個開發方式的hap包運作效果一緻。RAM
往期回顧:
三方庫移植之NAPI開發[1]—Hello OpenHarmony NAPI
三方庫移植之NAPI開發[2]C/C++與JS的資料類型轉換
(目錄)
開發環境:
- IDE:DevEco Studio 3.0 Release
- 開發闆:潤和DAYU200開發闆
建立工程
打開IDE,建立一個Native C++工程。
SDK選擇API9,model選擇Stage。
源碼實作
- 建立的Native C++工程有一個預設的hello world教程,接下來需要編輯的檔案如下
C++方法實作
将預設的hello.cpp檔案重命名為hellonapi.cpp,選中右鍵選中重構重命名。
hellonapi.cpp内容如下:
#include "napi/native_api.h"
#include <string>
//接口業務實作C/C++代碼
//std::string 需要引入string頭檔案,#include <string>
static napi_value getHelloString(napi_env env, napi_callback_info info) {
napi_value result;
std::string words = "Hello OpenHarmony NAPI";
//NAPI_CALL(env, napi_create_string_utf8(env, words.c_str(), words.length(), &result));
napi_create_string_utf8(env, words.c_str(), words.length(), &result);
return result;
}
// napi_addon_register_func
//2.指定子產品注冊對外接口的處理函數,具體擴充的接口在該函數中聲明
static napi_value registerFunc(napi_env env, napi_value exports)
{
static napi_property_descriptor desc[] = {
// 聲明該napi_module對外具體的提供的API
{ "getHelloString", nullptr, getHelloString, nullptr, nullptr, nullptr, napi_default, nullptr }
};
//NAPI_CALL(env, napi_define_properties(env, exports, sizeof(desc) / sizeof(desc[0]), desc));
napi_define_properties(env, exports, sizeof(desc) / sizeof(desc[0]), desc);
return exports;
}
// 1.先定義napi_module,指定目前NAPI子產品對應的子產品名
//以及子產品注冊對外接口的處理函數,具體擴充的接口在該函數中聲明
// nm_modname: 子產品名稱,對應eTS代碼為import nm_modname from '@ohos.ohos_shared_library_name'
//示例對應eTS代碼為:import hellonapi from '@ohos.hellonapi'
static napi_module hellonapiModule = {
.nm_version = 1,
.nm_flags = 0,
.nm_filename = nullptr,
.nm_register_func = registerFunc, // 子產品對外接口注冊函數
.nm_modname = "hellonapi", // 自定義子產品名
.nm_priv = ((void*)0),
.reserved = { 0 },
};
//3.子產品定義好後,調用NAPI提供的子產品注冊函數napi_module_register(napi_module* mod)函數注冊到系統中。
// register module,裝置啟動時自動調用此constructor函數,把子產品定義的子產品注冊到系統中
extern "C" __attribute__((constructor)) void hellonapiModuleRegister()
{
napi_module_register(&hellonapiModule);
}
此時的native_api.h檔案是在sdk\native\3.2.7.5\sysroot\usr\include\napi目錄下
CMakeLists.txt編譯配置檔案編寫
- 和開發rom包的NAPI工程需要在BUILD.gn檔案中指定編譯so庫需要的頭檔案和源檔案、動态庫名稱、依賴的庫一樣,通過IDE開發ROM包時也需要在CMakeLists.txt中指定編譯so庫需要的頭檔案和源檔案、動态庫名稱、依賴的庫,内容如下:
# the minimum version of CMake.指明了對cmake的最低(高)版本的要求
cmake_minimum_required(VERSION 3.4.1)
#配置項目資訊(建立native C++工程時候的工程名稱)
project(MyApplication3)
#指定程式設計語言
set(NATIVERENDER_ROOT_PATH ${CMAKE_CURRENT_SOURCE_DIR})
#設定頭檔案的搜尋目錄
include_directories(${NATIVERENDER_ROOT_PATH}
${NATIVERENDER_ROOT_PATH}/include)
# 添加名為xxx的庫
add_library(hellonapi SHARED hellonapi.cpp)
#建構此可執行檔案需要連結的庫
target_link_libraries(hellonapi PUBLIC libace_napi.z.so)
-
路徑指的是sdk\native\3.2.7.5\sysroot\usrNATIVERENDER_ROOT_PATH
-
表示編譯libhellonapi.so需要的是hellonapi.cppadd_library(hellonapi SHARED hellonapi.cpp)
-
target_link_libraries(hellonapi PUBLIC libace_napi.z.so)
表示編譯編譯libhellonapi.so依賴libace_napi.z.so
開發ROM包的NAPI工程時,libhellonapi.z.so也依賴libace_napi.z.so,以下為開發ROM包的NAPI工程時BUILD.gn檔案
libhellonapi.so依賴的libace_napi.z.so在sdk\native\3.2.7.5\sysroot\usr\lib\aarch64-linux-ohos目錄下
sdk\native\3.2.7.5\sysroot\usr\lib\arm-linux-ohos目錄下也有開發ROM包的NAPI時候可能依賴的動态庫。
index.d.ts聲明檔案編寫
![](https://img.laitimes.com/img/_0nNw4CM6IyYiwiM6ICdiwiI4UTMfhGLwIDOfdHLlpXazVmcvwVZnFWbp1zczV2YvJHctM3cv1Ce-cmbw5iZ0cTO5UTOhZjYlNDZmdTO1MTM3Q2YihzYmNWY4UTO2cDM0kTO38CXwEjMyAjMvw1cldWYtl2Lc12bj5yb0NWM14ycvlnbv1mchhWLsR2Lc9CX6MHc0RHaiojIsJye.png)
index.d.ts内容如下:
export const getHelloString: () => string;
界面設計
index.ets和三方庫移植之NAPI開發[1]—Hello OpenHarmony NAPI一文中一緻。
import prompt from '@system.prompt'
import hellonapi from 'libhellonapi.so'
@Entry
@Component
export struct HelloNAPI {
build() {
Flex({ direction: FlexDirection.Column, alignItems: ItemAlign.Center, justifyContent: FlexAlign.Center }) {
Button("NAPI: hellonapi.getHelloString()").margin(10).fontSize(24).onClick(() => {
// 調用getHelloString接口
let strFromNAPI = hellonapi.getHelloString()
prompt.showToast({ message: strFromNAPI })
})
}
.width('100%')
.height('100%')
}
}
json配置檔案編寫
- package.json内容如下
{
"name": "libhellonapi.so",
"types": "./index.d.ts"
}
- entry/package-lock.json内容如下
"@types/libhellonapi.so":"file:./src/main/cpp/types/libhellonapi"
有報錯就删除原有的libentry.so符号連結
- entry/package.json内容如下
"@types/libhellonapi.so": {
"version": "file:src/main/cpp/types/libhellonapi",
- 修改原有的libentry為libhellonapi
- 設定hap為自動簽名
hap包運作效果
和三方庫移植之NAPI開發[1]—Hello OpenHarmony NAPI一文效果一緻
總結:RAM包的NAPI工程和ROM包的NAPI工程的異同
以下為個人總結,希望各位老師和同學批評指正
- 動态庫的命名方式的不同,RAM包的NAPI工程(通過IDE開發NAPI工程)使用的動态庫libhellonapi.so,而ROM包的NAPI工程編譯出來使用的動态庫是libhellonapi.z.so。
libhellonapi.so位于hap包源碼路徑如下
entry\build\default\intermediates\libs\default\arm64-v8a
entry\build\default\intermediates\cmake\default\obj\arm64-v8a
entry\build\default\intermediates\libs\default\armeabi-v7a
entry\build\default\intermediates\cmake\default\obj\armeabi-v7a
- 開發ROM包的NAPI工程需要加入OHOS編譯體系,編寫BULID.gn、ohos.build等,開發過程較為繁瑣。而RAM包的NAPI工程不需要加入OHOS編譯體系,編寫CMakeLists.txt配置編譯需要的源檔案、頭檔案、依賴的庫等。是以開發RAM包的NAPI工程相對簡潔。
-
.d.ts聲明檔案的編寫不同
開發ROM包的NAPI工程時,筆者編寫的@ohos.hellonapi.d.ts内容為
開發RAM包的NAPI工程時,筆者編寫的@ohos.hellonapi.d.ts内容為#打卡不停更#三方庫移植之NAPI開發[3]通過IDE開發NAPI工程 編寫.d.ts聲明檔案時,RAM包開發的NAPI工程定義功能方法#打卡不停更#三方庫移植之NAPI開發[3]通過IDE開發NAPI工程
比ROM包多了getHelloString: () => string
符号。=>
知識點附送
-
以下為開發ROM包的NAPI工程時,需要添加進入sdk的聲明檔案模闆
@ohos.子產品名.d.ts檔案:
/**
* 子產品描述
* @since API版本号,IT Release3 對應 4,以此類推
* @sysCap 系統能力
* @devices 支援裝置
* @import 導入子產品
* @permission 權限清單
*/
declare namespace 子產品名 {
// 在此處定義功能方法
}
export default 子產品名;
附件連結:https://ost.51cto.com/posts/18336
本文作者:離北況歸