Ruff：一次破局 IoT 研發(fā)困境的嘗試

作者/鄭曄 Ruff公司CTO

　　*本文源于“嵌入式系統(tǒng)聯(lián)誼會(huì)主題討論會(huì)(總第22次)——物聯(lián)網(wǎng)操作系統(tǒng)現(xiàn)狀與發(fā)展前景研討會(huì)”上作者的報(bào)告。該會(huì)議主辦方：嵌入式系統(tǒng)聯(lián)誼會(huì)，時(shí)間：2017年11月12日，地點(diǎn)：北京航空航天大學(xué)。

　　提及 IoT(物聯(lián)網(wǎng)，Internet of Things)，幾乎整個(gè) IT 行業(yè)的共識(shí)是未來一定會(huì)是一個(gè) IoT 時(shí)代，繼互聯(lián)網(wǎng)時(shí)代將更多的人連接到一起之后，IoT 時(shí)代將會(huì)把更多的物(Thing)連接起來。但是，一說到 IoT 的研發(fā)，人們的第一反應(yīng)通常是，物就是硬件，做硬件就要懂嵌入式，所以，IoT 開發(fā)就是嵌入式開發(fā)。于是，我們看到在 IoT 的指引下，各大硬件廠商和嵌入式操作系統(tǒng)廠商搖旗吶喊，紛紛暢想著 IoT 的未來，而現(xiàn)在的 IoT 行業(yè)狀態(tài)卻是，只問腳步聲，未見人下來。為什么會(huì)這樣?我們不妨簡(jiǎn)要分析一下。

　　1 IoT 研發(fā)困境

　　? 產(chǎn)品經(jīng)理與硬件工程師難以協(xié)同

　　在 IoT 時(shí)代，做一個(gè)硬件，已經(jīng)不再是做一款獨(dú)立的硬件，本質(zhì)上，它就是一個(gè)產(chǎn)品，與這個(gè)時(shí)代的其它產(chǎn)品沒有區(qū)別。無論是硬件廠商，還是操作系統(tǒng)廠商，他們擁有的都是研發(fā)實(shí)力，但在產(chǎn)品上卻不是強(qiáng)項(xiàng)。而哪里擁有最多的產(chǎn)品經(jīng)理呢?現(xiàn)在的答案是互聯(lián)網(wǎng)公司。但為什么互聯(lián)網(wǎng)的產(chǎn)品經(jīng)理不來做物聯(lián)網(wǎng)呢?

　　不是沒有，而是很難。

　　曾經(jīng)有一個(gè)互聯(lián)網(wǎng)產(chǎn)品經(jīng)理看到了 IoT 的未來，決心投身這個(gè)未來，做一款改變世界的硬件產(chǎn)品。根據(jù)互聯(lián)網(wǎng)思維的做事方式，他說，我先要做一個(gè)東西先試錯(cuò)，因?yàn)槲乙膊淮_定對(duì)這個(gè)產(chǎn)品是否是對(duì)的。他把這個(gè)想法給了硬件工程師，硬件工程師說，我要做六個(gè)月。當(dāng)時(shí)這個(gè)互聯(lián)網(wǎng)產(chǎn)品經(jīng)理就崩潰了，說我從來都有想法大概兩周試出來，你告訴我要六個(gè)月。雙方很努力的協(xié)調(diào)之后，硬件工程師按照他把初步的想法做出一個(gè)東西。臨近實(shí)現(xiàn)結(jié)束，產(chǎn)品經(jīng)理出來說，我有一個(gè)新的想法，這回輪到硬件工程師崩潰了。

　　? 瀑布式研發(fā)

　　雙方之所以會(huì)有如此大的差異，本質(zhì)上，是因?yàn)殡p方在用不同的工作模式在工作。硬件研發(fā)屬于瀑布式開發(fā)，而互聯(lián)網(wǎng)產(chǎn)品研發(fā)則采用的是敏捷軟件開發(fā)，雙方對(duì)于開發(fā)節(jié)奏的理解截然不同。瀑布式要求一次性做好所有的事情，而敏捷開發(fā)則要不斷地試錯(cuò)。在20年前，軟件行業(yè)的主流開發(fā)方式也是瀑布式的，但對(duì)于這個(gè)需要快速響應(yīng)變化的年代，瀑布式研發(fā)顯得越加不合時(shí)宜了。

　　? 重復(fù)造輪子

