青娱乐手机在线视频,欧美日本国产,亚洲变态另类,男人日逼式看,在线成人自拍,AAA久久久,射了好多别动哦初恋哥vs,探花熟女

???這是第?63?篇不摻水的原創(chuàng)，想要了解更多，請戳上方藍色字體：政采云前端團隊?關注我們吧～

本文首發(fā)于政采云前端團隊博客：如何基于 Electron 開發(fā)跨終端的應用
https://www.zoo.team/article/the-application-of-electron

自我介紹

歡迎大家來到今天的早早聊跨端跨棧專場，今天我分享的主題是《如何基于 Electron 開發(fā)跨終端的應用》。先做一下自我介紹，我叫逯子洋，17 年加入政采云，目前主要負責政采云前端工程化平臺敦煌以及政采云電子招投標客戶端的建設。這邊是我們團隊的微信公眾號，大家如果想對我們團隊有更多的了解，可以關注一下我們的公眾號。

首先我們分享的第一塊叫端的延展。不知道大家對這張圖熟不熟悉，前段時間的新聞大家應該都聽到過，硅谷鋼鐵俠艾隆馬斯克發(fā)布了第一款商業(yè)化的載人龍飛船，這張圖片中就是龍飛船的控制臺，知乎上有人對這張圖的評價叫 JS 上天了。為什么說叫 JS 上天了呢？因為有傳言說它是基于 Electron 開發(fā)的，不過這個消息并沒有得到證實。但是可以證實的一點是航天飛船的觸控界面 UI ，確實是基于 Chromium + JavaScript 這樣的架構(gòu)來實現(xiàn)的。這也從某種程度上說明了這種架構(gòu)的一個可用性和穩(wěn)定性的能力。

下面我們一起來回顧一下前端在整個端領域的發(fā)展歷程。在早期，前端工程師的定義可能是基于瀏覽器運行環(huán)境的 Web 開發(fā)，但是隨著 09 年 Node.js 的出現(xiàn)，讓前端工程師有了脫離瀏覽器運行環(huán)境的開發(fā)能力。我們擁有了可以面向服務端開發(fā)的能力，前端的能力延展到了服務端。

隨著 HTML5 標準的制定，以及移動端設備技術的發(fā)展，前端工程師也可以更多的擁抱面向移動端場景的開發(fā)。也出現(xiàn)了像今天上午兩位講師所講到的移動端領域 React Native 這樣的跨平臺技術方案。隨著移動 APP 成為一個主流，基于這些智能化的設備以及芯片的計算能力，前端也普及到了物聯(lián)網(wǎng)設備方向，前端可以擁有了面向 Iot 的開發(fā)能力，也誕生了像 Thing.js ?這樣的面向物聯(lián)網(wǎng)設備開發(fā)的 Js 框架。

CLI -> GUI

今天所要講的主題是桌面端，隨著 Electron 這樣的跨終端 JS 框架的出現(xiàn)，整個前端工程師的能力也是延展到了桌面端。當我們擁有了這樣的一個桌面端的開發(fā)能力之后，它能帶給我們的價值是什么呢？首先看一下桌面端給我們帶來哪些不一樣的體驗。大家看到左邊這張圖，是早期電腦的 DOS 系統(tǒng)的運行的截圖，右邊則是 1983 年蘋果電腦發(fā)布的第一款 Apple Lisa 個人電腦，它是全球第一款搭載圖形用戶界面（也就是我們所說的 GUI）的一臺個人電腦，正是因為這款電腦的問世，讓后期個人電腦大眾化的普及得以實現(xiàn)。為什么它會帶動個人電腦的普及化，是因為圖形界面對于用戶來說，在視覺上更容易接受，學習的成本也是大幅的下降。相信用過 MAC 系統(tǒng)的同學都會對蘋果優(yōu)秀的界面設計以及整體的交互體驗，有比較深刻的感受。

那么，這樣的桌面端 GUI 的技術，能給我的前端開發(fā)工作帶來什么不一樣呢？

左邊這個流程相信大家不陌生，在我們開始新項目開發(fā)的時候，可能需要做哪些事情？首先第一步可能是需要去創(chuàng)建一個 Git 倉庫，創(chuàng)建完成之后將倉庫克隆到本地，然后通過團隊內(nèi)部的 CLI 工具的安裝之后，去執(zhí)行例如 xxx-cli create 這樣的命令去創(chuàng)建一個項目。創(chuàng)建項目完成之后，如果想進行開發(fā)，我們需要去運行 npm install ，安裝所需的依賴包，最終將整個項目提交到 Git 倉庫上去。這是我們新項目的創(chuàng)建，基于 CLI 方式的一個操作流程。

