JavaScript 如何应用在 IoT？

在日前的 GMTC 全球大前端技术大会上，Rokid 基础平台研发中心的研发工程师刘亚中发表了《JavaScript in IoT》的演讲，本文整理内容如下。

什么是 IoT

如字面翻译，即物联网，但真正要解释起来，其实就是两点：

• 
  

• IoT 是面向服务的 UI。

• 
  

• 
  

• IoT 面临资源受限的问题。

• 
  

在物联网时代，我们不再像从前那样独立地使用某个固定、单一的产品，而是在享受着整个环境或者是网络给我们提供的服务，比如原来我们买一个闹钟回来，闹钟就是闹钟，在 IoT 环境下，闹钟是其中的一环，当它叫醒你后，整个系统会为你准备起床后需要的所有待办事物，这就是物联网。

接下来我们来看看资源受限的问题：

最右侧的手机自不必说，整个生态已经相当成熟了。最左侧的是目前的低端配置，可以看到内存和可用空间都是 MB 为单位的，CPU 也相当受限，因此这种设备上 Linux 也已经不满足运行的最低需求了，所以一般是采用更轻量级的 RTOS，流行的有 FreeRTOS 和 RT-Thread（国内）。

最中间的是以 Linux 为主的 128+128 组合的设备，最为我们所熟知的就是智能音箱（无屏），对于这类设备来说包括 Alexa、Rokid、小爱同学等，现在大多数厂商在设备端的开发语言也都以 C + Lua 为主，目前也仅有 Rokid 支持 JavaScript 直接运行在设备端，而本文也主要是针对智能音箱这一挡设备来展开。

然后我们来看下，为什么在 128 MB 的设备上运行 JavaScript 也如此困难呢？

上图是 Rokid 智能音箱上各个子模块的内存占用情况：

• 
  

• kernel 内核占用，用于保证 Linux 用户态程序能正常运行。

• 
  

• 
  

• dsp 包括从麦克风读出语音数据，然后进行算法处理，最终获取是否语音激活。

• 
  

• 
  

• system 包括一些底层系统功能，如 IPC 服务、多媒体服务、存储服务等。

• 
  

• 
  

• applications 即上层应用的逻辑。

• 
  

通过上图的比例最终可以看出，JavaScript 真正能用的内存只有 25MB，这对于目前一个 Node.js 进程来说也就刚刚好而已，这也是目前大多数音箱，仅在服务器上提供 JavaScript SDK 的原因。

Why JavaScript？

为什么我们要在 IoT 使用 JavaScript 呢？这里简单给出几个理由。首先 Web 已经是一个相当成熟的社区了，它聚集了大量的开发者，这对于任何一个开放平台来说，都是一个非常有吸引力的开发者来源。

另外得益于 JavaScript 或者说 Web 这种即时更新的机制，在解决设备碎片化问题上，有着天然的优势，因此对于 IoT 的碎片化问题，我们希望借助于 Web 来解决。

另外，Web 标准组织已经提出了 WOT —— Web of Things 的概念，因此对于我们来说，要做的就是跟标准组织一起推进 WOT 的落地，这也是一个非常顺理成章的事情。

如果你想参与更多前端技术交流，获取更多专家分享，可以加入我们的“前端技术交流群“，社群内会经常讨论前端相关的技术、分享免费学习资料，我们也会邀请前端专家进行社群分享、直播、公开课等活动。如果你感兴趣，欢迎添加社群管理员微信 GeekUni004，回复“前端群”申请入群。

ShadowNode —— Node.js on IoT

ShadowNode 截止目前为主，已经支持如下特性：

1. 
   

2. 支持 macOS 与 Linux 的编译和运行。

3. 
   

4. 
   

5. 支持 x86、arm 与 aarch64。

6. 
   

7. 
   

8. 支持大部分核心的 Node.js API，如：assert / buffer / N-API Add-ons / child process / crypto / dns / events / file system / http / https / module / net / os / process / timers / TLS / UDP

9. 
   

10. 
    

11. 支持了 WebSocket / MQTT 等流行的 IoT 库

12. 
    

13. 
    

14. 支持 CPU 和 Heap 的 Profiler

15. 
    

16. 
    

17. 支持 N-API

18. 
    

接下来，关于 ShadowNode 的历史大家可以去看之前的专栏文章：

• 
  

• ShadowNode v0.8.0 发布
  

• 
  

• 
  

• ShadowNode v0.9.0 发布
  

• 
  

• 
  

• ShadowNode v0.10.0 发布
  

• 
  

简单来说呢，ShadowNode 就是为了能让 JavaScript 能愉快地跑在 IoT 设备上而存在的，下面是 ShadowNode 与 Node.js 的一些资源占用上的对比：

可以看出无论是 macOS 上，还是 ARM 上，ShadowNode 在内存占用上有明显地提升，还记得我们之前看到智能音箱上各子模块的内存分布吗？对于应用来说可用内存有 25MB，如果使用 ShadowNode 作为运行时的话，基本上就达到了可以随意新增本地应用的状态了。

然后是启动时间，对于设备端上的应用来说，往往为了省内存，会把不重要，或不再使用的应用（进程）杀掉，当有需要时，再重新启动，因此这对进程的启动时间，包括 CPU 占用都提出了不小的要求，可以看出 ShadowNode 在这方面的表现也优于 Node.js。

N-API on ShadowNode

N-API 作为 Node.js Add-on 的 ABI 兼容的接口，可以让任何程序在不需要重新编译的情况下无缝运行在 node-chakracore 与 node-v8 上，ShadowNode 同样如此，我们按照 N-API 的标准文档和测试集，实现了在 ShadowNode 上的 N-API，这样在不需要重新编译的情况下，也能在 Node.js 和 ShadowNode 跨运行时运行，这使得我们可以根据不同的设备配置，选择合适的运行时，而上层的代码则不需要任何修改。

