Ruff OS讓智慧硬體開發變簡單

眾所周知，從現在開發者角度來說，我們的時間比機器的時間更值錢。今天大家聽了一天前端的討論，就是為了不斷優化開發效率。從硬體方面進行優化的時候，我們的關注點也是能夠不斷提高開發效率。所以在 Ruff 的設計中，開發高效是我們最核心的設計方向。

在設計 IoT 應用平臺的時候，我們的關注點是希望能用現代的設計語言去做開發，能夠有一個面向應用的抽象，能提供生產的支援。

我們選擇的程式設計語言是 JavaScript 。

可能對於做 JS 的人來說，記憶體管理是稀鬆平常的事，但這卻是 C 和 C++ 的程式設計師永遠的痛點。

應用開發過程中需要提供一個很好的測試框架去完成相關工作。C 和 C++ 的程式設計師會覺得測試是一件非常痛苦的事，尤其是 C 和 C++ 的編譯模型對測試的支援並不是特別好。

C 和 C++ 的程式設計師沒有一個很好的包管理軟體庫，他們每拿到一個庫都需要重新編譯一遍。

以上就是我們選擇現代程式設計語言所要考量的幾個維度，而 JavaScript 在這些方面都有較為友好的表現。

JavaScript 還有一些特點，比如能支援多種正規化的程式設計模型，支援函數語言程式設計也支援物件導向的程式設計。

從流行度來說，Java 是一個很好的選擇。無論它的規模怎麼下降，目前在全行業還是排名第一的，Android 也用 Java 作為它應用開發的語言。但是在硬體開發的領域裡，Java 的虛擬機器太大了，在記憶體上有所限制。

還有就是像 Lua、Ruby 這樣的程式設計語言，喜愛它們的人會覺得很好用，但是放在全社群的角度，流行度還不夠高。

C 語言在我之前的吐槽中，大家也能看出我對它有多麼不看好。

相比之下只能選擇了 JavaScript。

$( ‘#light’ ).turnOn( );複製程式碼

GPIO.output(11,GPIO.HIGH)複製程式碼

應用抽象

led.turnOn( );複製程式碼

抽象級別

一個 IoT 開發平臺能做到的面向應用的抽象，可以把硬體驅動和軟體介面隔離開來，應用開發者只要保證軟體介面正確的呼叫，硬體驅動開發者來保證驅動編寫的正確性。這樣，應用開發者只要保證應用邏輯的正確性即可。

我們做了一個應用 “ Ruff PI ”，中文名叫裝置寶。它是由上海南潮資訊科技有限公司利用其物聯網作業系統開發的一款工廠的生產力助手應用產品。旨在通過資訊化及物聯網技術提高工廠生產效率及改善工廠生產管理，讓傳統工廠快速聯網，實現數字化轉型。Ruff PI 可以把工業領域裡的一些裝置監控起來，提供一些事件通知幫助我們對問題進行快速處理。

Ruff 在光伏領域幫助做一些電量資料的採集，工廠裝置數字化，以及對電力進行監控。

我剛才提到了不用 Java 做 Ruff，是因為它佔的記憶體太大了，而我們需要跑在256K 甚至更低的記憶體上，這才是 IoT 開發的常態。Ruff 在朝著更低的資源佔用的方向發展。

Ruff 還相容 API，並已經支援 TI TM4C1294、ESP32 這幾個晶片。從整個體系設計來說，Ruff 是一個開放的體系，我們會根據不同專案的需求往不同晶片上去移植。在 Ruff 上寫完的程式碼也可以平滑地移植到晶片上。

站在生產視角上，我們進行了區分。

對於每個不同的硬體可能會有不同的 layout，這樣實現了程式碼在不同的開發板上無縫移植。在 Ruff 的整個體系設計上，程式碼是可移植的。

如果有了 Ruff 這樣的平臺，未來的開發會變成圖上右邊的結構。意味著硬體是硬體的釋出週期，平臺是平臺的釋出週期，應用是應用的釋出週期。但是這個模式目前在 IoT 這個領域中並沒有很好地做到，原因就是沒有一個平臺把它們很好地區分開來。而 Ruff 做得就是通過一個平臺把應用和底層硬體隔離開，來實現一種全新的釋出模式。這樣就不會出現很多應用開發實際上是被硬體開發綁架了的可能性。

我們會把對工業領域做的探索變成未來對社群釋出的能力。

我們會提供更多的系統物件，提供系統訪問的能力。提供能力描述，應用依賴於能力，不依賴於硬體。未來還會有板卡，可以自己擴充套件板卡能力，把不同能力暴露出來。

這是我們 Ruff 2.0 未來要做的事情。

我今天的分享就到這裡，感謝聆聽！