Ruff：一次破局 IoT 研发困境的尝试

作者：时间：2018-02-06来源：电子产品世界收藏

作者/郑晔 Ruff公司CTO

本文引用地址：http://www.eepw.com.cn/article/201802/375450.htm

　　*本文源于“嵌入式系统联谊会主题讨论会(总第22次)——物联网操作系统现状与发展前景研讨会”上作者的报告。该会议主办方：嵌入式系统联谊会，时间：2017年11月12日，地点：北京航空航天大学。

　　提及 IoT(物联网，Internet of Things)，几乎整个 IT 行业的共识是未来一定会是一个 IoT 时代，继互联网时代将更多的人连接到一起之后，IoT 时代将会把更多的物(Thing)连接起来。但是，一说到 IoT 的研发，人们的第一反应通常是，物就是硬件，做硬件就要懂嵌入式，所以，IoT 开发就是嵌入式开发。于是，我们看到在 IoT 的指引下，各大硬件厂商和嵌入式操作系统厂商摇旗呐喊，纷纷畅想着 IoT 的未来，而现在的 IoT 行业状态却是，只问脚步声，未见人下来。为什么会这样?我们不妨简要分析一下。

　　1 IoT 研发困境

　　• 产品经理与硬件工程师难以协同

　　在 IoT 时代，做一个硬件，已经不再是做一款独立的硬件，本质上，它就是一个产品，与这个时代的其它产品没有区别。无论是硬件厂商，还是操作系统厂商，他们拥有的都是研发实力，但在产品上却不是强项。而哪里拥有最多的产品经理呢?现在的答案是互联网公司。但为什么互联网的产品经理不来做物联网呢?

　　不是没有，而是很难。

　　曾经有一个互联网产品经理看到了 IoT 的未来，决心投身这个未来，做一款改变世界的硬件产品。根据互联网思维的做事方式，他说，我先要做一个东西先试错，因为我也不确定对这个产品是否是对的。他把这个想法给了硬件工程师，硬件工程师说，我要做六个月。当时这个互联网产品经理就崩溃了，说我从来都有想法大概两周试出来，你告诉我要六个月。双方很努力的协调之后，硬件工程师按照他把初步的想法做出一个东西。临近实现结束，产品经理出来说，我有一个新的想法，这回轮到硬件工程师崩溃了。

　　• 瀑布式研发

　　双方之所以会有如此大的差异，本质上，是因为双方在用不同的工作模式在工作。硬件研发属于瀑布式开发，而互联网产品研发则采用的是敏捷软件开发，双方对于开发节奏的理解截然不同。瀑布式要求一次性做好所有的事情，而敏捷开发则要不断地试错。在20年前，软件行业的主流开发方式也是瀑布式的，但对于这个需要快速响应变化的年代，瀑布式研发显得越加不合时宜了。

　　• 重复造轮子

　　在硬件行业里，有一个典型的现象，在一个项目做好的东西很难用到另外一个项目上，比如，TCP/IP 协议栈，即便你已经烂熟于胸，拿到一款新的硬件，往往要重来一次。对于这种现象，在软件行业里，有一个常用的说法：重复造轮子。这在某种程度上是一种浪费，放在行业的角度，这种浪费现象更加严重，你在一个硬件上做的一个工作，在其它公司，会有另外的工程师做着同样的事情，然而你不知道，没法用。在行业中，如此大规模的浪费导致整个行业进展缓慢。

　　• 系统与应用一体

　　IoT 时代需要的必然产品本质上就是一个应用，但在硬件行业里，大多数人并不能将应用与系统分开，做一款硬件产品，往往需要从硬件到系统，再到上层的应用一起做。这样的做法带来的后果往往是，系统与应用常常混淆在一起，做过开发的人都知道，这也通常意味着代码混杂在一起，维护的难度系数便直线上升。此外，这还有一个隐含的要求，做硬件的人要懂得从系统到应用的各种知识。

