写一个N-API没那么难？

本文基于Nodejs v13.1.0

阅读本篇文章之前，请阅读前置文章：

• nodejs是如何和libuv以及v8一起合作的？(文末有彩蛋哦)

阅读完本篇文章之后，希望你可以掌握以下知识点：

• C++ Addon引入的原理
• NAN写法与NAPI写法的区别
• C++ Addon对算法效率的影响

本文demo地址：传送门

1、NAN和NAPI的历史简介

诚如从暴力到 NAN 再到 NAPI——Node.js 原生模块开发方式变迁一文所提到的NAN和NAPI的历史，NAN为了搞定”封建时代“混乱的C++原生模块，不再让一个模块只能被若干个nodejs版本使用，而提出使用宏定义来解决这个问题，所以说NAN是一大堆宏定义，兼容各种nodejs版本的宏定义。做到了一次编写，到处编译。

而这种设计模式还是依然有缺点，那就是多次编译，也就是说你写的插件如果到了更高的Nodejs版本，还是需要再次编译，让宏定义再次匹配新的版本去编译出新的插件包，于是在node v8版本之后，nodejs提出了新的一套机制，也就是我们这次的主角-NAPI。

不同版本的 Node.js 使用同样的接口，这些接口是稳定地 ABI 化的，即应用二进制接口（Application Binary Interface）。这使得在不同 Node.js 下，只要 ABI 的版本号一致，编译好的 C++ 扩展就可以直接使用，而不需要重新编译。

那么我们怎么查看当前Node版本的ABI版本呢？通过process.versions.modules可以打印出当前的ABI版本，nodejs提供了一份完整的ABI版本列表：

abi_version_registry.json

process.versions提供了Nodejs一些版本相关的提示，包括v8使用的版本，各个依赖包的版本，比如在版本v13.2.0下打印：(注：napi这个字段是NAPI模块版本，它有一个自己的版本矩阵：N-API Version Matrix)

{
  node: '13.2.0',
  v8: '7.9.317.23-node.20',
  uv: '1.33.1',
  zlib: '1.2.11',
  brotli: '1.0.7',
  ares: '1.15.0',
  modules: '79',
  nghttp2: '1.40.0',
  napi: '5',
  llhttp: '1.1.4',
  openssl: '1.1.1d',
  cldr: '35.1',
  icu: '64.2',
  tz: '2019c',
  unicode: '12.1'
}

N-API 定义了如下特性：

• 提供头文件node_api.h；
• 任何 N-API 调用都返回一个napi_status枚举，来表示这次调用成功与否；
• N-API 的返回值由于被napi_status占坑了，所以真实返回值通过形参来传递；
• 所有JavaScript数据类型都被黑盒类型napi_value封装，不再是类似于 v8::Object、v8::Number等类型；
• 如果函数调用不成功，可以通过napi_get_last_error_info函数来获取最后一次出错的信息。

1.1、既然说N-API是基于ABI的，为啥它使用的不是modules字段，而是自定义了napi这个字段？

这个问题是留给大家思考的。有疑问欢迎留言讨论。

2、Nodejs是如何引入执行一个C++插件的？

老规矩，如下图所示：

图中我们还发现有下面这么一个结论：为啥我们直接require JSON文件的时候，可以自动转化为一个对象？

因为模块解析的时候，如果是json后缀的时候，会调用JSON.parse这个方法

Tips:上图还可以作为面试题《请说说在Nodejs中require一个文件后一个简单流程》的一个简单答案

我们重点关注到v8里面的DLOpen方法。

该方法是为了解析node后缀的模块而写，node模块本质是一个动态链接库(windows下后缀是dll，linux下后缀是so)，所以你看v8源码下，如果是支持__POSIX__标准的话，是使用系统APIdlopen()打开即可，如果是非__POSIX__的话，就只能借助libuv的uv_dlopen方法去打开。

其次文件打开之后，执行以下几个判断：

• 判断模块的初始化函数是否符合标准
• 判断是否是普通的C++插件，如果是的话，看看是否当前的nodejs版本ABI版本是否可以支持加载该模块

最后执行模块的初始化函数

这里可以看到N-API的模块是不需要判断的，从这里也印证了这句话：

A given version n of N-API will be available in the major version of Node.js in which it was published, and in all subsequent versions of Node.js, including subsequent major versions.

2.1、使用不同版本编译和执行NAN模块

利用nvm切换nodejs版本，我们先使用node v11.15.0编译，再使用node v13.2.0执行，nodejs会报如下错误：

