Ruff破局IoT 困境的思考

IoT 时代可以说是互联网的下一代，将更多的物和设备连接起来。IoT 时代硬件，已经不再是做一款独立的硬件，IoT 研发已经进入困境，为此Ruff 进行了一次破局 IoT 研发困境的尝试。

提及 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 平台衡量标准上的一些做法

基于这些做法，采用 Ruff 平台的应用开发，将会看到在一些模式上出现的转变，如表4。

表4 采用Ruff 平台的应用开发，在一些模式上的转变

以上就是 Ruff 在破局 IoT 困境上的一些思考和尝试，欢迎读者能够给出自己在这个方面的见解，让我们一起推动 IoT 时代早日到来。