ShadowNode 的 N-API 完全是基于 Node.js 仓库下的 N-API 测试用例测试的，除了一些我们还不支持的特性外，其余的测试用例都会在 ShadowNode CI 上做验证，所以对于稳定性方面大可放心使用。

性能

我们在 IoT 下，针对一些特定场景，也做了一些性能优化。

比如需要使用一些第三方仓库时，仓库本身太过臃肿，导致在设备上加载起来就已经很花时间了（ShadowNode 没有 JIT），甚至于大多数情况是加载不进来的，因为这些库会在堆里创建大量的对象，而 ShadowNode 有预置的 heap_maximum_size，这样难道就没有其他办法了吗？

后面我们想到了一个办法，那就是保持兼容这些第三方库的 JS API，底层全部用 C/C++ 重写，这样可以减少大量的对象创建，同时也能让开发者使用时没有任何差异，我们使用这种方式分别完成了 WebSocket 和 MQTT 在 ShadowNode 上的移植。

另外一个优化手段是引入 NODE_PRIORITIZED_PATH，大家肯定对 NODE_PATH 不陌生吧，那 NODE_PRIORITIZED_PATH 理解起来也不困难，就是一个最高优先级的 NODE_PATH。因为在 IoT 设备上的情况与服务端往往不同，Node.js 模块都是放在每个项目中的，然而在 IoT 设备上的每个应用都比较轻，因此大部分依赖库都是放在全局的 node_modules，这样就导致每次 require 时，总会从模块的当前路径去搜索，这样造成了大量的浪费。

因此我们引入了 NODE_PRIORITIZED_PATH 来设置为全局路径，这样帮我们节省了 30%的启动时间。

接下来是 Copy-on-Write 技术（以下简称 COW），它是 Linux 针对 fork 函数的优化方法，可以节省进程启动时间与内存。这里首先要科普一个知识，即 child_process.fork 并不是真正的 fork，他依然要让子进程从零开始执行，并且抛弃掉父进程的所有资源。

我们来看一下下面的代码：

function uv_spawn (file, args) {  var pid = fork()  if (pid === 0) {    execvp(file, args) *// this disables COW*    *// starting VM and load script*  }}uv_spawn(‘test.js’, [])

在 Node.js 中，无论是 spawn、exec 还是 fork，都调用了同一个 uv_spawn 函数，以上是该函数的伪代码（JavaScript 版本）。可以看到每次 fork 完，都会在子进程调用 execvp 来重新初始化子进程，一旦使用了 execvp 这个函数，就意外着系统将把 COW 禁用了，我们再来看看不调用 execvp 的情况下，如何写代码：

var fork = require(‘linux-sys’).fork
*// load common modules for children*var player = require(‘player’)var http = require(‘http’)var foobar = require(‘foobar’)
*// start forking*var pid = fork()if (pid == 0) {  *// here is the child process*  *// use player / http / foobar*}

上面的代码不再是伪代码了，我们通过将系统的 fork 使用 N-API 暴露给 JavaScript 层，然后从 fork 开始到子进程真正能使用 player、http 和 foobar 模块，仅花了 4ms。

当然，上面的示例代码只是为了证明 COW 拥有卓越的性能提升，因此我们后来就创建了一个新项目 —— Hive。

yodaos-project/hive：https://link.zhihu.com/?target=https%3A//github.com/yodaos-project/hive)

github.com：https://link.zhihu.com/?target=https%3A//github.com/yodaos-project/hive)

Hive 是一个独立于 ShadowNode 的子项目，可以运行在 Node.js 与 ShadowNode 上，因此我们基于 Node.js，对 hive-fork、nodejs-fork、nodejs-spawn 做了一组对比测试：

我们得出的结论显而易见，Hive 在启动速度上几乎是完胜 child_process，这对于设备端的应用启动加速具有很大的意义。

同时在 FaaS 时代，我相信 Hive 也能占有一席之地，FaaS 典型的场景就是快速启动一个进程来执行，然后退出，使用 Hive 可以轻松地定义脚本中的 API，定义好之后，便不需要担心进程启动后所带来的加载消耗，因为几乎是 0 成本的。

YodaOS 从诞生的第一个版本，到现在已经快 1 年时间了。接下来小小预告一下，下半年我们准备发布第二个大版本，即 YodaOS 8.0。在这个版本中，YodaOS 与 Rokid 开放平台完成了解耦，本地的应用也采用了大家熟悉的 Web 应用（不完全兼容）。届时，开发者可以使用 YodaOS 来接入 Alexa、天猫精灵或者 Google Assistant。

总结

很开心能够参加 GMTC 这样的活动，不管是作为讲师还是听众，都收获颇多，我相信 JavaScript 一定会在 IoT 时代释放更多开发者的能量。

嘉宾介绍

刘亚中，开源爱好者，Node.js Collaborator、ShadowNode 作者，目前主攻：Node.js 在 AIoT 领域的应用, 并负责 YodaOS 的社区推广工作。五年 JavaScript 开发经验，曾就职于：SeedMail、Pixbi、阿里巴巴，目前就职于 Rokid 基础平台研发中心，主要工作方向为基于 JavaScript 的物联网操作系统。近年来参与并负责 YodaOS 项目，将 IoT 和 AI 能力开放给 Node.js 社区，并实现了 Node.js 在 IoT 场景的产品级落地。同时也是 Node.js Collaborator、ShadowNode 和 TensorFlow-Node.js 作者，开源发烧友，目前给 60 个开源项目贡献过代码。