如果說基于客戶端的能力的，我們可以做哪些改變呢？我們可以看到，右邊的圖是我們團隊前端工程化平臺敦煌的系統(tǒng)截圖。如果是創(chuàng)建一個新項目，只需要選擇自己的創(chuàng)建方式，然后輸入一些必要的創(chuàng)建參數(shù)，比如說選擇你需要創(chuàng)建的 Git 倉庫 Group、項目名稱、腳手架類型，點擊創(chuàng)建項目之后，它會自動幫你將左邊的這一系列的流程全部執(zhí)行完畢。就是說將左邊 6 個步驟簡化到了 2 個步驟，大大的簡化了操作的鏈路。

GUI 賦予的價值

GUI 賦予了我們哪些價值呢？首先它可以將分散的任務點進行一個串聯(lián)整合，提供了一個更簡化的操作鏈路，同時它還可以抹平不同同學使用時一些流程間的差異，以及流程所依賴的一些環(huán)境的差異，并且基于 GUI 的一個整合能力，我們還可以將其他能力進行一個橫向的串通，并且通過 GUI 來設計插件化的機制，還可以創(chuàng)造一個可共建的生態(tài)。同時基于 GUI 的圖形界面操作低學習成本，以及它對整個流程的托管，也是可以大大的降低團隊同學的研發(fā)復雜度。

業(yè)務場景應用

下面是基于 Electron 開發(fā)的一些重點應用的落地場景。這是我所負責的政采云電子招投標客戶端的業(yè)務。它主要的功能是幫助用戶由傳統(tǒng)的線下招投標，紙質(zhì)的標書，轉(zhuǎn)變?yōu)殡娮訕藭?，我們提供這樣的客戶端可以幫助用戶串聯(lián)整個制作標書的流程。同時基于 Electron 所提供的 Node.js 的能力，用戶本地標書文件的讀寫，以及本地文件的加解密操作，都可以在客戶端里面完成。

基建場景應用

這邊是 Electron 在我們的工程化平臺上的實踐，這就是我們前面所提到的前端工程化平臺-敦煌。它主要做的內(nèi)容是對整個前端研發(fā)流程的托管，像我們剛才所提到的項目創(chuàng)建就是其中的一個環(huán)節(jié)。下面我們還會詳細的介紹一些這方面的應用。

開發(fā)模式

上面我們大概介紹了一下 Electron 的一些價值。如果說我們想基于 Electron 開發(fā)一個跨平臺的桌面端應用，應該如何來做？下面一起來看一下，第二部分：開發(fā)模式。Electron 的開發(fā)模式跟我們平時的 Web 開發(fā)有哪些不一樣的地方？

Electron 架構(gòu)

首先這是 Electron 的一個整體的架構(gòu)，它是由 Github 開發(fā)了一個開源框架，允許我們使用來 HTML + CSS + Javascript 來構(gòu)建開發(fā)桌面應用，大大降低了桌面應用的開發(fā)的復雜度。整體架構(gòu)的核心組成是由 Chromium + Node.js + Native APIs 組成的。其中 Chromium 提供了 UI 的能力，Node.js 讓 Electron 有了底層操作的能力，Navtive APIs 則解決了跨平臺的一些問題，比如說 Windows 系統(tǒng)、MAC OS 系統(tǒng)及 Linux 系統(tǒng)之前一些差異的屏蔽，并且它還提供了一個比較統(tǒng)一體驗的原生能力。

能力點

我們來介紹一下它的一些核心的能力點。

首先是 Chromium，我們可以把它理解為是一個擁有最新版瀏覽器特性的一個 Chrome 瀏覽器，它帶給我們的好處就是在開發(fā)過程中無需考慮瀏覽器的兼容性，我們可以使用一些 ES6、ES7 最新的語法，可以放心的使用 Flex 布局，以及瀏覽器的最新特性，都可以嘗試，不需要考慮兼容性的問題。
Node.js 則是提供了一個文件讀寫、本地命令調(diào)用、以及第三方擴展的能力，并且基于 Node.js 整個強大的生態(tài)，將近幾十萬的 Node.js 模塊都可以在整個客戶端內(nèi)使用。
Native APIs 提供了一個統(tǒng)一的原生界面的能力，還包括一些系統(tǒng)通知、快捷鍵，還可以通過它來獲取一些系統(tǒng)的硬件信息。還提供了桌面客戶端的基礎能力，像更新機制、崩潰報告這樣的能力。

