专访 Yorkie：JavaScript 如何开发 IoT 应用？

随着 5G 的到来，各大公司都纷纷加大了在物联网和边缘计算方面的投入，一些先驱者试图将 JavaScript 引入 IoT 开发，打通物联网与庞大的前端开发者生态，ShadowNode 就是其中的一位。在 6 月 20 日举办的 GMTC 全球大前端技术大会中，ShadowNode 作者 Yorkie 将分享《JavaScript in IoT》的话题，借此机会我们对他进行了采访，了解 JavaScript 在 IoT 领域开发的一些问题。

InfoQ：能否和我们讲讲，现在 IoT 开发领域有哪些具体的场景和产品？

Yorkie：场景可以分为使用场景和开发场景，首先是针对用户使用场景，IoT 可以划分为 2 个主要分类：一种是对单个家庭设备的控制，诸如控制空调、打开开关、打开电灯等。还有一种一般叫智能场景，就是通过一些简单的操作来配置某个事件发生时的一系列控制指令。举个简单例子，每天用户起床，自动打开窗帘、打开卫生间的灯光、自动播放当日早间新闻等。

除了以上两种外，其实还有一些非常定制化的场景，比如当播放家庭影院时，家里的智能电灯可以根据电影的情节，调节不同的灯光颜色来烘托电影气氛。

对于开发场景来说，IoT 设备在我看来，主要分为：

• 以 1GB 内存为主的 Android 设备，主要是一些带屏的智能设备，如我们常用的手机，电子相册等，开发环境以 Android 为主。

• 以 128MB 内存为主的 Linux 设备，主要是作为家庭网关、智能音箱等，开发环境以 C/C++ 为主。

• 以 512KB 内存为主的 RTOS 设备，主要代表为智能电灯、智能手环、智能空调等，开发环境以 C 为主。

目前的现状是这样。

InfoQ：请您介绍一下 ShadowNode，以及为什么要做这个项目？

Yorkie：简单的说，ShadowNode 被我定义为设备端的 Node.js 运行时，并支持 N-API。物联网按照资源富有程度，分为 3 个等级，对于 1GB 以上的设备，社区版的 Node.js 是完全可以胜任的，而 ShadowNode 则是为了解决开发者在 128MB 设备下，运行 Node.js 的使用问题，它可以做到裸运行时只有 1MB 占用。

提到 ShadowNode，就不得不提到 IoT.js，其实 ShadowNode 是 fork 自 IoT.js，而且当我发现它的时候，就已经具备了大部分 Node.js 的功能了，包括 net, stream, dns, udp, fs, http 等重要模块，ShadowNode 在其基础上增加了 child_process, tls, mqtt, websocket 等，并且增加了 N-API 的支持和兼容了部分 NPM 包生态。

做 ShadowNode 的原因也很简单，就是想补齐 Node.js 在物联网的部分，让 JS 开发者从云端开发再次回到用户端，并希望 JS 生态和 IoT 生态能融合得更加紧密。我非常希望能把社区和 IoT 行业联系在一起，而不是让它停留在给开发者玩玩的状态，因此才会在树莓派这类开发板配置越来越好的大环境下，仍然选择去做更低成本配置的适配，也正因如此，才会有 ShadowNode 的诞生。

InfoQ：对不了解 IoT 的人来说，Node.js 和 JavaScript 的性能似乎不够好，为什么能用在嵌入式平台上面呢？

Yorkie：严格来说，现在我们仍然没有完成在真正的嵌入式平台上运行 Node.js，不过我可以分享下在设备成本一降再降时，如何优化性能与内存的。

首先是内存上的优化，主要包括常用 ByteCode 的 Compact 模式，Compressed Pointer（压缩指针），选择性地支持了 ECMA 标准等。

接下来是性能优化，由于 ShadowNode 是集成在我们自己的操作系统（YodaOS）上的，所以一些基础 Node.js 包是放在全局路径（/usr/lib/node_modules），按照 Node.js Modules 的搜索算法，它是一个就近原则的算法，这样导致了在加载系统模块时，会消耗大量时间在搜索路径，于是我们就引入了一个新的环境变量 NODE_PRIORITIZED_PATH，顾名思义，设置后会优先搜索该路径下的模块。

还有一个我们在 ShadowNode 中比较常用的优化手段是，当我们遇到一个第三方库要用时，但同时这个库体积很大，依赖多，这时我们通常会用 C 语言把底层重写，然后做一层很薄的 JS API，让它与社区库保持一致，内置的 MQTT / WebSocket 都是按这个套路来完成的，效果都很显著。

总结一下，在资源受限的情况下，我们往往做优化时，都是在内存与性能之间做权衡，实在无法权衡的情况，就选择减少 JavaScript 的对象，往往都能凑效。所以我们在开发 ShadowNode 时，选择了一种与 Node.js 完全不同的方式，我们只让 JavaScript 承担系统浇水的角色，大量的逻辑使用 C 来完成，越少的 JS 代码就代表越好的性能以及越低的内存占用，最后只要保证 API 一致就行了。

InfoQ：用 JS 编写一个驱动智能音箱的 IoT 应用，大概流程是什么样的？

Yorkie：其实跟我们在桌面写程序并没有什么不同，只是智能音箱多了一个事件，去告诉开发者“用户说了什么话，以及什么意图”，然后就是处理算法传过来的 JSON，再按照你想做的去控制 IoT 设备就行。控制的话，也都是通过 http 或 websocket 等就能完成。

如果你想移植一些 C/C++ 库的话，也很方便，只需要按照 N-API 在 PC 上调通，然后再放到对应的交叉编译框架下完成编译即可。

InfoQ：目前 JS in IoT 有哪些痛点？

Yorkie：目前的痛点主要还有 3 点，也可以说是 ShadowNode 需要持续做好的：

• 语法的支持，虽然现在 ShadowNode 支持了箭头函数、Class、Symbol 等，但仍然不支持 const/let、generator 和 async/await 等，这可能对于习惯了 Node.js 新特性的开发者来说，会是一段相对痛苦的经历。

• 调试方式相对简陋，ShadowNode 并不支持 Inspector 和大部分 Chrome DevTools 的功能，仅支持了 Heap Profiler。

• 生态的缺乏，虽然我们支持运行 NPM 格式的包，不过不幸的是，很少有包能在 ShadowNode 上运行起来，最主要的原因就是大部分的包都有大量的依赖。

除此之外，还有就是对于 RTOS 上，完整地使用 ShadowNode（Node.js）还是非常困难，仍然需要做大量的优化以及移植的工作。

InfoQ：您认为 IoT 开发的前景如何，有哪些发展趋势？

Yorkie：其实这里我们一直缺少提到一个我们再熟悉不过的词，就是——Web，印象中的 Web 好像不是基于浏览器，就是在 WebView 上开发，不过在我现在看来，Web 对我们来说，早就脱离了浏览器（甚至是 GUI）的范畴了，它代表了一系列的标准。

因此我坚持认为 Web 仍然会在 IoT 时代大放异彩，Web 中的一些冷门的 API 也会慢慢进入开发者的视野，如 VoiceXML、SpeechSynthesis、Bluetooth 等。而且现在 Node.js 与 Deno 都在积极拥抱 Web API，所以对于前端开发者，或者 Node.js 开发者来说，保持关注标准，或者通过参与 Node.js, Deno 或者 ShadowNode 来加入实现标准的行列中来。

嘉宾简介：

Yorkie，Rokid 研发工程师，开源爱好者，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 个开源项目贡献过代码。