　　在硬件行業(yè)里，有一個(gè)典型的現(xiàn)象，在一個(gè)項(xiàng)目做好的東西很難用到另外一個(gè)項(xiàng)目上，比如，TCP/IP 協(xié)議棧，即便你已經(jīng)爛熟于胸，拿到一款新的硬件，往往要重來一次。對(duì)于這種現(xiàn)象，在軟件行業(yè)里，有一個(gè)常用的說法：重復(fù)造輪子。這在某種程度上是一種浪費(fèi)，放在行業(yè)的角度，這種浪費(fèi)現(xiàn)象更加嚴(yán)重，你在一個(gè)硬件上做的一個(gè)工作，在其它公司，會(huì)有另外的工程師做著同樣的事情，然而你不知道，沒法用。在行業(yè)中，如此大規(guī)模的浪費(fèi)導(dǎo)致整個(gè)行業(yè)進(jìn)展緩慢。

　　? 系統(tǒng)與應(yīng)用一體

　　IoT 時(shí)代需要的必然產(chǎn)品本質(zhì)上就是一個(gè)應(yīng)用，但在硬件行業(yè)里，大多數(shù)人并不能將應(yīng)用與系統(tǒng)分開，做一款硬件產(chǎn)品，往往需要從硬件到系統(tǒng)，再到上層的應(yīng)用一起做。這樣的做法帶來的后果往往是，系統(tǒng)與應(yīng)用常常混淆在一起，做過開發(fā)的人都知道，這也通常意味著代碼混雜在一起，維護(hù)的難度系數(shù)便直線上升。此外，這還有一個(gè)隱含的要求，做硬件的人要懂得從系統(tǒng)到應(yīng)用的各種知識(shí)。

　　今時(shí)今日，前端工程師已經(jīng) IT 行業(yè)里一個(gè)主流的職位。但你不妨同前端工程師交流一下，看有多少前端工程師知道，屏幕上顯示的點(diǎn)到底是怎么顯示出來的，總的來說，比例不會(huì)高，除非他自己非常有熱情的去研究這些東西。而在嵌入式領(lǐng)域，要做一個(gè)應(yīng)用必須知道各種細(xì)節(jié)，包括底層的寄存器。從某種程度上說，這是對(duì)人的要求非常非常高。

　　這種高要求導(dǎo)致嵌入式行業(yè)人才培養(yǎng)也極其困難，即便是一個(gè)計(jì)算機(jī)專業(yè)的學(xué)生，真正理解操作系統(tǒng)，理解硬件底層是怎么運(yùn)作都是一件有很高難度的事情。我們看到一個(gè)很無情的現(xiàn)實(shí)是，雖然我們以為嵌入式領(lǐng)域人才已經(jīng)很多了，但是與做軟件的人比起來做嵌入式的人，數(shù)量還是太少。

　　2 軟硬鴻溝

　　換個(gè)角度，作為一個(gè)軟件的人，如果他真的有熱情，要去做硬件，他又會(huì)面臨什么樣的問題。

　　他會(huì)看到一大堆的新名詞：GPIO、I2C、C、時(shí)序、驅(qū)動(dòng)等等，如果你是做硬件的，這些名詞或許很熟悉。但我曾經(jīng)在一些軟件技術(shù)大會(huì)上做過一些調(diào)研，嘗試用這些名詞去問過不同的人，你知不知道這個(gè)詞什么意思。這些軟件工程師普遍的表情就是見了鬼一樣。他們根本不知道我在說什么。

　　軟件工程師會(huì)關(guān)心的是什么呢?他們會(huì)關(guān)心：

　　? 需求是什么

　　? 用戶體驗(yàn)是怎樣的

　　? 設(shè)計(jì)模式用什么

　　? 系統(tǒng)怎么架構(gòu)的

　　? 怎樣在高并發(fā)中保持系統(tǒng)的健壯

　　我們不難發(fā)現(xiàn)，這兩套語言幾乎就是兩個(gè)世界的語言，就像中國人說中文，英國人說英文，你沒有一個(gè)翻譯你根本不知道對(duì)方在說什么。雖然雙方都號(hào)稱自己從事的軟件開發(fā)，但談?wù)摰母静皇且换厥?。這里面存在一個(gè)巨大的鴻溝。

　　3 IoT 應(yīng)用研發(fā)，出路何在?

　　我們回過頭想想，問題到底出在哪?

　　通過前面的分析，軟硬雙方，一方是人數(shù)不夠多，另外一方想進(jìn)又進(jìn)不來，所以造成的現(xiàn)狀就是，各種硬件廠商在編寫各種各樣的硬件，所以整個(gè) IoT 的進(jìn)展速度不會(huì)太快。