其他桌面端選型對比

Electron 提供這些能力點大大的降低了桌面端開發(fā)的成本，以及上手的門檻。當然開發(fā)桌面端的話，除了 Electron 外，還會有一些其他的選型，我們看一下它跟其他的選型相比較的話有哪些差異點。

開發(fā)桌面端首先可以選擇 Native 開發(fā)，但是，在開發(fā)不同的平臺的時候，需要使用不同的語言，但它的優(yōu)點是具有比較好的原生體驗，以及比較好的運行性能，但是它的門檻相對來說還是比較高的。
QT 是一個基于 C++ 的跨平臺桌面端開發(fā)框架，它所使用的語言是使用 C++，整體性能和體驗上來說，跟Native 開發(fā)的話是可以相媲美的，但由于技術棧原因，開發(fā)門檻相對來說也是比較高的。
另外兩個就是 Electron 和 NW.js。這兩個都是使用 Javascript 作為一個開發(fā)語言。相較于 Native 和 QT 來說，它們對前端工程師來說是相當友好的，并且它們兩個有著比較相似的一個架構(gòu)，都是基于 Chromium + Node.js 實現(xiàn)，同時它們也都有一個跨平臺的支持能力。但兩個的差異點是：Electron 相對來說有一個更好的一個社區(qū)的生態(tài)和社區(qū)的活躍度，我們平時如果遇到了一些問題，在社區(qū)內(nèi)可能會有比較多、比較完善的解決方案，同時它對 issue 的響應速度也是比較快的。

所以基于上面的比較，開發(fā)桌面客戶端，對前端工程師來說，Electron 是一個非常好的選擇。

簡單 Electron 應用的結(jié)構(gòu)

下面來看一下，如果想開發(fā)一個桌面客戶端，應該怎么做呢？這邊是一個最簡單的 Electron 桌面應用的結(jié)構(gòu)，我們只需要有三個文件，首先我們通過 package.json 中的 main 字段，通過 main 字段來定義應用的一個啟動入口。我們將入口文件定義為 main.js ，在 mian.js 里我們做了哪些事情呢？首先 app 代表著整個應用，監(jiān)聽 app 的狀態(tài)，當整個應用達到一個 ready 的狀態(tài)之后，通過 Electron 提供的 BrowserWindow ，去新創(chuàng)建一個瀏覽器窗口。創(chuàng)建瀏覽器窗口之后，去加載 index.html 文件，這樣的話我們就完成了一個最基礎版桌面端應用的實現(xiàn)。基于 Electron 開發(fā)桌面端應用，和平時的開發(fā) web 端應用有哪些不一樣的，我們需要了解的兩個核心概念就是：主進程和渲染進程，以及兩個進程間的通信如何實現(xiàn)。在剛才的示例中，其中 main.js 是運行在主進程中， index.html 則是運行在渲染進程之中。下面我們通過一個簡單的 Demo，來看一下如何實現(xiàn)兩個進程之間的通信，并且如何通過主進程來進行一些 Node.js 能力調(diào)用的。

進程間的通信

我們想要實現(xiàn)這樣的效果，頁面上有一個按鈕，當點擊按鈕之后，向主進程發(fā)送了一個 say-hello 的消息，當主進程接收到消息之后，它會在系統(tǒng)桌面上創(chuàng)建一個文件叫 hello.txt。并寫入內(nèi)容 Hello Mac!。具體的我們是怎么做的？

首先在渲染進程里面，我們應該在頁面上會進行一個按鈕操作事件，當事件觸發(fā)之后，我們通過 Electron 提供的 ipcRenderer ?API 向主進程發(fā)送一個叫 say-hello 這樣的一個消息。當我們的主進程接收到這樣一個消息之后，則可以在主進程中直接調(diào)用 Node.js 的 fs 模塊，一個文件讀寫的模塊。首先先創(chuàng)建一個文件，并且對這個文件寫入我們所傳輸?shù)膬?nèi)容。當文件寫入成功之后，對渲染進程進行回復，通過調(diào)用 Electron 提供的 Notification模塊，顯示系統(tǒng)通知去告知用戶，這是一個簡單的 Demo 的實現(xiàn)，其核心的點就是需要關注主進程和渲染進程的概念，以及兩個進程之間是如何通過 IPC 機制進行通信的，這邊是一個簡單的實現(xiàn)。還有一些更多的應用的場景，這塊就不再對 API 進行過多的介紹。

