Electron，從玩玩具的心態開始，到打造出一款愈來愈優秀的桌面客戶端產品

時間 2019-11-10

標籤 electron 玩具心態開始造出一款愈來愈優秀桌面客戶端產品简体版

原文原文鏈接

標題是我以第一視角基於 Electron 開發客戶端產品的體驗，我將在以後分一系列文章向有興趣的朋友一步一步介紹我是怎麼從玩玩具的心態開始接觸 Electron 到去開發客戶端產品，最後隨着業務和功能的複雜度提高再不斷地優化客戶端。webpack

這是該系列的第一篇，我也是邊學邊作邊反思，歡迎交流，哦，不用擔憂我會「太監」這個系列文章，由於個人老大握着40米大刀注視着我，不按期出下一篇（間隔最大不超3周）。
web

// 如下是單口相聲，從第一視角講我是怎麼接觸到 Electron 直到要本身去用它開發應用的，不喜歡能夠跳過

Electron，小名 Atom Shell，而 Atom 是 Github 發佈的一款「現代化」的文本編輯器，不少人由於看到「Atom 華麗的編輯器截圖」而入坑，又紛紛由於「Atom 三分鐘憋不出一個P的流暢度」而棄坑，仰天感嘆「封面果真都是騙人的」，我就是其中一個，這是第一次我和 Electron 接觸，但那時候我還不認識她。

後來據說微軟有一款編輯器叫「VS Code」賊好用，我就又去用了下，同樣華麗的「封面」，然而卻異常地好用和流暢，（這裏我並不想挑起兩大門派戰爭，只是我的體驗實錄），那是我和 Electron 的第二次接觸，我依舊不認識她。

以後又在一些博客、專欄看到過諸多 Electron 的相關的文章，大體知道這是一個新的技術框架，可讓 web 前端去開發跨平臺的桌面客戶端，但也沒深刻，由於從字面上「用 Web 前端技術去開發一個桌面的客戶端產品」去理解，腦中就是六個字「叔叔，咱們不約」。

而3個月前，個人老大「尼古拉斯·飛」想讓我一個前端去搞 Windows 客戶端開發，和我說起技術框架是用 Electron，問我要不要試試。我才第一次去確認了這個單詞的讀音和意思，意思是「電子」，再去看下她的前世此生，以前叫 Atom Shell「原子的殼」，是 Github 開發 Atom 編輯器時配套開發的技術框架，合理了，「原子」不就是由「電子」和「原子核」組成麼，可能哪天 Github 還會出一個「Nucleus」（原子核）的東西吧...

更進一步，我在Electron的官網發現，不少基於 Electron 的大佬級產品，我都本身體驗過，而那時的我並不知道這背後是 Electron。和我天天接觸最頻繁的當屬「VS Code」，也是基於 Electron 的，我在公司 windows 電腦上用的 GitGUI「GitKraken」、我 Mac 上用的郵箱客戶端 Nylas 等等都是基於 Electron 開發的。

因而，我和我老大說，「我要試試用 Electron 開發客戶端產品」，那時候我確實就是以爲這個東西好玩好看（能夠用 Web 前端寫界面，通常都比較好看），額外說一句，Electron 自己這個項目也是抱着好玩的心態創造出來的。

我抱着把 Electron 當玩具的態度去瀏覽它的文檔，看一些 Electron 的應用 Demo，再結合咱們客戶端應用的需求去看，咱們能夠從這些 Demo 中借鑑哪些思路，慢慢地，我就熟練學會了 Electron ...的拼寫。

// 單口相聲結束

因此，在這篇以及以後一系列的文章中，我將把本身在 Electron 方面的學習收穫和應用心得記錄下來，而在這第一篇文字裏，我將「庸俗地」介紹如何「Quick Start Electron」，但不是 Hello World。個人「Quick Start」將依次介紹如下內容：
json

是什麼讓 Electron 如此迷人（尤爲是對於前端）
Electron 入門的幾個階段和對應要完成的事
該怎麼去閱讀和學習 Electron 的文檔
該如何去挑選一些 Electron 的 Demo 源碼來學習和實踐
以後的該系列文章會涉及到哪些功能或主題（吊個胃口）

本文不會具體說怎麼起一個 Demo 去「Quick Start」，這徹底能夠在官網找到，也有不少文章寫了，我只是就本身的經歷去給出一些有限的建議，給有興趣的朋友一個合理的入門參考，不少時候，當咱們實踐完「Hello world」後，咱們就不知道怎麼辦了，因而熱情就只能冰封在「Hello world」階段了，下面這個笑話不是想要的結果。

windows

1、是什麼讓 Electron 如此迷人？

可能主要是由於，猿類裏的亞種——前端開發——又有了新的出路了吧，還沒找工做的前端開發，又有了新的崗位能夠去選擇，已經在崗的前端也有了新一年的 KPI/OKR，剛起步的創業公司能夠只拉一個前端就能開發跨平臺的多個桌面客戶端... ...（開個玩笑）。
後端

