Electron,從玩玩具的心態開始,到打造出一款越來越優秀的桌面客戶端產品 —— 一份不是「Hello Word」的吊胃口的Quick Start

首發于酷家樂前端博客

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

這是該系列的第一篇,我也是邊學邊做邊反思,歡迎交流,哦,不用擔心我會「太監」這個系列文章,因為我的老大握著40米大刀注視著我,不定期出下一篇(間隔最大不超3周)。

Electron

// 以下是單口相聲,從第一視角講我是怎么接觸到 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」將依次介紹以下內容:

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

本文不會具體說怎么起一個 Demo 去「Quick Start」,這完全可以在官網找到,也有很多文章寫了,我只是就自己的經歷去給出一些有限的建議,給有興趣的朋友一個合理的入門參考,很多時候,當我們實踐完「Hello world」后,我們就不知道怎么辦了,于是熱情就只能冰封在「Hello world」階段了,下面這個笑話不是想要的結果。

四步開發VScode
四步開發VScode

一、是什么讓 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 項目一般,開發構建流程可以引入很多成熟的包去打造出適合自己項目的開發工作流,另一個方面就是其應用本身也可以依賴需要的包去完成自己的功能,之后的文章我們會展開詳細說。

3. 這個東西網站也可以為什么需要客戶端?

既然 Electron 是用 Web 技術寫客戶端,那么看上去 Electron 要做的事,可以搬到網站上,為什么還要搬到客戶端,這里有3個角度的回答:

  • 用戶角度: 客戶端是一款獨立的軟件,其綜合體驗一般都是比網站高的,尤其是涉及到「工具」范疇的應用,此外,特定的用戶群體也會有類似的使用習慣
  • 發行方角度: 客戶端是另一種產品形式,是一種產品的分發方式和入口,客戶端可以實現很多本地應用獨有的需求去觸達用戶,也能提供更加可靠的服務
  • 開發角度: 終于...不用考慮瀏覽器兼容了,Chromium 也足夠開發使用一些先進的 CSS 或 JS 特性,我們現在還沒計劃引入 webpack 和 babel,因為現在好像夠用,克制才是愛,除了寫起來爽,對于開發來說,終于跳出了瀏覽器的沙盒,你可以自己去控制 Electron 中的「瀏覽器」,莫名的開心

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

4. 那在 Electron 和 NW.js 之間,為啥選擇前者?

我沒怎么用過 NW.js,但當時在沒有時間深入體驗的實際情況下,我選擇生態好的。

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

所以,生態更好一些,我選擇了 Electron。

二、Electron 入門可以有哪幾個階段?

這一節從筆者目前有限的能力給出學習和使用 Electron 可能需要經歷的幾個階段,里面提及的基礎的內容可以去搜一下,有很多文章都解釋了,比如什么是主進程,什么是渲染進程,而一些重要的實踐是之后我會慢慢寫的,比如開發打包構建發行工作流、自動更新和升級的實現等。

Electron 入門階段

三、該怎么去閱讀和學習 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 提供把所有文檔在一個頁面內展示,這樣你就可以用「搜索」了。

四、該如何去挑選一些 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 應用的代碼,就是帶著訴求去看的,這一步對優化自己的產品很重要

五、之后的該系列文章會涉及到哪些功能或主題(吊個胃口)

以上是我對于想入坑的「坑友」們分享的一些「入坑正確姿勢」,姿勢不對,容易折啊。可以看到這整篇文字沒啥具體的實踐,但作為一個開發了一段時間產品的前端,這是我認為很重要的一些方式方法。

在之后的一系列文章中,我將介紹以下內容(確定了一定會寫的):

  • 怎么打造自己的開發工作流:從源代碼到一個安裝程序,我們怎么自動化這個流程
  • 自動更新:我們怎么考慮自動更新,為什么需要分強弱級別的自動更新,有什么區別,怎么實現
  • 如何給自己的應用加入測試版功能,以提供一些方便測試的功能
  • 怎么做客戶端能做但瀏覽器為難的消息推送
  • ... ...

任重道遠,歡迎交流,以上內容轉載請標明原文鏈接和作者。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容