GitHub 如何基於 Node.js 和 Chromium 開發 Atom？

weixin_34321977發表於2015-07-01
GithubNode.js

看到回答裡, 多數都沒有回答到點子上, 還有些給了非常主觀的意見而沒有給出實際結論和分析過程.

題主的問題有四個: 

1. Github 如何基於 Node.js 和 Chromium 開發 Atom?

Atom 是基於 Atom-Shell (atom/atom-shell · GitHub) 開發的, atom-shell 是一個將 Chromium 和 Node.js (在最近的版本中已經替換成了 io.js 了) 整合在一起的 shell 框架. 那麼他是如何整合 node.js 和 chromium 的呢? Atom-Shell 在瀏覽器的底層和渲染層分別加入了 node.js 的事件迴圈, 由此在瀏覽器核心中驅動了 node.js. 之所以將渲染層和核心層的事件迴圈區分, 是為了 CEF3 的渲染架構而這麼設計的, 而為了能夠讓渲染層之間, 以及渲染層和核心層之間通訊, 採用 ipc 進行封裝, 具體的 ipc 實現我沒深入去檢視原始碼, 應該是直接走了 Chromium 的 IPC 介面. 
類似的 Shell 技術還有 nw.js 和 bracket-shell. 但是這些 shell 技術都有差異, 具體的差異可以閱讀這幾篇文件:

atom-shell/atom-shell-vs-node-webkit.md at master · atom/atom-shell · GitHub



Github 的 Atom 就是在 Atom-Shell 的基礎上, 通過 coffee-script 寫頁面端的表現, 通過 node.js/io.js 的整合處理 io 層的需求. 然後通過 atom-shell 整合作業系統中一些 native 視窗的能力.

2. 有過來人能分享學習經驗?

學習經驗倒也談不上, 我基本上是閱讀了一遍 atom-shell 官方的文件, 重點學習了一下如何使用 ipc 進行視窗間, 核心層之間的通訊方式以及頁面程式設計相關的知識. 這個過程中, 我覺得有幾個地方可以系統學習:

1. 通訊模型的建立:

為了更好的進行 ipc 通訊, 我們需要一些有效的經驗模型來總結通訊的方法, 為此, 我找了兩個通訊模型的文件進行學習:

Getting Started with 'nanomsg'


通過對 nanomsg, zero-mq 中提出的幾種通訊方式的總結, 我們漸漸地設計出符合我們需求的訊息通訊編碼規範, 和通訊型別. 

2. CSS 排版, DOM 頁面渲染知識:

為了能夠讓我寫的 GUI 高效的在頁面中運轉, 我需要掌握更多的關於瀏覽器如何渲染 DOM, 如何解析 CSS 等瀏覽器渲染核心的知識, 為此我閱讀了以下文件:

How Browsers Work: Behind the scenes of modern web browsers (這是一篇基礎入門的好文章, 他讓我在短短1個禮拜內, 通過自己的編碼實踐和擴充套件閱讀理解了瀏覽器的大概的工作原理)
Getting Started With the WebKit Layout Code (這也是一篇非常好的文章, 他通過解析 Webkit 的底層 layout 程式碼, 讓你明白整個瀏覽器是如何進行 css 排版工作的)
A Visual Method for Understanding WebKit Layout (這篇文章繼承上一篇, 通過實踐進一步理解 layout 的技術內容)
Rendering: repaint, reflow/relayout, restyle / Stoyan's phpied.com (這篇文章也是講關於 reflow 的底層細節)
Understanding the CSS Specifications (然後因為 css 的文件本身太晦澀, 我一個初入門 web 前端程式設計的人一開始沒能讀懂, 所以我就先找到了這篇進行學習)
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification (在那之後, 我進行了一些實踐, 差不多覺得可以掌握了, 就通讀了一遍這篇文件, 並通過少量編碼, 完成大部分 css2 的排版計算過程, 打通了我心中對於排版的諸多疑問)

這之後, 我又擴充套件閱讀了以下一些 css 草案:


然後通過上面的幾輪實踐, 我又回過頭來學習了以下幾篇關於排版的知識點:

大概前前後後花了約 4 個月時間, 完成了整個 web 渲染和排版的基礎知識. 

3. Node.js/io.js 學習

Node.js 的學習我是在專案中持續進行的, 這期間由於專案進度比較緊張, 我並沒有很好的做好各種學習筆記, 所以不好意思, 沒有特別多可以分享的經驗. 