　　亞當(dāng)·斯密在《國富論》的開篇提到：勞動(dòng)生產(chǎn)力上最大的改進(jìn)，以及勞動(dòng)時(shí)所表現(xiàn)的更多的嫻熟程度、技巧和判斷力，似乎都是分工的結(jié)果。

　　我們不難從前面的討論中看出，硬件廠商一個(gè)人扮演了三個(gè)角色：硬件制造、系統(tǒng)研發(fā)、應(yīng)用開發(fā)。如果能夠把三個(gè)角色分開，由不同的廠商扮演不同的角色：應(yīng)用的人把應(yīng)用寫好，平臺(tái)的人把平臺(tái)做好，做硬件的人把硬件做好。事實(shí)上，現(xiàn)在行業(yè)里已經(jīng)有人開始做這方面的嘗試了，于是，行業(yè)里就出現(xiàn)了各種 IoT 平臺(tái)。

　　接下來，我就以 Ruff 這個(gè) IoT 平臺(tái)為例，介紹一下一個(gè) IoT 平臺(tái)背后的設(shè)計(jì)理念。

　　4 IoT 平臺(tái)衡量標(biāo)準(zhǔn)

　　在討論 IoT 平臺(tái)之前，我們需要知道有哪些衡量標(biāo)準(zhǔn)來判斷一個(gè) IoT 平臺(tái)的優(yōu)劣。下面是我提出的三個(gè)衡量標(biāo)準(zhǔn)

　　? 現(xiàn)代程序設(shè)計(jì)語言

　　? 面向應(yīng)用的抽象

　　? 提供生產(chǎn)支持

　　4.1 現(xiàn)代程序設(shè)計(jì)語言

　　鑒于摩爾定律的存在，在現(xiàn)代軟件開發(fā)中，開發(fā)的效率比代碼執(zhí)行的效率要重要。所以，一個(gè)好的 IoT 平臺(tái)，需要有一門現(xiàn)代的程序設(shè)計(jì)語言。

　　我們不妨先看看 C/C++ 這個(gè)傳統(tǒng)的嵌入式開發(fā)語言在現(xiàn)代程序設(shè)計(jì)語言所需特性上的表現(xiàn)，如表1。

　　表1 C/C++在現(xiàn)代程序設(shè)計(jì)語言所需特性上的表現(xiàn)

　　再來看看 Ruff 選擇的 JavaScript 在這些特性上的表現(xiàn)，如表2。

　　表2 Ruff 選擇的 JavaScript 在這些特性上的表現(xiàn)

　　通過對(duì)比，不難發(fā)現(xiàn)，雖然 C/C++ 依然戰(zhàn)斗力十足，但作為“現(xiàn)代程序設(shè)計(jì)語言”，它們顯得不那么“現(xiàn)代”了?；蛟S你會(huì)好奇，Ruff 為什么選擇其它的“現(xiàn)代程序設(shè)計(jì)語言”，主要有下面幾點(diǎn)考量。

　　4.2 面向應(yīng)用的抽象

　　什么是面向應(yīng)用的抽象?對(duì)比兩段代碼，我們便不難發(fā)現(xiàn)，這兩段代碼完成是同樣的工作，點(diǎn)亮一盞燈。

　　先是傳統(tǒng)嵌入式風(fēng)格，簡(jiǎn)單起見，我們用了 Python 代碼做示例：

　　GPIO.output(11, GPIO.HIGH)

　　再是 Ruff 的代碼，用的是 JavaScript 語言

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

　　我們?yōu)槭裁葱枰布橄竽?因?yàn)槲覀兛吹秸麄€(gè)軟件開發(fā)的趨勢(shì)就是抽象度越來越高，從匯編到 C 語言，再到Java，今天還會(huì)有各種各樣的 DSL (Domain Specific Language，領(lǐng)域特定語言)。早年間，編寫代碼，我們可能會(huì)質(zhì)疑編譯器是否正確，手寫匯編效率會(huì)更高，但今天，我們肯定不會(huì)這么做，開發(fā)效率太低，因?yàn)橛辛顺橄?，底層的東西可以不斷優(yōu)化，越做越好。之所以抽象程度能不斷提升，還要拜摩爾定律所賜，硬件能力越來越強(qiáng)，一些執(zhí)行上的性能損失，我們是可以承受的。

　　那我們需要怎樣的抽象呢?從發(fā)展趨勢(shì)可以看出，抽象的趨勢(shì)一定是越來越接近問題領(lǐng)域。對(duì)于 IoT 平臺(tái)而言，一定是越來越接近于應(yīng)用開發(fā)。在 IoT 平臺(tái)的嘗試中，我們看到了幾種不同的抽象。

