专访 Yorkie:JavaScript 如何开发 IoT 应用?

阅读数:15 2019 年 5 月 16 日

随着 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 个开源项目贡献过代码。

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论