放棄了C和Java，我為什麼選擇了JavaScript

作者 屠敏

責編 屠敏

萬物互聯時代，很多人仍然會有這樣一個疑問：「為何物聯網概念與技術提出並發展了多年，卻感覺離我們仍很遙遠？」。解惑這個問題之前，我們不妨先探討智能手機為何會成為人們生活不可或缺的一部分。智能手機可基於 Android 或 iOS 操作系統，承載運行多款 App，嫁接起技術與用戶之間的橋樑。

反觀物聯網之所以遲遲無法走進人們的生活，究其根本原因之一——應用的缺乏。在現如今這個軟體吞噬硬體的趨勢之下，作為一名開發者，該如何更為快捷簡單的上手硬體應用開發？如何進行適合的工具選型？面對更為嚴峻的挑戰，需要具備哪些新技能？

Ruff CTO 鄭曄

1

個人從業經歷和團隊背景

在 IT 行業沉浸十幾年，我的職業生涯分成三個階段：

在東軟，學會了做軟體，而不僅僅是寫程序，但對於製作軟體的過程，我產生一個疑問，怎麼做軟體才是合理的。

在 ThoughtWorks，我學會了敏捷/精益軟體開發方法，能用一個非常順暢的過程製作軟體。在那段經歷的後期，我也開始思考，希望能夠做一些能夠對行業有影響力的事，Moco 就是我在那個階段開始的一個作品。

在 Ruff，就是我現在所供職的公司，我希望用自己這些年對技術的理解，改變 IoT 應用開發的現狀，打造一個 IoT 版本的 Android。

從個人的經歷上來看，貌似跨度比較大，從軟體到硬體，但本質上，我有一個核心關注點，提高開發者的效率。

通過軟體過程，把事情做對，節省時間，比如對敏捷軟體開發方法的推廣；

打造工具，簡化開發者的工作，比如 Moco；

編寫框架，為開發者提供新的抽象，比如 Ruff。

在我心目中有一個偏執的印象，只有為程序員提供支持，無論是工具，還是基礎庫，才算得上高手，例如開發了 Linux 和 Git 的 Linus Torvalds、開發了 MapReduce 的 Jeff Dean 等技術大牛。

我們團隊囊括了各方面的人才，有從 Intel、NVIDA 這樣大公司出來的底層技術高手，也有一些為開源操作系統做過貢獻的人，還有一些在雲服務廠商工作的技術者等。

Ruff 的技術團隊現在大約有30人左右的規模：

硬體團隊，負責 Ruff 的開發套件，以及一些合作項目中，硬體的設計與生產；

Ruff SDK 團隊，負責硬體端 Ruff 的設計與維護；

雲端團隊，負責雲平台的建設，甚至包括手機 App 的開發。

2

Ruff 設計宗旨及特點

Ruff 從始至終有一個理念：讓 IoT 應用開發變得更簡單。

Ruff 旨在讓軟體開發者能夠進入到硬體開發的領域，因為軟體開發者不懂硬體，Ruff 設計就是將底層的硬體概念隔離開，基於此，我們引入了設備抽象的概念，讓開發者像用程序庫一樣操作硬體。

在我們看來，IoT 一定是未來重要的組成部分，但 IoT 發展得實在太慢，究其根源在於，能夠在這個領域中開發應用的人太少，懂硬體的開發者稀缺，而懂硬體又懂應用的開發者更是少之又少。移動互聯網領域已經為我們演示了如何為手機應用開發領域帶來新的開發者，就是讓軟體開發者進入這個領域。對於屬於未來的 IoT，我們希望看到同樣的故事再次上演。

Ruff 現階段解決的最重要的問題是，讓軟體開發者能夠編寫硬體應用，這等於為軟體開發者打開一道新的大門。

與此同時，Ruff 還對研發效率非常關注。從入門開始，我們的開發者通常幾分鐘就能完成「Hello，world」級別的開發，而傳統的方式中，開發者僅僅搭建環境這一項就需要很長時間。

再有，眾所周知，測試驅動開發是更好的寫代碼方式，而這種方式的重點是小步快跑。在傳統的硬體開發中，幾乎是不可能的，主要是受下面幾點所限：

傳統硬體開發中，開發者必須把代碼部署到硬體上，才能知道代碼運行是否正常。

鏡像燒寫是一個比較漫長的過程，每次部署代碼到硬體都需要很長時間。

所以，嵌入式開發者的習慣是，編寫一段很長的代碼，然後再部署到硬體上，慢慢調試，從研發效率的角度來說，這種做法效率極低。

在 Ruff 應用開發中，測試驅動開發是能做到的，因為 Ruff 有應用抽象，可以把硬體驅動和軟體介面隔離開來，應用開發者只要保證軟體介面正確的調用，硬體驅動開發者來保證驅動編寫的正確性。這樣，應用開發者只要保證應用邏輯的正確性即可，而 Ruff 提供了測試框架，讓應用開發者可以在沒有硬體的前提下，運行應用測試。應用在具體硬體上的測試，就成了集成測試，而不是開發者每步都要做的事情。