　　今时今日，前端工程师已经 IT 行业里一个主流的职位。但你不妨同前端工程师交流一下，看有多少前端工程师知道，屏幕上显示的点到底是怎么显示出来的，总的来说，比例不会高，除非他自己非常有热情的去研究这些东西。而在嵌入式领域，要做一个应用必须知道各种细节，包括底层的寄存器。从某种程度上说，这是对人的要求非常非常高。

　　这种高要求导致嵌入式行业人才培养也极其困难，即便是一个计算机专业的学生，真正理解操作系统，理解硬件底层是怎么运作都是一件有很高难度的事情。我们看到一个很无情的现实是，虽然我们以为嵌入式领域人才已经很多了，但是与做软件的人比起来做嵌入式的人，数量还是太少。

　　2 软硬鸿沟

　　换个角度，作为一个软件的人，如果他真的有热情，要去做硬件，他又会面临什么样的问题。

　　他会看到一大堆的新名词：GPIO、I2C、C、时序、驱动等等，如果你是做硬件的，这些名词或许很熟悉。但我曾经在一些软件技术大会上做过一些调研，尝试用这些名词去问过不同的人，你知不知道这个词什么意思。这些软件工程师普遍的表情就是见了鬼一样。他们根本不知道我在说什么。

　　软件工程师会关心的是什么呢?他们会关心：

　　• 需求是什么

　　• 用户体验是怎样的

　　• 设计模式用什么

　　• 系统怎么架构的

　　• 怎样在高并发中保持系统的健壮

　　我们不难发现，这两套语言几乎就是两个世界的语言，就像中国人说中文，英国人说英文，你没有一个翻译你根本不知道对方在说什么。虽然双方都号称自己从事的软件开发，但谈论的根本不是一回事。这里面存在一个巨大的鸿沟。

　　3 IoT 应用研发，出路何在?

　　我们回过头想想，问题到底出在哪?

　　通过前面的分析，软硬双方，一方是人数不够多，另外一方想进又进不来，所以造成的现状就是，各种硬件厂商在编写各种各样的硬件，所以整个 IoT 的进展速度不会太快。

　　亚当·斯密在《国富论》的开篇提到：劳动生产力上最大的改进，以及劳动时所表现的更多的娴熟程度、技巧和判断力，似乎都是分工的结果。

　　我们不难从前面的讨论中看出，硬件厂商一个人扮演了三个角色：硬件制造、系统研发、应用开发。如果能够把三个角色分开，由不同的厂商扮演不同的角色：应用的人把应用写好，平台的人把平台做好，做硬件的人把硬件做好。事实上，现在行业里已经有人开始做这方面的尝试了，于是，行业里就出现了各种 IoT 平台。

　　接下来，我就以 Ruff 这个 IoT 平台为例，介绍一下一个 IoT 平台背后的设计理念。

　　4 IoT 平台衡量标准

　　在讨论 IoT 平台之前，我们需要知道有哪些衡量标准来判断一个 IoT 平台的优劣。下面是我提出的三个衡量标准

　　• 现代程序设计语言

　　• 面向应用的抽象

　　• 提供生产支持

　　4.1 现代程序设计语言

　　鉴于摩尔定律的存在，在现代软件开发中，开发的效率比代码执行的效率要重要。所以，一个好的 IoT 平台，需要有一门现代的程序设计语言。

　　我们不妨先看看 C/C++ 这个传统的嵌入式开发语言在现代程序设计语言所需特性上的表现，如表1。

　　表1 C/C++在现代程序设计语言所需特性上的表现

　　再来看看 Ruff 选择的 JavaScript 在这些特性上的表现，如表2。

　　表2 Ruff 选择的 JavaScript 在这些特性上的表现

　　通过对比，不难发现，虽然 C/C++ 依然战斗力十足，但作为“现代程序设计语言”，它们显得不那么“现代”了。或许你会好奇，Ruff 为什么选择其它的“现代程序设计语言”，主要有下面几点考量。

　　4.2 面向应用的抽象

　　什么是面向应用的抽象?对比两段代码，我们便不难发现，这两段代码完成是同样的工作，点亮一盏灯。

　　先是传统嵌入式风格，简单起见，我们用了 Python 代码做示例：