下面我們會根據(jù)一個實際的應用，來介紹一下 Electron 開發(fā)的實踐。

工程化發(fā)展 CLI -> GUI

以我們的前端工程化平臺敦煌為例，介紹一下我們是如何通過 Electron 將工程化能力由 CLI 式變?yōu)?GUI 式的使用。首先大家先看一個視頻，這個視頻就是我們在最開始所提到的項目創(chuàng)建的整個流程的運行的演示。大家可以看到我們整個流程完成了 Git 倉庫的創(chuàng)建、項目模板的創(chuàng)建、項目模板到倉庫的推送，并且對 Git 項目進行本地克隆，克隆完成之后，會進行依賴的安裝，并且在客戶端進行重新載入和管理這樣一個流程。將之前分散的單點命令操作，通過 GUI 的方式進行一個串聯(lián)。這個流程只是工程化平臺中的一塊，我們在整個工程化平臺中，實現(xiàn)了很多的單點命令到工作流的串聯(lián)。

I2P（Install To Publish）

這邊是我們整個前端應用管理平臺的系統(tǒng)架構(gòu)，大概看一下。核心流程就是上面所寫到的一個 I2P 的概念，就是 install to publish 。它完成了組件、模板和項目這三個級別，從創(chuàng)建到發(fā)布的全流程托管。

創(chuàng)建階段，主要提供了包括本地創(chuàng)建、Git 創(chuàng)建、統(tǒng)一的創(chuàng)建模板管理、創(chuàng)建的流程審批和創(chuàng)建完成的反饋。
開發(fā)階段，提供了一個 Dev Server 的運行能力，對項目級的頁面管理、依賴管理、分支管理，還有一鍵式的升級能力。同時還打通了 CI/CD 持續(xù)集成能力。
發(fā)布階段，則提供了一個發(fā)布前的權(quán)限校驗和合規(guī)檢測、資源推送以及發(fā)布的審批機制。
數(shù)據(jù)分析，是我們整個流程中比較核心的一塊，是對我們整個流程進行一些數(shù)據(jù)沉淀，并且將這些數(shù)據(jù)以可視化報表的形式進行成輸出，基于這些數(shù)據(jù)將整個 I2P 的流程與其他的能力進行一個串聯(lián)。

在上面的整個 I2P 的流程中，我們沉淀出一些項目數(shù)據(jù)，包括流程數(shù)據(jù)，可能還有一些類似于組件管理的數(shù)據(jù)。以數(shù)據(jù)為連接點，可以將整個的研發(fā)流程與其他的一些技術建設能力進行一個串聯(lián)打通，包括用戶行為分析、頁面級、項目級的性能分析報告，還有錯誤監(jiān)控的機制，都可以接入到整個工程化平臺上。支撐我們整個工程化平臺就是一些基礎能力以及 Electron 所提供的桌面端能力。基礎能力，包括一些常規(guī)的 GIt 操作、NPM 操作、一些命令執(zhí)行和一些本地的 logger 服務。Electron 提供了桌面端包括更新、窗口管理、通信，以及些原生能力。

由點到線

單點命令 -> 任務流

下面我們就具體來看一下如何實現(xiàn)由一個單點命令到任務流這樣的一個串聯(lián)。將單點命令的操作變?yōu)槿蝿樟鞯拇?lián)模式，我們要從以下 4 個切入點來實現(xiàn)。

? 首先我們要將常規(guī)的一些命令調(diào)用變?yōu)楹瘮?shù)式的調(diào)用。

? 基于這些函數(shù)式的調(diào)用，進行一個任務流的編排和組裝，根據(jù)實際的開發(fā)場景，去定制一個任務流。

? 第三塊我們所需要的是整個任務流的任務進度反饋機制，如何將任務執(zhí)行，通過 GUI 的能力，讓用戶可以直觀感受到整個任務的執(zhí)行鏈路和進度。

? 最后，在整個任務流中，很重要的一塊就是對整個流程的數(shù)據(jù)收集。

