写一个N-API没那么难?

5,963 阅读7分钟

本文基于Nodejs v13.1.0

阅读本篇文章之前,请阅读前置文章:

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

  • 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::Objectv8::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 ?