NodeJS 中使用native module - 不同方式介绍

写NodeJS 程序的时候，往往不会全是JS的，不管是什么原因需要利用原来的DLL去实现一些特定的业务，那么NodeJS怎么去实现对DLL的调用呢？

NodeJS对模块的调用都是通过require("module")来实现的，那么我们就需要编写一个binary可以通过require("")加载的。要想编译成.node文件，那就必须说node-gyp tool了。

node-gyp 是基于 GYP[^4] 的。它会识别包或者项目中的 binding.gyp[^5] 文件，然后根据该配置文件生成各系统下能进行编译的项目，如 Windows 下生成 Visual Studio 项目文件（*.sln 等），Unix 下生成 Makefile。在生成这些项目文件之后，node-gyp 还能调用各系统的编译工具（如 GCC）来将项目进行编译，得到最后的动态链接库 *.node 文件。具体使用可以参考官网以及Git

方法一：C++ AddOn

你可以参考NodeJS的官方说明，按照说明，如果按照这种方法开发出的AddOn只能支持特定版本，主要是由于V8引擎的各个版本的接口是变化的，甚至有的时候函数参数类型都会在个版本之间不同，所以该方法不建议使用。

方法二: NAN方式，也称为NAPI

在NodeJS的官方网站上没有该方面的说明，但是可以从Git上查看使用原理，NAN 是 Node.js 原生模块抽象接口可能还是有点抽象，那么讲明白点，它就是一堆宏判断。比如声明一个函数的时候，只需要通过下面的一个宏就可以了

NAN_METHOD(Echo)
{
}

NAN 的宏会判断当前编译时候的 Node.js 版本，根据不同版本的 Node.js 来展开不同的结果。那也就是在下载安装该AddOn的时候该AddOn会自动根据当前Node版本重新编译，从而达到不同版本的Node都可以使用该扩展。有个具体例子可以参考

方法三 N-API，该接口符合ABI(Application binary interface),也就是应用程序二进制接口标准，是Node团队维护的，也就是可以解决前面两种方式遇到的夸Node大版本的问题。完全独立于javascript 引擎(chrominum的V8)。

N-API跟NAPI（NAN方式）的区别是它把 Node.js 的所有底层数据结构全部黑盒化，抽象成 N-API 当中的接口。

不同版本的 Node.js 使用同样的接口，这些接口是稳定地 ABI 化的，即应用二进制接口（Application Binary Interface）。这使得在不同 Node.js 下，只要 ABI 的版本号一致，编译好的 C++ 扩展就可以直接使用，而不需要重新编译。事实上，在支持 N-API 接口的 Node.js 中，的确就指定了当前 Node.js 所使用的 ABI 版本。

总结经验：

1. 本人在使用前两种的时候都发现了同样的问题就是最后运行的NodeJS版本跟编译的版本不一致的问题，这会导致程序不能运行，也会提示编译版本和使用版本不一致。

2. 利用NAPI也就是NAN方式的时候，作为扩展的开发人员，在发布的时候要添加安装时自动编译的script("install": "node-gyp rebuild",)