首发于酷家乐前端博客前端
标题是我以第一视角基于 Electron 开发客户端产品的体验,我将在以后分一系列文章向有兴趣的朋友一步一步介绍我是怎么从玩玩具的心态开始接触 Electron 到去开发客户端产品,最后随着业务和功能的复杂度提高再不断地优化客户端。webpack
这是该系列的第一篇,我也是边学边作边反思,欢迎交流,哦,不用担忧我会「太监」这个系列文章,由于个人老大握着40米大刀注视着我,不按期出下一篇(间隔最大不超3周)。web
// 如下是单口相声,从第一视角讲我是怎么接触到 Electron 直到要本身去用它开发应用的,不喜欢能够跳过json
Electron,小名 Atom Shell,而 Atom 是 Github 发布的一款「现代化」的文本编辑器,不少人由于看到「Atom 华丽的编辑器截图」而入坑,又纷纷由于「Atom 三分钟憋不出一个P的流畅度」而弃坑,仰天感叹「封面果真都是骗人的」,我就是其中一个,这是第一次我和 Electron 接触,但那时候我还不认识她。windows
后来据说微软有一款编辑器叫「VS Code」贼好用,我就又去用了下,同样华丽的「封面」,然而却异常地好用和流畅,(这里我并不想挑起两大门派战争,只是我的体验实录),那是我和 Electron 的第二次接触,我依旧不认识她。后端
以后又在一些博客、专栏看到过诸多 Electron 的相关的文章,大体知道这是一个新的技术框架,可让 web 前端去开发跨平台的桌面客户端,但也没深刻,由于从字面上「用 Web 前端技术去开发一个桌面的客户端产品」去理解,脑中就是六个字「叔叔,咱们不约」。浏览器
而3个月前,个人老大「尼古拉斯·飞」想让我一个前端去搞 Windows 客户端开发,和我说起技术框架是用 Electron,问我要不要试试。我才第一次去确认了这个单词的读音和意思,意思是「电子」,再去看下她的前世此生,以前叫 Atom Shell「原子的壳」,是 Github 开发 Atom 编辑器时配套开发的技术框架,合理了,「原子」不就是由「电子」和「原子核」组成么,可能哪天 Github 还会出一个「Nucleus」(原子核)的东西吧...babel
更进一步,我在Electron的官网发现,不少基于 Electron 的大佬级产品,我都本身体验过,而那时的我并不知道这背后是 Electron。和我天天接触最频繁的当属「VS Code」,也是基于 Electron 的,我在公司 windows 电脑上用的 GitGUI「GitKraken」、我 Mac 上用的邮箱客户端 Nylas 等等都是基于 Electron 开发的。app
因而,我和我老大说,“我要试试用 Electron 开发客户端产品”,那时候我确实就是以为这个东西好玩好看(能够用 Web 前端写界面,通常都比较好看),额外说一句,Electron 自己这个项目也是抱着好玩的心态创造出来的。框架
我抱着把 Electron 当玩具的态度去浏览它的文档,看一些 Electron 的应用 Demo,再结合咱们客户端应用的需求去看,咱们能够从这些 Demo 中借鉴哪些思路,慢慢地,我就熟练学会了 Electron ...的拼写。
// 单口相声结束
因此,在这篇以及以后一系列的文章中,我将把本身在 Electron 方面的学习收获和应用心得记录下来,而在这第一篇文字里,我将「庸俗地」介绍如何「Quick Start Electron」,但不是 Hello World。个人「Quick Start」将依次介绍如下内容:
本文不会具体说怎么起一个 Demo 去「Quick Start」,这彻底能够在官网找到,也有不少文章写了,我只是就本身的经历去给出一些有限的建议,给有兴趣的朋友一个合理的入门参考,不少时候,当咱们实践完「Hello world」后,咱们就不知道怎么办了,因而热情就只能冰封在「Hello world」阶段了,下面这个笑话不是想要的结果。
可能主要是由于,猿类里的亚种——前端开发——又有了新的出路了吧,还没找工做的前端开发,又有了新的岗位能够去选择,已经在岗的前端也有了新一年的 KPI/OKR,刚起步的创业公司能够只拉一个前端就能开发跨平台的多个桌面客户端... ...(开个玩笑)。
这是 Electron 最迷人的地方,究其根本是由于它是创建在「Chromium」和「Node」之上的,一个负责界面,一个负责背后的逻辑,典型的「你负责貌美如花,我负责赚钱养家」,为何 Electron 可以开发跨平台的桌面应用也就能够理解了。
而对于前端开发来讲,「不要和老夫说什么 C++,Java,老夫行走江湖就一把 JS,遇到需求就是干」。前端开发能够用本身熟悉的方式去写应用界面,逻辑部分也仍是 JS,若是你精通 Node 后端,那后端也能够插一脚,「鸟枪换大炮」,你开发客户端的能力有一种「忽如一晚上春风来」的感受。
可是,不一样系统间仍是会有很大的不一样,「同一套代码,编译出跨平台的多个客户端」,话是这么说,但你得由于系统的不一样作一些额外的处理,以使得打包出的不一样系统下的应用均可以正常工做,这多是一些「if - else」的成本,但相比于那80%都能彻底复用的代码,这些成本已经很小了。
综上所述,一个 Web 前端开发者能够花不多的成本去上手 Electron,而相比于之前开发多平台客户端的成本,利用 ELectron 开发多平台客户端的成本是极低的。
由于 Electron 是基于 Node 的,意味着,Node 这个大生态下的模块,Electron 也均可以用,这减小了不少造轮子的时间,你要写一些逻辑将首先思考有没有成熟的模块能够引入,而不是本身吭哧吭哧闭门造车,本身造时间精力会大量得被消耗,上路还可能翻车。
Electron 从 Node 获益有2个方面,一个方面是如现代的 web 项目通常,开发构建流程能够引入不少成熟的包去打造出适合本身项目的开发工做流,另外一个方面就是其应用自己也能够依赖须要的包去完成本身的功能,以后的文章咱们会展开详细说。
既然 Electron 是用 Web 技术写客户端,那么看上去 Electron 要作的事,能够搬到网站上,为何还要搬到客户端,这里有3个角度的回答:
这些综合起来回答这个小节的问题就是,用 Electron 开发客户端,用户体验好,开发麻烦小,功能更强大,老板脱发少。
我没怎么用过 NW.js,但当时在没有时间深刻体验的实际状况下,我选择生态好的。
Electron 相关的社区生态很好,以后的开发过程也证实了这一点,遇到的问题基本都能经过 Stackoverflow 找到,若是没有找到,新开一个问题或者去 Github 提 Issue 均可以获得较快的解决,除非是一些已知的问题或一些看文档能够解决的问题,这类问题可能会被忽略过去。
因此,生态更好一些,我选择了 Electron。
这一节从笔者目前有限的能力给出学习和使用 Electron 可能须要经历的几个阶段,里面说起的基础的内容能够去搜一下,有不少文章都解释了,好比什么是主进程,什么是渲染进程,而一些重要的实践是以后我会慢慢写的,好比开发打包构建发行工做流、自动更新和升级的实现等。
读文档,这回事实际上是见仁见智的,若是你看文档有本身的三板斧,能够不用管这一节,否则仍是建议看一下一些读和查 Electron 文档的建议,曾经我也「行尸走肉」般地看过 Electron 文档,而后发现这样效率极低,因此都是教训啊。
文档里你不理解的,可能不少开发者已经在本身的博客里展开解释了,因此你若是遇到看文档不理解的,能够搜一些文章,结合着看,这样你才会理解,尤为对于必须理解的基本概念,这很是重要。
甚至,你可能还要结合一些代码去看。
第一遍浏览,快的一个下午,慢的2天,检查本身的成果就是搞定如下3个难题,你都能清楚地表达就能够了:
在第一遍的基础上,第二遍看 API 文档,脑中基本就有必定的框架了(别小看第一遍的浏览,这会大大提高你第二遍看的效率,也会提升之后你查文档的效率),这个时候看文档的目标就是让每一个模块在脑中有一个印象。
这个印象包括,这个模块是在哪类进程中可用的、这个模块负责什么功能,有个印象就好。
由于每一个应用的不一样,可能对于模块的重要程度排序也会不一样,我仅给出个人建议,你可能须要好好看的一些模块,「好好看」的意思是,这些模块多是很重要的,你要仔细地看:
只能在主进程使用的:
app
:控制你整个 Electron 应用的生命周期BrowserWindow
:建立和控制应用的窗口ipcMain
:用于主进程中,和渲染进程通讯的webContents
:渲染和控制你窗口中的 web 内容的(由于 Electron 中,你是用 web 写的界面)能够在渲染进程使用的:
ipcRenderer
:用于渲染进程中,和主进程通讯的remote
:能够方便你在渲染进程中直接调用主进程的方法<webview> Tag
:能够载入外界的网页以上模块是我以为是须要仔细学习的第一梯队模块,固然也说了,每一个应用不尽相同,因此整体思路仍是知道什么对本身重要,就重点看什么,至于其他的,要用到的时候去查就行。
只要你已经对 Electron 有了大体的认识,你就会查文档了,不会发生你要在渲染进程中使用的模块,但却直奔主进程中可用的模块那查半天。
有一个 Tip 是,若是你是明确能够定位的,那么你根据你的需求去查对应模块,若是你只有几个关键字,那么 Electron 提供把全部文档在一个页面内展现,这样你就能够用「搜索」了。
每过一段时间,总能看到一些文章「Electron + xxx 开发 what what what」,因此咱们能够借鉴和学习的 Demo 是不少的,可是要去挑适合本身的而且友好的 Demo 来看,而看 Demo 代码也须要必定的方式。
怎么没有第一个?「Hello World」:你把我置于何地。
直到目前,我仍是会常常看一些其余的 Electron Demo 或者已能够称为产品的应用,这个时候我不可再事无巨细地去看整个应用的代码,而是明确知道我要去看什么。
举个栗子,在开发实际应用一段时间后,我以为咱们的 Electron 应用,从开发到打包,再到构建安装包,最后到发行,整个开发工做流效率低下,很不流畅,这个时候我就去看不少的项目,借鉴不少的优秀实践,感谢他们。在那个时候,我就会只看他们是怎么组织整个工程的,是怎么划分开发的各个阶段的,又是如何让整个流程流畅地自动化的。
到后来,须要实现「自动更新」功能的时候,我又去看一些实现了自动更新的应用和 Demo,看他们是怎么实现的,最终结合咱们本身的需求实现了「分强弱的自动更新」功能。
因此在有了本身要开发的产品后,看 Electron 应用的代码,就是带着诉求去看的,这一步对优化本身的产品很重要。
以上是我对于想入坑的「坑友」们分享的一些「入坑正确姿式」,姿式不对,容易折啊。能够看到这整篇文字没啥具体的实践,但做为一个开发了一段时间产品的前端,这是我认为很重要的一些方式方法。
在以后的一系列文章中,我将介绍如下内容(肯定了必定会写的):
任重道远,欢迎交流,以上内容转载请标明原文连接和做者。