1. 能夠用 Web 前端技術開發跨平臺的桌面客戶端

這是 Electron 最迷人的地方，究其根本是由於它是創建在「Chromium」和「Node」之上的，一個負責界面，一個負責背後的邏輯，典型的「你負責貌美如花，我負責賺錢養家」，爲何 Electron 可以開發跨平臺的桌面應用也就能夠理解了。

而對於前端開發來講，「不要和老夫說什麼 C++，Java，老夫行走江湖就一把 JS，遇到需求就是幹」。前端開發能夠用本身熟悉的方式去寫應用界面，邏輯部分也仍是 JS，若是你精通 Node 後端，那後端也能夠插一腳，「鳥槍換大炮」，你開發客戶端的能力有一種「忽如一晚上春風來」的感受。

可是，不一樣系統間仍是會有很大的不一樣，「同一套代碼，編譯出跨平臺的多個客戶端」，話是這麼說，但你得由於系統的不一樣作一些額外的處理，以使得打包出的不一樣系統下的應用均可以正常工做，這多是一些「if - else」的成本，但相比於那80%都能徹底複用的代碼，這些成本已經很小了。

綜上所述，一個 Web 前端開發者能夠花不多的成本去上手 Electron，而相比於之前開發多平臺客戶端的成本，利用 ELectron 開發多平臺客戶端的成本是極低的。
瀏覽器

2. 能夠從 Node 的生態得到極大的助力

由於 Electron 是基於 Node 的，意味着，Node 這個大生態下的模塊，Electron 也均可以用，這減小了不少造輪子的時間，你要寫一些邏輯將首先思考有沒有成熟的模塊能夠引入，而不是本身吭哧吭哧閉門造車，本身造時間精力會大量得被消耗，上路還可能翻車。

Electron 從 Node 獲益有2個方面，一個方面是如現代的 web 項目通常，開發構建流程能夠引入不少成熟的包去打造出適合本身項目的開發工做流，另外一個方面就是其應用自己也能夠依賴須要的包去完成本身的功能，以後的文章咱們會展開詳細說。
babel

3. 這個東西網站也能夠爲何須要客戶端？

既然 Electron 是用 Web 技術寫客戶端，那麼看上去 Electron 要作的事，能夠搬到網站上，爲何還要搬到客戶端，這裏有3個角度的回答：
app

用戶角度： 客戶端是一款獨立的軟件，其綜合體驗通常都是比網站高的，尤爲是涉及到「工具」範疇的應用，此外，特定的用戶羣體也會有相似的使用習慣
發行方角度： 客戶端是另外一種產品形式，是一種產品的分發方式和入口，客戶端能夠實現不少本地應用獨有的需求去觸達用戶，也能提供更加可靠的服務
開發角度： 終於...不用考慮瀏覽器兼容了，Chromium 也足夠開發使用一些先進的 CSS 或 JS 特性，咱們如今還沒計劃引入 webpack 和 babel，由於如今好像夠用，剋制纔是愛，除了寫起來爽，對於開發來講，終於跳出了瀏覽器的沙盒，你能夠本身去控制 Electron 中的「瀏覽器」，莫名的開心

這些綜合起來回答這個小節的問題就是，用 Electron 開發客戶端，用戶體驗好，開發麻煩小，功能更強大，老闆脫髮少。
框架

4. 那在 Electron 和 NW.js 之間，爲啥選擇前者？

我沒怎麼用過 NW.js，但當時在沒有時間深刻體驗的實際狀況下，我選擇生態好的。

Electron 相關的社區生態很好，以後的開發過程也證實了這一點，遇到的問題基本都能經過 Stackoverflow 找到，若是沒有找到，新開一個問題或者去 Github 提 Issue 均可以獲得較快的解決，除非是一些已知的問題或一些看文檔能夠解決的問題，這類問題可能會被忽略過去。

因此，生態更好一些，我選擇了 Electron。

2、Electron 入門能夠有哪幾個階段？

這一節從筆者目前有限的能力給出學習和使用 Electron 可能須要經歷的幾個階段，裏面說起的基礎的內容能夠去搜一下，有不少文章都解釋了，好比什麼是主進程，什麼是渲染進程，而一些重要的實踐是以後我會慢慢寫的，好比開發打包構建發行工做流、自動更新和升級的實現等。

3、該怎麼去閱讀和學習 Electron 的文檔

讀文檔，這回事實際上是見仁見智的，若是你看文檔有本身的三板斧，能夠不用管這一節，否則仍是建議看一下一些讀和查 Electron 文檔的建議，曾經我也「行屍走肉」般地看過 Electron 文檔，而後發現這樣效率極低，因此都是教訓啊。

1. 看文檔要結合一些別人寫的博文或代碼去看

文檔裏你不理解的，可能不少開發者已經在本身的博客裏展開解釋了，因此你若是遇到看文檔不理解的，能夠搜一些文章，結合着看，這樣你纔會理解，尤爲對於必須理解的基本概念，這很是重要。

甚至，你可能還要結合一些代碼去看。

