用node-webkit做桌面應用

[技術産品] 用node-webkit做桌面應用

陳天 · 2 年前

小長假就這麼結束了，本來打算抽空用node-webkit寫點什麼的，結果中間一天加班，前後兩天出去玩，累了個半死。也沒顧上。

node-webkit是兩周前我才剛剛認識的桌面開發利器。那天程式君寫了篇關于github atom的文章，中間有段文字做了大膽的猜測：「這就是Atom最大的亮點！web native。在此之下，less style，coffeescript plugin，nodejs integration都水到渠成。看上去atom的源代碼來自chrome —— 我覺得atom很可能是一款以某種方式運作本地web app的浏覽器。chrome的源代碼base在webkit上（貌似是bsd），是以atom可以任意修改。很可能chrome上面的沙箱環境（不允許web app通路本地資源，如檔案系統）被移除，然後nodejs以某種方式被內建進來（這樣javascript可以通路檔案系統等本地資源）。」

很快有不少朋友或在知乎上，或在微信裡給我留言，不約而同地提到了一個技術：node-webkit。所謂「三人行，必有我師」，感謝這些讀者，你們為我開了一扇窗。^_^ 孤陋寡聞的程式君知道了這個技術後，便如饑似渴地研究了下去...如今兩周過去了，程式君也有點點小小的心得來回饋大家，尤其是當時為我指引迷津的朋友。

我會按照：what - why - how 的順序介紹node-webkit。

What

不了解web-native技術的程式員可以先稍稍了解一下webkit和基于webkit之上的chromium兩個開源項目。兩者都是BSD license的浏覽器項目。chromium的商業化産品就是我們熟悉的chrome浏覽器（我的好基友）。chromium基本就是一個作業系統，裡面提供了非常複雜的協定棧和各種功能，包括但不限于：

• 跨平台的系統資源通路，如檔案系統
• 各種網際網路相關協定，如HTTP, HTTPS, FTP, DNS, etc.
• 強大的并發處理能力
• 各種壓縮協定和算法
• 頁面快速渲染
• javascript執行引擎
• 磁盤緩存機制
• ...

可以看這張圖：

然而，為了避免來自非受信域（網際網路）上的應用進行一些非法操作，chromium提供了嚴格的沙箱環境，讓本地的很多資訊（比如檔案系統）不會暴露給網際網路上的應用。

chronium強大的功能讓人垂涎，又是BSD license，以此為基礎做一個應用程式誘惑力很大：跨平台，各種已經建好的功能，深度整合網際網路技術等。是以它是做桌面應用的一個利器。可是，chronium對于未在浏覽器行業浸淫的小團隊來說困難了些。因為你要讀懂chronium的content API文檔，要了解很多技術細節，更重要的是，基本上你需要使用C++來開發應用。google看到了裡面的機會，将chronium項目封裝出一套使用簡單的API，并（在第三方的協助下）提供了很多不同語言的binding，這樣你就可以使用你熟悉的語言進行桌面應用程式的開發，這個就是CEF（Chrome Embedded Framework）。

投抱CEF懷抱的知名項目有：

• Adobe Bracket
• Evernote
• QQ
• 豌豆莢

我沒有太研究CEF，是以就不多說。

node-webkit另辟蹊跷，它沒有基于官方的CEF進行二次開發，而是做了如下事情：

(1) 将nodejs的消息循環和chromium的結合起來，讓使用者可以在dom裡調用nodej.js的函數。

(2) 合并nodejs和chromium兩者裡的web引擎（都基于v8）。這樣所有javascript運作在一個context下。

(3) 修改沙箱模型，去除很多對桌面應用而言沒有意義的安全手段，讓應用可以最大程度通路本地資源（比如檔案，本地網絡等）。

node-webkit最大優勢是很巧妙地把nodejs結合到chronium裡，讓你可以使用幾乎所有的nodejs社群裡的module。

投抱node-webkit的知名項目有 LightTable。

Why

無論CEF還是node-webkit，都大大降低了寫複雜桌面應用的難度：不需要C++，不需要QT，不需要java，你隻需要懂html，css和javascript，就能寫出本來難度不小的桌面應用。 除此之外，還有好幾個跟現代軟體相關的原因：

現代軟體不和網際網路結合就是慢性自殺。

現代軟體沒有漂亮的UI就如同沒有學會打扮但很有内涵的姑娘。

現代軟體不能跨平台就會少很多高端使用者（mac占有率已經接近7%了）。

所有種種，CEF和node-webkit都能提供支援，相對于CEF，node-webkit使用起來更簡單，對nodejs社群的良好支援是個殺手锏。如果你稍稍看看adobe brackets（一個代碼編輯器）的代碼，就會發現其在本地檔案系統的支援上花了多少功夫。而使用node-webkit，引用fs的package即可。（當然，我相信不久的将來，CEF對此會做修改和優化）

How

"How" 是我們開啟一段程式旅程的最困難的部分。所謂細節是魔鬼，難就難在怎麼做這樣的細節上。對于node-webkit，你可以follow其repo（https://github.com/rogerwang/node-webkit）裡的wiki，一步一步做，就能成功做出一個Hello world程式。

這似乎很簡單 - 不就是寫個 package.json，外加個index.html？何難之有？

但我們想要的絕對不是hello world。我們想做的往往要複雜得多。是以我們需要一套完整的解決方案，問問自己這些問題：

(1) 我的代碼用什麼撰寫？（程式君用coffeescript, less和handlebars）

(2) 我的應用打算使用什麼樣的MVC庫？（ember, angular, backbone, etc.）

(3) 我的應用都有那些前端的（bower）和後端的依賴（npm）？

(4) 如何打包和發行？

(5) 如何測試？

(6) ...

怎麼撰寫代碼取決于你打算如何維護你的應用。最簡單的方式當然是直接撰寫html, css, js，但是這樣容易産生意大利面條式的代碼。一般web前端都是使用各種技術最終打包出來html, css和js。

如何測試很重要。雖然你在寫桌面應用，但大部分代碼都是為界面和互動提供服務的。如果這樣的代碼還不得不運作在node-webkit裡，而不是浏覽器中，那麼開發的效率會大打折扣。

經過深入探索，程式君獲得的答案是這些工具和項目：

• brunch
• Anonyfox/node-webkit-hipster-seed
• tapas-with-ember

brunch是打包工具，後兩者都是項目的template。

angular的擁趸直接用node-webkit-hipster-seed就好了，封裝得已經近乎完美。但angular不是程式君的菜，是以程式君又重新拾起已一年多未使用的ember，基于 tapas-with-ember 做了一套符合程式君自己需要的template project。你如果感興趣，可以

$ brunch new https://github.com/coderena/node-webkit-template test
           

來試試這個template結構。基本上它提供了一個非常靈活的架構，可以适應應用程式的不斷增長。

先寫這麼多，等我有了更多的經驗，會繼續分享。

如果你對本文感興趣，歡迎訂閱公衆号『程式人生』（搜尋微信号 programmer_life）。每天一篇原汁原味的文章，早8點與您相會。