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

看到回答里, 多数都没有回答到点子上, 还有些给了非常主观的意见而没有给出实际结论和分析过程.

题主的问题有四个: 

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

你可能感兴趣的:(node.js)