　　? 無抽象

　　傳統(tǒng)的嵌入式開發(fā)按照這個(gè)標(biāo)準(zhǔn)，就是無抽象的，其特點(diǎn)是面向硬件接口編程。

　　GPIO.output(11, GPIO.HIGH)

　　? 編程接口抽象

　　諸如 Ruff、Tessel、Jonny-Five、Cylon.js 等一些 IoT 平臺(tái)開始提供面向應(yīng)用的編程接口抽象，讓開發(fā)者無需關(guān)注底層的實(shí)現(xiàn)細(xì)節(jié)。

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

　　var led = new five.Led(13);

　　led.strobe();

　　});

　　但在這里，我們不難發(fā)現(xiàn)，我們依然要對(duì)底層的接口有了解，否則，你便不知道，這段代碼中的13是做什么用的。

　　? 隔離硬件配置的抽象

　　Ruff 在提供面向應(yīng)用的編程接口抽象基礎(chǔ)上，更進(jìn)了一步，將硬件配置隔離出去。在 Ruff 代碼中，我們甚至看不出硬件配置是什么樣的。

　　$.ready(function (error) {

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

　　});

　　Ruff 之所以要提供隔離硬件配置的抽象，主要是為了提供生產(chǎn)支持。

　　4.3 提供生產(chǎn)支持

　　大家對(duì)于新出現(xiàn)的 IoT 平臺(tái)，普遍有一個(gè)誤解，這些平臺(tái)只能用在原型研發(fā)上，因?yàn)樗鼈兛吹降氖?，采?JavaScript 的硬件要求都很高，與現(xiàn)在普遍的硬件開發(fā)狀況不符?，F(xiàn)在 JavaScript 已經(jīng)可以運(yùn)行在一些資源有限的系統(tǒng)上，比如 MCU，Ruff 就有自己的 MCU 版本，支持了幾款不同的 MCU。

　　Ruff 所做的事情更進(jìn)了一步，它將硬件配置與應(yīng)用本身分離開來，這樣的做法帶來一些好處是

　　? 應(yīng)用開發(fā)者無需關(guān)注硬件如何配置，可以將更多的將注意力放在應(yīng)用邏輯本身

　　? 硬件具體的配置方式可以在具體的部署時(shí)決定

　　一旦硬件配置可以在部署時(shí)決定，便出現(xiàn)了另外一種可能，也就是，同一個(gè)應(yīng)用可以運(yùn)行在不同的硬件上，也就是跨硬件應(yīng)用就出現(xiàn)了，這也就讓前面提及的“重復(fù)造輪子”的情況得到一定程度的緩解。

　　伴隨跨硬件應(yīng)用的出現(xiàn)，還會(huì)有一個(gè)額外的作用：測(cè)試。以往硬件測(cè)試一定要在硬件上完成，因?yàn)榍懊嫣峒暗姆N種原因，硬件測(cè)試往往要部署一個(gè)包括系統(tǒng)在內(nèi)的應(yīng)用，所以，效率是極低的。而我們知道，應(yīng)用開發(fā)中，大量的測(cè)試實(shí)際上是應(yīng)用邏輯的測(cè)試，屬于軟件測(cè)試的部分，理論上是可以在開發(fā)機(jī)上完成的。因?yàn)橛辛擞布綦x，Ruff 就提供了在開發(fā)機(jī)上做軟件測(cè)試的能力，開發(fā)的效率由此得以提升。

　　下面是一個(gè) Ruff 測(cè)試代碼的例子，可以在開發(fā)機(jī)上運(yùn)行：

　　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 結(jié)論

　　我們總結(jié)一下 Ruff 在 IoT 平臺(tái)衡量標(biāo)準(zhǔn)上的一些做法，如表3。

　　表3 Ruff 在 IoT 平臺(tái)衡量標(biāo)準(zhǔn)上的一些做法

　　基于這些做法，采用 Ruff 平臺(tái)的應(yīng)用開發(fā)，將會(huì)看到在一些模式上出現(xiàn)的轉(zhuǎn)變，如表4。

　　表4 采用Ruff 平臺(tái)的應(yīng)用開發(fā)，在一些模式上的轉(zhuǎn)變

　　以上就是 Ruff 在破局 IoT 困境上的一些思考和嘗試，歡迎讀者能夠給出自己在這個(gè)方面的見解，讓我們一起推動(dòng) IoT 時(shí)代早日到來。