3. 還有通過這種方式開發移動應用呢?


有一些 Hybrid 的應用通過相似的方法構建, 比較出名的有:

這方面我接觸的不多, 所以沒有太多的經驗可以分享.

4. 基於 Node 開發類桌面應用有什麼建議?


我覺得還是要從專案本身的需求出發點考慮, 如果你是一個 javascript 依賴較多的專案, 或者一個偏頁面應用的專案, 那麼基於 Node/Chromium 構建的桌面 APP 將給你帶來非常好的基礎結構, 讓你專注在開發本身.

 

 

*********************************************************************************************************************************************************

 

題主不必把眼光侷限在 ATOM，對於一般的應用程式，我更推薦 XDK 使用的框架 nodw-webkit，也就是現在的 NW.js，這個框架做起來非常順手。

我不推薦 ATOM 所用的 atom-shell，原因在於它比較難上手，特別是引入了 ipc 通訊機制。如果你是做一些類似 CS 架構的應用，那麼 ipc 是你的得力助手。如果你只是做一些普通的桌面應用，ipc 會逼著你把簡單的任務複雜化，違反了 KISS 原則。而且 ipc 有很多坑，會成為你開發中最浪費時間的部分。

下文統一介紹一下這個領域現成的技術框架和成功案例：

atom 基於 atom-shell 開發而來，atom-shell 基於 node.js(io.js) 和 Chromium(CEF2) 開發而來。
atom-shell 代表案例可參考 Fireball 總設計師回答的這個帖子：還要多少年, 前端開發才能像客戶端開發那樣輕鬆？ - Johnny Wu 的回答

NW.js 由 node-webkit 更名而來，技術底層和 atom-shell 是一樣的，比 atom-shell 還容易上手，用的人最多。node-webkit 是為了支撐 Intel 自家的 XDK 而做的，誰會想到這樣的 IDE 神器竟然是用 JavaScript 寫的？但也正是由於這點，nw 之前的更新停滯了一段時間，於是被我們無情拋棄了，這個專案最近似乎重新活躍了起來。

看完上面的兩個框架和對應的案例，我想題主心中會有答案。此外類似的框架還有比較小眾的 brackets-shell 和 heX，分別支撐 brackets 和 有道詞典的開發。

下面是吐槽時刻：

nodejs + chromium ≈ sb

為什麼這麼說，先說≠的部分，如果你要在linux花30分鐘寫出一個介面酷炫功能簡單的小工具，nodejs+chromium（也就是node-webkit）是很好的選擇，在windows上是vb，要介面酷炫的話 + wpf，mac也請退坑，預設的就夠好了。

誰都知道WPF和VB很好用，但是要跨平臺怎麼辦？想要跨平臺的話，用 node+web 再好不過了。

如果你要做個比較重的東西，chromium的效率和bug會把你拖累成狗，你說npm絕贊？node-webkit索然披著node皮但是用到原生程式碼的編譯起來炒雞蛋疼。

atom-shell 的 bug 響應時間是按天算的呢，chromium的效率還真的很棒。原生程式碼的編譯蛋疼在哪了…… 不就一個命令列搞定的事嗎？你要是換了其它技術，那編譯起來各種依賴庫才叫一個酸爽呢。

如果你要做一個小玩意，但是給人用，帶個node-webkit不知道多重……

好幾十MB，聽起來是很重，但是我用有道詞典那麼多年了，一直沒發現它很重啊？誰會注意到它是 CEF 做的呢。你做了一個棒棒的工具，這年頭誰還會在乎體積啊？

其他的，你要炫酷介面opengl/directui

網頁做介面才叫酷炫呢，看看我上面的 atom-shell 案例

你要跨平臺gtk / qt各有各的好

AIR 和 Java 更好，gtk/qt 已經入土為安了。

速度慢, 執行效率低.

看我的案例，遊戲引擎都能做了，XDK 這樣的重量級 IDE 都能做了，還有什麼效能上可質疑的呢？

佔用資源較多.

你做的什麼應用，要常駐後臺嗎？你的記憶體還差這幾十MB？

開發週期長.

明明是縮短了開發週期好嗎…… 不信你跨個平臺試試。就算不跨平臺，你看看我前面 atom-shell 貼的案例吧，網頁做起 UI 開發效率很高的。

references:

http://www.zhihu.com/question/23679877

相關文章