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

作者/鄭曄 Ruff公司CTO

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

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

　　1 IoT 研發(fā)困境

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

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

　　不是沒(méi)有，而是很難。

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

　　? 瀑布式研發(fā)

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

　　? 重復造輪子

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

　　? 系統與應用一體

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

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

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

　　2 軟硬鴻溝

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

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

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

　　? 需求是什么

　　? 用戶(hù)體驗是怎樣的

　　? 設計模式用什么

　　? 系統怎么架構的

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

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

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

　　我們回過(guò)頭想想，問(wèn)題到底出在哪?

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

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

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

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

　　4 IoT 平臺衡量標準

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

　　? 現代程序設計語(yǔ)言

　　? 面向應用的抽象

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

　　4.1 現代程序設計語(yǔ)言

　　鑒于摩爾定律的存在，在現代軟件開(kāi)發(fā)中，開(kāi)發(fā)的效率比代碼執行的效率要重要。所以，一個(gè)好的 IoT 平臺，需要有一門(mén)現代的程序設計語(yǔ)言。

　　我們不妨先看看 C/C++ 這個(gè)傳統的嵌入式開(kāi)發(fā)語(yǔ)言在現代程序設計語(yǔ)言所需特性上的表現，如表1。

　　表1 C/C++在現代程序設計語(yǔ)言所需特性上的表現

　　再來(lái)看看 Ruff 選擇的 JavaScript 在這些特性上的表現，如表2。

　　表2 Ruff 選擇的 JavaScript 在這些特性上的表現

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

　　4.2 面向應用的抽象

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

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

　　GPIO.output(11, GPIO.HIGH)

　　再是 Ruff 的代碼，用的是 JavaScript 語(yǔ)言

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

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

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

　　? 無(wú)抽象

　　傳統的嵌入式開(kāi)發(fā)按照這個(gè)標準，就是無(wú)抽象的，其特點(diǎn)是面向硬件接口編程。

　　GPIO.output(11, GPIO.HIGH)

　　? 編程接口抽象

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

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

　　var led = new five.Led(13);

　　led.strobe();

　　});

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

　　? 隔離硬件配置的抽象

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

　　$.ready(function (error) {

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

　　});

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

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

　　大家對于新出現的 IoT 平臺，普遍有一個(gè)誤解，這些平臺只能用在原型研發(fā)上，因為它們看到的是，采用 JavaScript 的硬件要求都很高，與現在普遍的硬件開(kāi)發(fā)狀況不符?，F在 JavaScript 已經(jīng)可以運行在一些資源有限的系統上，比如 MCU，Ruff 就有自己的 MCU 版本，支持了幾款不同的 MCU。

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

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

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

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

　　伴隨跨硬件應用的出現，還會(huì )有一個(gè)額外的作用：測試。以往硬件測試一定要在硬件上完成，因為前面提及的種種原因，硬件測試往往要部署一個(gè)包括系統在內的應用，所以，效率是極低的。而我們知道，應用開(kāi)發(fā)中，大量的測試實(shí)際上是應用邏輯的測試，屬于軟件測試的部分，理論上是可以在開(kāi)發(fā)機上完成的。因為有了硬件隔離，Ruff 就提供了在開(kāi)發(fā)機上做軟件測試的能力，開(kāi)發(fā)的效率由此得以提升。

　　下面是一個(gè) Ruff 測試代碼的例子，可以在開(kāi)發(fā)機上運行：

　　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 平臺的應用開(kāi)發(fā)，將會(huì )看到在一些模式上出現的轉變，如表4。

　　表4 采用Ruff 平臺的應用開(kāi)發(fā)，在一些模式上的轉變

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