:16
internal/modules/cjs/loader.js:1190
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: The module '/Users/linxiaowu/Github/nodejs-NAPI-demo/packages/md5-NAN/build/Release/md5-nan.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 67. This version of Node.js requires
NODE_MODULE_VERSION 79. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1190:18)
    at Module.load (internal/modules/cjs/loader.js:976:32)
    at Function.Module._load (internal/modules/cjs/loader.js:884:14)
    at Module.require (internal/modules/cjs/loader.js:1016:19)
    at require (internal/modules/cjs/helpers.js:69:18)
    at Object.<anonymous> (/Users/linxiaowu/Github/nodejs-NAPI-demo/packages/md5-NAN/index.js:1:15)
    at Module._compile (internal/modules/cjs/loader.js:1121:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1160:10)
    at Module.load (internal/modules/cjs/loader.js:976:32)
    at Function.Module._load (internal/modules/cjs/loader.js:884:14)

2.2、使用不同版本编译和执行N-API模块

同样使用上述的步骤，是可以正常执行NAPI模块的。其中v11.15.0的process.versions：

{ node: '11.15.0',
  v8: '7.0.276.38-node.19',
  uv: '1.27.0',
  zlib: '1.2.11',
  brotli: '1.0.7',
  ares: '1.15.0',
  modules: '67',
  nghttp2: '1.37.0',
  napi: '4',
  llhttp: '1.1.1',
  http_parser: '2.8.0',
  openssl: '1.1.1b',
  cldr: '34.0',
  icu: '63.1',
  tz: '2018e',
  unicode: '11.0' }

而v13.2.0的process.versions是：

{
  node: '13.2.0',
  v8: '7.9.317.23-node.20',
  uv: '1.33.1',
  zlib: '1.2.11',
  brotli: '1.0.7',
  ares: '1.15.0',
  modules: '79',
  nghttp2: '1.40.0',
  napi: '5',
  llhttp: '1.1.4',
  openssl: '1.1.1d',
  cldr: '35.1',
  icu: '64.2',
  tz: '2019c',
  unicode: '12.1'
}

由此验证了N-API在兼容性和编译这块做的确实够好。

3、NAN和NAPI写法对比

以demo中的为例子，分别用NAN和N-API实现了一个md5，下图是二者的对比：

我们逐条逐条分析。

Tips：NAN使用第三方包nan，N-API使用第三方包node-addon-api

3.1、头部①

从头部可以看出N-API的头文件更加干净清爽，没有那些v8的语句。因为不需要再像NAN那样使用：

using v8::Local;
using v8::Object;
using v8::String

3.2、实现部分②

实现部分，NAN使用宏定义将实现的函数头部包裹起来，而N-API经过node-addon-api包裹之后，更像一个正常的函数，有函数名、形参、返回值。函数体实现二者差距不是很大，除了返回值：

NAN：

info.GetReturnValue().Set(New(md5str).ToLocalChecked());

非常的v8!

而N-API:

return String::New(env, md5str,32);

非常的正常！

3.3、初始化函数③

二者的区别一看就看出差距：

NAN：

Nan::HandleScope scope;
Nan::SetMethod(exports, "md5", md5);

N-API：

exports.Set("md5", Function::New(env, GetMD5));
return exports;

3.4、模块定义④

NAN模块的初始化是交给 Node.js 提供的宏来实现的：

NODE_MODULE(addon, init)

而N-API使用自己的宏定义(NAPI_MODULE)，因为我们使用node-addon-api，所以它也对这个宏定义包裹成下面这个了：

NODE_API_MODULE(addon, Init)

4、NAPI可以提高算法效率吗？

我们来看看使用N-API对排序算法的一个效率提升，示例中使用了两种排序算法：冒泡排序和快速排序：

代码参考：sort.cc

比如以快速排序为例子，快速排序的算法时间复杂度是NlogN，C语言版本的快排：

void quickSort(unsigned int *array, unsigned int length)
{
  unsigned int partition;
  unsigned int i, j;
  unsigned int rightLength, leftLength;
  unsigned int *rightArray, *leftArray;

  if (length < 2)
  {
    return;
  }
  partition = *(array);
  i = 1;

  for (j = 1; j <= length; j++)
  {
    if (*(array + j) < partition)
    {
      swap(array + i, array + j);
      i++;
    }
  }
  swap(array, array + i - 1);

  leftLength = i - 1;
  leftArray = array;
  rightArray = array + i;
  rightLength = length - i;

  quickSort(rightArray, rightLength);
  quickSort(leftArray, leftLength);
}

当我们改变demo中test/index.js中数组的长度，得到的js版本排序时间和N-API的排序时间(单位ms)如下图：

从图中可以看到，在快速排序算法中，随着数组长度的增加，js版本的排序时间甚至还优于N-API的排序时间，可以说二者不相上下，而在冒泡排序中，N-API的排序时间一直是优于js版本的排序时间，得出两个结论：

• 选择算法的重要性！
• v8对代码优化已经做得很好了！

参考

1. 从暴力到 NAN 再到 NAPI——Node.js 原生模块开发方式变迁
2. ABI Stability
3. Shared library handling
4. process.versions.modules is not for N-API ?