流程的設計

下面是我們剛才所演示的項目創(chuàng)建流程的架構(gòu)設計。當我們在調(diào)用項目創(chuàng)建模塊的時候，首先會通過 Server 接口，去創(chuàng)建 Git 項目。先對整個用戶的權(quán)限做一層校驗，校驗通過之后，通過調(diào)用 Gitlab API，進行一個倉庫的創(chuàng)建，之后，根據(jù)所選用的模板信息拉取統(tǒng)一維護的項目模板，根據(jù)用戶所輸?shù)捻椖棵Q、項目描述等信息，來生成真正的項目文件，調(diào)用 Gitlab API 將整個項目文件推送到創(chuàng)建好的倉庫。關于 Gitlab API 的使用這一塊，在掘金上有進行過文章的分享，大家感興趣的話可以去了解一下，這邊就不再進行詳細的闡述。在我們整個服務端完成了一系列的 Git 創(chuàng)建操作之后，會將創(chuàng)建成功的倉庫 url，給到我們的桌面端，桌面端接收到這樣創(chuàng)建成功的任務結(jié)果之后，開始執(zhí)行一些本地操作的任務流程。將 Git 倉庫克隆到本地的工作區(qū)內(nèi)，同時完成整個項目的依賴安裝。在依賴安裝之后，我們會借助桌面端的通知能力，包括釘釘?shù)慕涌谌ネ瓿赏ㄖ头答?。其中克隆、依賴的安裝以及通知反饋是在我們桌面端的主進程內(nèi)完成的。在我們整個任務流中，它有實時與渲染進程的消息反饋。我們會將整個任務的進度，包括命令執(zhí)行的日志輸出、命令執(zhí)行結(jié)果，通過 IPC 的方式實時的與渲染進行通信，最終在界面上給到用戶反饋。在整個流程中，也會對項目數(shù)據(jù)和流程數(shù)據(jù)進行存儲。

實現(xiàn)這樣的整個流程，在實踐上有哪些是需要說的呢，下面我們來看一下具體的代碼。

npm install 變?yōu)?npm.install()

首先在進行命令調(diào)用的時候，要將 npm install 這樣一個命令行的調(diào)用方式變成變?yōu)橐粋€函數(shù)式的調(diào)用，會變?yōu)?npm.install() 這樣一個調(diào)用方式。

git init 變?yōu)?git.init()

類似 Git 的命令，也會變成函數(shù)式調(diào)用

將命令式執(zhí)行 Promise 化

下面我們看一下，具體場景，如何將命令式調(diào)用變成函數(shù)式調(diào)用。首先是將命令執(zhí)行 Promise 化。例如 git init 這樣的操作，在執(zhí)行整個命令的時候，我們更多關心的是整個命令執(zhí)行的結(jié)果，可能不太會關心命令執(zhí)行過程中的一些輸出的內(nèi)容。這樣的話我們就可以通過 Node.js 中的 spawn ，啟動子進程來執(zhí)行命令。通過監(jiān)聽子進程輸出來判斷我們整個命令的執(zhí)行狀態(tài)，然后對整個命令進行 Promise 封裝，我們就完成了 git init 這樣一個命令行調(diào)用變?yōu)?git.init() 這樣一個異步的函數(shù)調(diào)用。

實時輸出命令執(zhí)行日志

在另外一個場景，比如說 npm install ，依賴安裝，或者說啟動本地開發(fā)服務，整個命令的執(zhí)行過程可能會比較長，我們更關注的是過程中實時的日志輸出。我們怎么來做呢？首先我們這邊是先創(chuàng)建一個 EventEmitter 實例，作為我們的日志的分發(fā)管理，同樣的我們也是通過 spwan 來啟動一個子進程來執(zhí)行命令，并且實時的監(jiān)聽子進程的輸出，將輸出的日志通過 emitter 實例將它分發(fā)出去。當我們在主進程中拿到這樣的實時日志輸出之后，可以通過 Electron 主進程跟渲染進程間的 IPC 的通信，將日志實時的輸出到渲染進程當中。

將命令式調(diào)用變?yōu)楹瘮?shù)式調(diào)用，有了這樣的能力之后，就可以通過對這些函數(shù)的調(diào)用，進行任務流的編排。例如剛才我們所提到的項目創(chuàng)建，這可能是一個比較通用的流程，還有組件管理、模板管理和以及項目發(fā)布等。大家可以根據(jù)自己實際的業(yè)務需要，來去編排自己一個任務流。