2. 第一遍瀏覽是要理解基本概念和看到 Electron 文檔的組織方式

第一遍瀏覽，快的一個下午，慢的2天，檢查本身的成果就是搞定如下3個難題，你都能清楚地表達就能夠了：

能向不瞭解 Electron 前端開發解釋清楚 Electron 這個技術框架的特性和優點
能清楚地解釋什麼是「主進程」，什麼是「渲染進程」，各自負責什麼，怎麼通訊的
大腦中能夠清晰地浮現出 Electron 文檔的組織方式（尤爲是 API 文檔部分，是分主/渲染進程的、模塊化的 API 組織方式）

3. 第二遍看主要是看各個 API 模塊大體負責什麼

在第一遍的基礎上，第二遍看 API 文檔，腦中基本就有必定的框架了（別小看第一遍的瀏覽，這會大大提高你第二遍看的效率，也會提升之後你查文檔的效率），這個時候看文檔的目標就是讓每一個模塊在腦中有一個印象。

這個印象包括，這個模塊是在哪類進程中可用的、這個模塊負責什麼功能，有個印象就好。

由於每一個應用的不一樣，可能對於模塊的重要程度排序也會不一樣，我僅給出個人建議，你可能須要好好看的一些模塊，「好好看」的意思是，這些模塊多是很重要的，你要仔細地看：

只能在主進程使用的：

app：控制你整個 Electron 應用的生命週期
BrowserWindow：建立和控制應用的窗口
ipcMain：用於主進程中，和渲染進程通訊的
webContents：渲染和控制你窗口中的 web 內容的（由於 Electron 中，你是用 web 寫的界面）

能夠在渲染進程使用的：

ipcRenderer：用於渲染進程中，和主進程通訊的
remote：能夠方便你在渲染進程中直接調用主進程的方法
<webview> Tag：能夠載入外界的網頁

以上模塊是我以爲是須要仔細學習的第一梯隊模塊，固然也說了，每一個應用不盡相同，因此整體思路仍是知道什麼對本身重要，就重點看什麼，至於其他的，要用到的時候去查就行。

4. 查文檔

只要你已經對 Electron 有了大體的認識，你就會查文檔了，不會發生你要在渲染進程中使用的模塊，但卻直奔主進程中可用的模塊那查半天。

有一個 Tip 是，若是你是明確能夠定位的，那麼你根據你的需求去查對應模塊，若是你只有幾個關鍵字，那麼 Electron 提供把全部文檔在一個頁面內展現，這樣你就能夠用「搜索」了。

4、該如何去挑選一些 Electron 的 Demo 源碼來學習和實踐

每過一段時間，總能看到一些文章「Electron + xxx 開發 what what what」，因此咱們能夠借鑑和學習的 Demo 是不少的，可是要去挑適合本身的而且友好的 Demo 來看，而看 Demo 代碼也須要必定的方式。

1. 如何選擇第二個你要學習的 Electron Demo

怎麼沒有第一個？「Hello World」：你把我置於何地。

挑一個複雜度不要過高的（package.json簡單的通常不復雜）。這一點好理解，不解釋。
不要選擇一個代碼寫得很隨意的，可能會帶壞你。沒註釋，代碼風格清奇，這樣的仍是算了吧。
不要去跟着寫了很複雜的界面，但對 Electron 自己的使用沒幾行的 Demo，畢竟你不是來學 CSS 的。我真遇到過所謂用 Electron + XXX 開發的項目，寫了一個花哨的界面，對 Electron 的使用依舊停在「Hello World」階段。

2. 若是找到了這樣的 Electron 項目，How to play

看懂主要的代碼邏輯，看不懂的查文檔
本身去給它擴展一個功能，這裏會遇到一些頗有趣的事，好比你以爲應該簡單的，結果你花了好久都沒搞定，正常的，因此建議擴展一個和 Demo 中已有功能相似的功能，那樣你能夠直接參考了。

3. 等有了本身要開發的應用後，再去看別人的 Demo 是看什麼？

直到目前，我仍是會常常看一些其餘的 Electron Demo 或者已能夠稱爲產品的應用，這個時候我不可再事無鉅細地去看整個應用的代碼，而是明確知道我要去看什麼。

舉個栗子，在開發實際應用一段時間後，我以爲咱們的 Electron 應用，從開發到打包，再到構建安裝包，最後到發行，整個開發工做流效率低下，很不流暢，這個時候我就去看不少的項目，借鑑不少的優秀實踐，感謝他們。在那個時候，我就會只看他們是怎麼組織整個工程的，是怎麼劃分開發的各個階段的，又是如何讓整個流程流暢地自動化的。

到後來，須要實現「自動更新」功能的時候，我又去看一些實現了自動更新的應用和 Demo，看他們是怎麼實現的，最終結合咱們本身的需求實現了「分強弱的自動更新」功能。

因此在有了本身要開發的產品後，看 Electron 應用的代碼，就是帶着訴求去看的，這一步對優化本身的產品很重要。