原理：

napi概念来源于Node.js，openharmony沿用了napi的原理，根据自己的js引擎，重写了类napi接口，并保留了napi的语法。其用于在系统层创建js对象，或从js运行环境中获取js对象或方法。

通过napi，系统层可以向应用层提供napi接口，暴露系统层的函数方法。

在openharmony应用层，调用流程为:引擎将ets编译成js语言，通过import导入的napi库，被编译成requirNapi() ——>创建引擎实例，构造方法调用requirNapi()方法，其中调用modelManager.LoadNativeModel()方法，通过napi 库名，加载调用对应napi库——>执行对应napi库的构造函数，调用napi_module_register()方法，将napi 模块注册到js引擎 ——>执行module中.nm_register_func属性定义的初始化函数，该函数中通过napi_property_descriptor()方法定义了js端调用napi接口函数名和实际c++端函数名的映射关系，并通过napi_define_properties()方法批量定义该模块的属性以及属性值(c++方法)  ——>在js端调用napi模块具体的方法时，js引擎就会通过模块属性名，根据已经模块初始化时已经定义好的映射关系，去调用对应的属性值(c++方法)。

编写：

主要包括三部分内容:

模块注册和声明文件

模块接口实现文件

以及模块接口声明文件

其在文件结构中体现为：

napi_module.cpp模块注册

file_operate_napi.cpp模块接口实现

@ohos.filemanagement.file_operate.d.ts模块声明文件

sa的napi接口，在BUILD.gn文件中，需要指定编译生成li.z.so文件的相对路径为mudule

因为js引擎的LoadNativeModule()默认的加载napi.z.so文件的路径就是system/lib/module。如果不指定该参数，生成的napi.z.so文件会在system/lib路径下，导致LoadNativeModule()执行失败，即对应为js中的import那一步失败了。