模擬終端：反饋任務進度

上面我們提到的是主進程中對整個命令執(zhí)行方式的一些改變。那么在我們的渲染進程當中，我們要怎樣去實現(xiàn)類似于剛才視頻中的終端日志反饋呢？反饋的方式有很多，我們可以通過設計一些任務的步驟條，或者進度條這樣的方式來給予整個任務進度的反饋。但是更好的方式是我們可以把任務的進度，包括整個任務輸出日志進行一個及時的反饋。這邊我們使用的是 xterm.js。它是一個基于 ts 所編寫的一個前端終端組件，可以在瀏覽器內(nèi)實現(xiàn)終端應用，VsCode 也是基于 xterm.js 來實現(xiàn)的終端的。要如何將主進程的日志來輸出到渲染進程當中，就是我們上面所提到的，在拿到一個 EventEmitter 所廣播的的輸出之后，要通過主進程與渲染進程之間的通信，將數(shù)據(jù)推送到渲染進程，在渲染進程所需要做的一個處理，把接受到的命令輸出，實時的渲染到 xterm 實現(xiàn)的終端組件上面來。

這樣的話我們就完成了整個任務流的反饋機制。

以上就是我們在工程化平臺中一個任務流的實現(xiàn)，借助于 Electron 能力，我們就可以很方便的實現(xiàn)整個流程任務的編排，以及實現(xiàn)對應流程的界面交互，對整個流程進行簡化。除了任務流的實現(xiàn)之外，我們更多需要關注的是整個過程中的數(shù)據(jù)收集，包括流程數(shù)據(jù)以及流程中創(chuàng)建的項目、組件數(shù)據(jù)沉淀，也包括流程當中一些異常數(shù)據(jù)，因為這些數(shù)據(jù)是將流程與其他的基礎建設能力進行打通的基礎，同時也能讓我們對整個流程持續(xù)的優(yōu)化，

更新

在完成客戶端的開發(fā)之后，需要考慮的則是后續(xù)的更新，一起來看一下，我們?nèi)绾螌崿F(xiàn)客戶端的自動更新的功能。

Electron 提供了一套比較完善的打包更新機制。

通過 Election-builder 把我們的應用構(gòu)建之后，會輸出一個 latest-mac.yml 文件，以及應用的 zip 包，將這兩個文件放到更新服務器上，更新服務器的實現(xiàn)方案有很多，我們選用的是 CDN 來做為更新服務器。我們?nèi)绾稳ピO計整個更新的流程，在渲染進程內(nèi)，一般會提供手動檢測更新的觸發(fā)入口，或者通過輪詢?nèi)蝿?，來定時進行版本更新檢測。渲染進程發(fā)起版本檢測求之后，會在渲染進程內(nèi)調(diào)用 ?autoUpdater 模塊，它是 Electron 內(nèi)置的更新管理模塊。首先需要設置 feedUrl，就是最新的更新包在更新服務端地址。當收到一個渲染進程的版本檢測請求之后，調(diào)用 checkForUpdates 方法，之后，它會觸發(fā)下面一系列的一些事件，我們可以通過對整個更新事件的各個生命周期的監(jiān)聽，來完成整個更新流程的把控。

通過 Electron 內(nèi)置的一個更新機制要面臨的問題是更新包體積比較大。因為我們通過 Electron 所構(gòu)建的桌面端的應用，它將整個 Chromium 進行了集成，就會導致即使我們寫了一個很小的 Hello world 這樣一個應用，它的體積壓縮后也會有 40MB 左右，常規(guī)的一個應用來說可能占用 100MB 左右。這樣的問題就是有一些比較小的改動的時候，就需要全量的更新，對于用戶的一個體驗來說并不是很好，對于這些我們有哪些解決方案？首先我們是可以對整個更新的交互設計上做一個優(yōu)化。我們需要提供的是對整個更新流程的一個進度反饋，另外一點就是我們可以通過 autoUpdater，實現(xiàn)后臺的下載。當我們完成了整個更新包的下載之后，然后再通知用戶對整個應用進行一個重啟，然后更新整個應用，這樣的話就才從交互層面上，一定程度的避免了增量更新對用戶所體驗上的一些影響。當然全量更新還會存在的一個問題，如果用戶量比較大的話，就會比較浪費網(wǎng)絡資源。