即便是硬體上的測試，因為 Ruff 分離了應用與系統，每次部署到硬體只要部署應用即可，系統無需重新部署，部署效率就大幅度提高了。

Ruff 物聯網操作系統特點

側重點的差異，現在各大公司出品的物聯網操作系統大多是在原有的領域不斷拓展，比如，華為的 LiteOS 是希望操作系統佔用內存更少，ARM 的 mbed 希望讓原來硬體工程師的工作稍微簡單一點，所以，根本上來說，他們比拼的是存量市場，而 Ruff 要做的是增量市場，讓軟體工程師進入到硬體應用領域中來。

做增量市場的事情，谷歌是有經驗的，因為他們做過 android。但在 IoT 領域的探索，谷歌現在做得還不夠，之前他們曾經做過 Brillo，後面變成了 Android Things，但他們沒有解決的問題是一樣的，這兩個框架採用依然是硬體開發者的語言(比如：GPIO、I2C)，軟體開發者不會用，硬體開發者很難從 C 改成 C++或 Java。

3

基於 Javascript 開發硬體應用優勢及難點

優勢

首先，C/C++ 是硬體開發者相對熟悉的語言，但是，以基礎設施的角度來看，C/C++ 有些老了，對於現代軟體工程的支持存在天然的缺陷，比如，C/C++ 至今沒有一個好的包管理工具。對於硬體開發人員來說，可移植性是個永遠的痛，每次拿到一款新硬體，讓程序跑起來都是件痛苦的事情。

對於其它非 C/C++ 的語言，要應用在硬體上，主要面臨兩個問題：

運行時，能不能把這個語言跑在硬體上，尤其是內存很小的單片機上，像 Java 這樣的語言，就被排除了。

流行程度，有一些語言運行時很小，比如 Lua，但對大多數程序員而言，這些語言都是陌生的。

綜合這些因素，在我們開始 Ruff 的時候，JavaScript 是當時看來最好的選擇，社區蓬勃發展，各種配套工具很豐富，有各種運行時實現可供選擇。隨後的發展也可以看出，後來在其它公司在這方面的探索，也選擇了 javascript 這條路。

難點

用 JavaScript 開發硬體，第一步就是讓硬體能夠運行 JavaScript。大多數開發者可能不理解這裡的難度，很多人以為我們就是把 Node.js 移植到硬體上，其實不然。node.js 能夠運行 JavaScript 的基礎是 V8，而 V8是一個為瀏覽器設計的 js 引擎，在 PC 上運行時，它幾乎可以完全不顧慮資源進行性能優化，所以，V8佔用的資源非常多，而硬體領域，資源是受限的，V8引擎根本運行不起來，也就是 Node.js 根本不能在資源受限的硬體上運行。所幸，JavaScript 社區發展足夠好，有很多 JS 可供選擇。所以，我們前期的工作等於基於一個引擎構建了一個另一個 Node.js。

以 Ruff 的設計目標而言，有一個重點是，如何設計一個面嚮應用開發者的抽象，把硬體設計細節全部隱藏起來。直到我們找到了下面這段代碼：

