天天看點

#打卡不停更#三方庫移植之NAPI開發[3]通過IDE開發NAPI工程

  • 在三方庫移植之NAPI開發[1]—Hello OpenHarmony NAPI一文中,筆者開發的是一個

    rom

    包的napi工程。該工程需要編譯燒錄固件,C ++的動态庫會內建到開發闆的ROM中。
  • 在本篇文章中,筆者使用三方庫移植之NAPI開發[1]—Hello OpenHarmony NAPI中一樣的hellonapi.cpp和index.ets源碼,通過IDE開發一個

    RAM

    包的NAPI工程(內建C ++的動态庫到開發闆的RAM中),直接編譯安裝hap包到開發闆即可。兩個開發方式的hap包運作效果一緻。

往期回顧:

三方庫移植之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)
           
  • NATIVERENDER_ROOT_PATH

    路徑指的是sdk\native\3.2.7.5\sysroot\usr
  • add_library(hellonapi SHARED hellonapi.cpp)

    表示編譯libhellonapi.so需要的是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聲明檔案編寫

#打卡不停更#三方庫移植之NAPI開發[3]通過IDE開發NAPI工程

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内容為

    #打卡不停更#三方庫移植之NAPI開發[3]通過IDE開發NAPI工程
    開發RAM包的NAPI工程時,筆者編寫的@ohos.hellonapi.d.ts内容為
    #打卡不停更#三方庫移植之NAPI開發[3]通過IDE開發NAPI工程
    編寫.d.ts聲明檔案時,RAM包開發的NAPI工程定義功能方法

    getHelloString: () => string

    比ROM包多了

    =>

    符号。

知識點附送

  • 以下為開發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

本文作者:離北況歸

繼續閱讀