增量發(fā)布

下面是我們的一些在增量發(fā)布上面的一些實踐。首先對整個 Renderer 層的靜態(tài)資源進行 CDN 托管。對于我們整個應用，不會將 Renderer 層的靜態(tài)資源打包到最終的桌面端程序內(nèi)，將資源遠程托管，同時我們根據(jù)一些特定的業(yè)務場景，可以利用 service worker 能力，對整個資源做一個離線緩存，并且對靜態(tài)資源做版本控制。

更新流程

Renderer 層的一個更新流程是這樣的，當頁面發(fā)請求的時候，首先會匹配本地有沒有這樣的一個資源的緩存，如果我們匹配到資源，就會返回匹配到的結(jié)果。如果說本地沒有匹配到的話，就重新請求最新資源，同時將請求的資源進行緩存。如果說在整個請求的過程中出現(xiàn)了錯誤，需要有一個可使用的默認版本的資源，并且將錯誤進行上報。這里我們所實現(xiàn)的一個是基于 UI 層的一個增量更新。實際的業(yè)務場景，需要根據(jù)不同資源的更新頻率，來決定應該是進行更新的體驗優(yōu)化，還是使用 UI 層增量更新，或者安裝包的增量更新。

敦煌工程化平臺技術架構(gòu)圖

這邊是整個應用管理平臺的架構(gòu)，在我們的整個工程實踐中，除了實現(xiàn)了對整個項目、組件還有模板的 I2P 全流程托管之外，我們還提供了其他能力，例如團隊入口的收斂，包括文檔入口，輸出入口，同時還將團隊內(nèi)部的一些工具進行一個整合，將一些分散在各個地方的一些工具，比如說文檔站點生成工具、圖床工具，iconfont 管理工具進行了一個整合，同時我們還對整個客戶端的用戶行為數(shù)據(jù)做了采集，通過數(shù)據(jù)分析來持續(xù)迭代。

QA

“
請問子洋：如何進行熱更新呢？據(jù)我了解 Electron 打包出來的頁面是放在包內(nèi)的，如何進行在線更新？

我理解問題應該是 UI 層界面的更新。其實剛才我有提到過，我們對頁面的一些靜態(tài)資源是做了一個 cdn 上的托管，在更新的時候，會有一個檢測更新的機制，它可以通過輪詢或者服務端推送來實現(xiàn)，當收到靜態(tài)資源版本更新的通知，通過主進程對渲染進程進行一個忽略緩存的強制刷新，或者說可以通過在主進程有相應的交互，包括升級提醒和更新日志，讓用戶觸發(fā)頁面重載，去更新 UI 層面的靜態(tài)資源。

“
請問子洋：Electron 和 NW.js 的區(qū)別能請您對比一下嗎？

它們兩個最大的區(qū)別是在于對 Node.js 和 Chromium 事件循環(huán)機制的整合的處理方式是不一樣的。首先 NW.js 是通過修改源碼的方式，讓 Chromium 與 Node.js 的事件循環(huán)機制進行打通；Electron 實現(xiàn)的機制是通過啟用一個新的安全線程，在 Node.js 和 Chromium 之間做事件轉(zhuǎn)發(fā)，這樣來實現(xiàn)兩者的打通。這樣的一個好處就是 Chromium 和 Node.js 的事件循環(huán)機制不會有這么強的耦合。另外的區(qū)別則是 NW.js 支持 xp 系統(tǒng)，Electron 是不支持的。相比較而言 Electron 有著更活躍的社區(qū)，以及更多的大型應用如 VS code、Atom 的實踐案例，更多的區(qū)別可以參考 Electron 官方的一篇介紹：www.electronjs.org/docs/develo…

“
請問子洋：更新包的文件是放在私有文件服務器還是 Gitlab 或者 Github 上面？

有比較多方式，我們的實現(xiàn)是通過 CDN 的托管，也可以通過 Github 或者私有文件服務器的搭建來實現(xiàn)。根據(jù)自己實際的業(yè)務場景和技術棧來選擇。

推薦閱讀

我的公眾號能帶來什么價值？(文末有送書規(guī)則，一定要看)

每個前端工程師都應該了解的圖片知識(長文建議收藏)

為什么現(xiàn)在面試總是面試造火箭？

如何基于 Electron 開發(fā)跨終端的應用