$( #led ).turnOn();

很多第一次看到 Ruff 的軟體開發者，尤其是 Web 開發者看到這段代碼時，第一反應通常是這和 jQuery 很像。這就是我們想要的感覺，開發者面對的是他們有些熟悉的東西，而不是完全地陌生，心裡負擔會一下子降下來，有興趣進一步了解。

Ruff 前期遇到的問題，大多是這種「表達」層面的難題，比如，怎麼寫驅動。對我們來說，把驅動實現出來並不難，難的是怎麼表達成開發者們熟悉的模式。我們也參考了大量已有的框架，最終選定了現在的做法，從中不難看出 React.js 的影子：

driver({

attach: function(inputs) {

...

},

exports: {

turnOn: function() {

...

}

}

});

作為一個堅定的敏捷軟體開發支持者，測試驅動開發（Test Driven Development）是我生命中不可或缺的一部分。在硬體開發中如何支持 TDD，因為 TDD 需要小步迭代，而傳統的硬體開發中，每次都要把代碼部署到硬體上，這個周期會非常長，很難實現 TDD。但基於我們的設計，我們有了一個很好的分層，就很容易把硬體操作變成軟體方法調用，這樣，我們就用軟體習慣的方式進行測試，比如，使用 Mock Object 模式進行測試。

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

runner.run(appPath, function() {

verify($( #led-r )).turnOn();

});

};

解決方案

更準確的說， IoT 全行業都缺乏足夠的行業解決方案。因為物和網這兩個概念長期處於獨立發展的階段，做硬體的人只關注硬體怎麼運作得更高效，做業務的人難以跨越硬體鴻溝，很少有人把它們結合起來思考。任何希望構建行業解決方案的團隊，都需要構建自己的軟硬體團隊，從行業的角度來說，這是極大的浪費。

我們現在也在探索一些行業解決方案，比如我們現在在工業物聯網領域有一個設備運維的產品，能夠讓工廠的人時刻監控設備狀態。站在業務的角度，這個方案並不複雜，但怎麼把設備接入到雲端，這就是一個鴻溝。有了 Ruff，整個過程就會變得相對容易很多，我們開發了一整套接入方案，現在我們就可以把軟硬體作為一個整體進行思考，比如有了設備數據，可以怎樣結合人工智慧的方式，進行工藝上的改進，甚至客戶可以怎樣設計新的流程，適應基於 IoT 的生產模式。

單純從建議上來說，很容易說從業務上進行整體思考，但從行業的現狀上來說，缺少了一個讓軟硬體成為一體的基礎，這也就是現在 Ruff 希望在行業里扮演的角色。

4

硬體應用開發平台安全性問題

安全是一個永遠不可忽視的問題。在 Ruff 的設計過程中，我們也是非常關心安全問題的。相較於之前直接控制硬體，Ruff 的應用是運行在受控的（Managed）環境中。在這樣的環境下，Ruff 就可以不斷地提升運行時的安全性，應用在原封不動的情況下，整體安全性就會得到提升。Ruff SDK 提供的各種組件，比如 SSL，我們也會不斷升級，保證能夠反映當前行業比較新的進展。這就是應用平台一個重要的差異，應用不需要做什麼，安全性就會得到提升。

在 Ruff 的設計中，我們還設計了一些機制，減少安全隱患，比如只允許一個應用，不存在像多應用破壞其它應用的可能性。在生產環境中也設計了一些機制，保證應用不會在陌生的條件下進行更新。隨著 Ruff 在生產環境下的應用，我們會在這個領域投入更多的精力，為應用提供一個更加安全的運行環境。

5

軟體開發者的硬體應用開發之路

硬體對於軟體開發者來說，只是沒做過，有學習門檻，因為需要懂硬體介面、驅動、中斷處理、時序等技術，聽完所需要的技術後部分開發者基本上就準備放棄了。

但如果換個角度來看，首先直接寫一個程序，按個按鈕點亮一盞燈，這樣開發者幾乎就可以很容易的開始起步硬體開發的學習。

$.ready(function (error) {

$( #button ).on( push , function () {

$( #led ).turnOn();

});

$( #button ).on( release , function () {

$( #led ).turnOff();

});

});

當學會控制硬體的之後，再去了解燈到底怎麼點亮的，看類似這樣的驅動代碼，複雜度也就大幅度降低了：

turnOn: function() {

}

從學習的角度，一個好的方式是在已有的基礎上，逐漸擴展新知識。在硬體領域，之前沒有特別好的入門方式，有了 Ruff，我們就可以一步一步地邁進硬體開發領域。

6

物聯網面臨的挑戰及未來展望

硬體廠商做應用，是阻礙行業進步的一大痛點。

在很多硬體廠商眼中，不存在硬體和應用的區分，他們在做的事情，就是一個做硬體，如同當年手機廠商認為手機就是一個手機一樣。今天的移動互聯網已經告訴我們，手機只是一個計算平台，有了 Android 和 ios 之後，上面可以承載多種不同的應用。大多數用過當年諾基亞和摩托羅拉應用的人，對比今天的手機應用，會非常明顯的感受到，當年的應用使用體驗有多糟糕。這和今天硬體廠商同時做硬體和應用是異曲同工。IoT 領域要發展，關鍵就是打破堅冰，實現社會分工：讓硬體廠商做好硬體，讓應用廠商做應用。

物聯網領域目前的狀態是，實現技術蓬勃發展，應用進展緩慢。

我們看到晶元廠商、硬體廠商、系統廠商不斷地推陳出新，推進各種技術，硬體越來越強大，技術越來越先進，系統佔用資源越來越少。但是，技術不能轉換應用，這些越來越強大的技術怎麼才能進入到人們的日常生活，這就是應用廠商要做的事情。

在我看來，物聯網領域最大的挑戰就是應用太少，這也就是我們現在在嘗試解決的問題。沒有足夠多的人做應用，這個領域就不可能真正的發展起來。

關於物聯網的未來，會不同的物聯網應用，這裡的應用不僅僅是在硬體上，而是作為一個完整的物聯網應用，從硬體到雲，甚至到手機的控制端。普通消費者可以獲取各種應用，結合自己的硬體，實現各種物聯網的場景。

我們之所以要構建 IoT 應用平台，主要是希望能夠降低 IoT 應用的開發門檻，讓更多開發者，尤其是軟體開發者能夠進入到 IoT 研發領域中。現在的 Ruff，為硬體端引入軟體開發者，在我們的大 IoT 平台中，開發者可以在雲端編寫各種物聯網應用場景，無需了解具體的設備是哪個廠商的。有了這樣的平台，現在的軟體開發者可以順利進入物聯網開發領域，構想各種有趣的場景。有了低的門檻，開發者便更容易進入，有了足夠多的開發者，物聯網也就未來可期了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！