零、electron 簡介

1. 歷史：Atom 編輯器衍生出的 Atom Shell，后更名為 Electron
2. 可以跨 Linux、Mac、Win7-8 平臺開發(fā)桌面程序
   「寫本文時，electron 版本為 1.6.2，electron 并不支持 win10」
3. 使用網(wǎng)頁開發(fā)的形式，加速了開發(fā)效率，但在性能操作上表現(xiàn)欠佳
   「實質(zhì)上僅用了 Webkit 瀏覽器內(nèi)核的殼子套了開發(fā)者的代碼，可以直接做瀏覽器用」
4. 打包軟件一般 安裝包 40M 起步，軟件體積 100M 起步

一、electron 的布局

I. 文件布局

1. 源代碼布局

app/             // 名稱固定，方便 electron 取文件
├── package.json // 程序的名稱、簡介、版本等信息 ，程序的編譯，打包腳本等
├── main.js      // 程序運行唯一入口，可以在 package.json 修改入口文件
└── index.html   // 網(wǎng)頁主頁

2. electron 打包后程序的文件存放

resources/         // 程序根目錄下的文件
├── app/           // 編寫的源代碼「可選，Mac 中在打包后直接省略了該部分」
└── electron.asar  // 源代碼 經(jīng)過 asar 打包壓縮后生成的 程序需要引用文件「必須」

II. 運行方式

1. 依托 NodeJS 構(gòu)建的獨立服務(wù)器獲取系統(tǒng)資源
2. 以唯一的 main.js 作為主進程，網(wǎng)頁的渲染作為其多個子進程
3. 頁面和主線程之間的交流：通過 ipcMain「主」 和 ipcRenderer 「頁面」互相廣播交流
4. 頁面之間的交流：可以通過在主線程廣播轉(zhuǎn)發(fā)給頁面

• 過多使用通過廣播發(fā)送信息，會導(dǎo)致程序的卡頓
  建議使用一個廣播，而用參數(shù)作為消息類型的判斷
• 每個窗口都是一個進程，開啟過多的窗口會造成巨大的卡頓

// 減少過多廣播的方法
ipcMain.on(gc.message, function (event, type, ...arg) {
    switch (type){
        case gc.msgMainLog:
            log(...arg);
            break;
        case gc.msgOpenEffect:
            CreateWindow.openEffect(event.sender, ...arg);
            break;
        case gc.msgAddSequence:
            CreateWindow.addSeq(event.sender, ...arg);
            break;
        case gc.msgAddPlist:
            CreateWindow.addPlist(event.sender, ...arg);
            break;
    }
});

二、electron 的不足

1. 性能：canvas 標(biāo)簽使用 17個左右 就開始內(nèi)存緊張，循環(huán)利用
2. 官網(wǎng)未能提供一個 即可以記錄渲染線程，又可以記錄主線程的 log
   好在 Github 上從不缺少這樣的 東西
3. 在搭配使用 React 時，不能在 electron 的 index.html 中直接引用的 CSS 內(nèi)引用資源，哪怕是相對路徑的連接也不行
   解決方法：

• 把 CSS 寫入 React，而不是單獨在 index.html 中引用
• 把 CSS 引用的資源編譯成 base64 寫入到 CSS 文件中
  「不過 引用資源過大會造成 CSS 的加載更慢」

由于 React 在編譯打包的時候，會把 CSS 引用資源的鏈接轉(zhuǎn)化為絕對路徑
打包后，程序由于絕對路徑的原因，只能在開發(fā)的機子上使用，分發(fā)給他人后，會造成資源缺失的問題