- 在三方库移植之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包运行效果一致。
开发环境：
- 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库需要的头文件和源文件、动态库名称、依赖的库，内容如下：
cmake_minimum_required(VERSION 3.4.1)
project(MyApplication3)
set(NATIVERENDER_ROOT_PATH ${CMAKE_CURRENT_SOURCE_DIR})
include_directories(${NATIVERENDER_ROOT_PATH}
${NATIVERENDER_ROOT_PATH}/include)
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声明文件编写
index.d.ts内容如下：
export const getHelloString: () => string;
界面设计
index.ets和 三方库移植之NAPI开发 1 一文中一致。
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内容为：
编写.d.ts声明文件时，RAM包开发的NAPI工程定义功能方法getHelloString: () => string比ROM包多了=>符号。
为了能让大家更好的学习鸿蒙（HarmonyOS NEXT）开发技术，这边特意整理了《鸿蒙开发学习手册》（共计890页），希望对大家有所帮助：https://qr21.cn/FV7h05
《鸿蒙开发学习手册》：
如何快速入门：https://qr21.cn/FV7h05
- 基本概念
- 构建第一个ArkTS应用
- ……
开发基础知识：https://qr21.cn/FV7h05
- 应用基础知识
- 配置文件
- 应用数据管理
- 应用安全管理
- 应用隐私保护
- 三方应用调用管控机制
- 资源分类与访问
- 学习ArkTS语言
- ……
基于ArkTS 开发：https://qr21.cn/FV7h05
- Ability开发
- UI开发
- 公共事件与通知
- 窗口管理
- 媒体
- 安全
- 网络与链接
- 电话服务
- 数据管理
- 后台任务(Background Task)管理
- 设备管理
- 设备使用信息统计
- DFX
- 国际化开发
- 折叠屏系列
- ……
鸿蒙开发面试真题（含参考答案）：https://qr18.cn/F781PH
鸿蒙开发面试大盘集篇（共计319页）：https://qr18.cn/F781PH
1.项目开发必备面试题
2.性能优化方向
3.架构方向
4.鸿蒙开发系统底层方向
5.鸿蒙音视频开发方向
6.鸿蒙车载开发方向
7.鸿蒙南向开发方向文章来源：https://www.toymoban.com/news/detail-852762.html
文章来源地址https://www.toymoban.com/news/detail-852762.html
到了这里，关于三方库移植之NAPI开发（三）通过IDE开发NAPI工程的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