　　GPIO.output(11, GPIO.HIGH)

　　再是 Ruff 的代码，用的是 JavaScript 语言

　　$('#led').turnOn();

　　我们为什么需要硬件抽象呢?因为我们看到整个软件开发的趋势就是抽象度越来越高，从汇编到 C 语言，再到Java，今天还会有各种各样的 DSL (Domain Specific Language，领域特定语言)。早年间，编写代码，我们可能会质疑编译器是否正确，手写汇编效率会更高，但今天，我们肯定不会这么做，开发效率太低，因为有了抽象，底层的东西可以不断优化，越做越好。之所以抽象程度能不断提升，还要拜摩尔定律所赐，硬件能力越来越强，一些执行上的性能损失，我们是可以承受的。

　　那我们需要怎样的抽象呢?从发展趋势可以看出，抽象的趋势一定是越来越接近问题领域。对于 IoT 平台而言，一定是越来越接近于应用开发。在 IoT 平台的尝试中，我们看到了几种不同的抽象。

　　• 无抽象

　　传统的嵌入式开发按照这个标准，就是无抽象的，其特点是面向硬件接口编程。

　　GPIO.output(11, GPIO.HIGH)

　　• 编程接口抽象

　　诸如 Ruff、Tessel、Jonny-Five、Cylon.js 等一些 IoT 平台开始提供面向应用的编程接口抽象，让开发者无需关注底层的实现细节。

　　board.on("ready", function() {

　　var led = new five.Led(13);

　　led.strobe();

　　});

　　但在这里，我们不难发现，我们依然要对底层的接口有了解，否则，你便不知道，这段代码中的13是做什么用的。

　　• 隔离硬件配置的抽象

　　Ruff 在提供面向应用的编程接口抽象基础上，更进了一步，将硬件配置隔离出去。在 Ruff 代码中，我们甚至看不出硬件配置是什么样的。

　　$.ready(function (error) {

　　$('#led').turnOn();

　　});

　　Ruff 之所以要提供隔离硬件配置的抽象，主要是为了提供生产支持。

　　4.3 提供生产支持

　　大家对于新出现的 IoT 平台，普遍有一个误解，这些平台只能用在原型研发上，因为它们看到的是，采用 JavaScript 的硬件要求都很高，与现在普遍的硬件开发状况不符。现在 JavaScript 已经可以运行在一些资源有限的系统上，比如 MCU，Ruff 就有自己的 MCU 版本，支持了几款不同的 MCU。

　　Ruff 所做的事情更进了一步，它将硬件配置与应用本身分离开来，这样的做法带来一些好处是

　　• 应用开发者无需关注硬件如何配置，可以将更多的将注意力放在应用逻辑本身

　　• 硬件具体的配置方式可以在具体的部署时决定

　　一旦硬件配置可以在部署时决定，便出现了另外一种可能，也就是，同一个应用可以运行在不同的硬件上，也就是跨硬件应用就出现了，这也就让前面提及的“重复造轮子”的情况得到一定程度的缓解。

　　伴随跨硬件应用的出现，还会有一个额外的作用：测试。以往硬件测试一定要在硬件上完成，因为前面提及的种种原因，硬件测试往往要部署一个包括系统在内的应用，所以，效率是极低的。而我们知道，应用开发中，大量的测试实际上是应用逻辑的测试，属于软件测试的部分，理论上是可以在开发机上完成的。因为有了硬件隔离，Ruff 就提供了在开发机上做软件测试的能力，开发的效率由此得以提升。

　　下面是一个 Ruff 测试代码的例子，可以在开发机上运行：

　　var runner = require('ruff-app-runner');

　　var verify = require('ruff-mock').verify;

　　exports['test should call turn on while application is ready'] = function() {

　　runner.run(appPath, function() {

　　verify($('#led')).turnOn();

　　});

　　};

　　require('test').run(exports);

　　5 结论

　　我们总结一下 Ruff 在 IoT 平台衡量标准上的一些做法，如表3。

　　表3 Ruff 在 IoT 平台衡量标准上的一些做法