背景

公司需要做一個同步盤的客戶端，框架技術選型方面使用了支援跨平臺的Electron框架，其中一些核心功能就是檔案的上傳，和下載，考慮到node操作檔案比較方便，起初把檔案的下載上傳操作放到主程序，在大量檔案下載和上傳時，造成了介面的卡頓，現在就這個問題進行剖析和優化。

解決卡頓

方案一

首先要確定是什麼因素導致的卡頓，在平時，沒有上傳下載檔案時，electron客戶端沒有出現卡頓的情況，然後對下載的流程進行跟蹤，通過列印log日記發現，在執行一個方法後後面的log無法輸出，然後介面失去了響應，其程式碼如下

const  parentExist = (rpath: string) => {
const  root = store.get("syncPath") as  string;
let  parent = path.parse(rpath).dir.replaceAll("\\", "/");
let  localFilePath = path.join(root, parent);
let  isFalse = parent !== "/";
const  dirs = [];
try {
while (!fs.existsSync(localFilePath) && isFalse) {
dirs.push(localFilePath);
parent = path.parse(rpath).dir.replaceAll("\\", "/");
localFilePath = path.join(root, parent);
isFalse = parent !== "/";
}
for (const  dir  of  dirs) {
fs.mkdirSync(dir);
}
} catch (error) {
console.log(error);
}
};

好傢伙，在while 迴圈裡我做了parent = path.parse(rpath).dir.replaceAll(“\“, “/“);，應該是parent = path.parse(parent).dir.replaceAll(“\“, “/“); 不然parent 一直不等於”/“,這樣就一直迴圈出不來了，導致主程序卡頓失去響應。
解決這個問題後發現，卡頓依然存在，還需要繼續優化。

方案二

一般來說，造成卡頓的主要原因是主程序被阻塞了，雖然我使用的非同步，但是，像之前的while 迴圈無線遞迴，雖然放在主程序，但是也會阻塞主程序，而下載上傳這樣的同步邏輯涉及到很多計算和資源的等待，於是，我對同步邏輯進行了整改，我把同步邏輯放在一個隱藏的渲染程序進行執行，通過ipc再進行互動.

進行了這一輪改造後，發現優化後的效果不太明顯。

方案三

經過前幾輪的優化，讓我對我渲染程序的邏輯有些思考，會不會是我的渲染程序的js程式碼有問題，於是我重新審視了我的程式碼，發現在獲取狀態圖示的時候,每個檔案都需要呼叫ipc，通過主程序獲取檔案的狀態，並且，每一個觸發同步操作時，都會通知渲染程序進行重新渲染，如果觸發頻率過高，就會一直觸發渲染，而且發現獲取狀態的回撥時長有點長，平均每個1s，

const resust = await ipcRenderer.invoke("getFileStatus",
   this.getRLPath(filedir)
);

就是這段程式碼。

於是我就將獲取狀態的方案重新整改。通過快取的方式獲取，放到主程序的全域性變數裡，兩個渲染程序共同操作這個全域性變數

 const statusCache: any = new mapCache();
  const statusCacheinit = async () => {
  const meta = new MetaData();
  const dbFile = await meta.getAll("");
  statusCache.clear();
  if (dbFile) {
    for (const file of dbFile) {
      if (statusCache.containKey(file.path)) {
        continue;
      } else {
        statusCache.add(file.path,  {
          path: file.path,
          status: "success",
          fileID: file.fileid,
          sharePerm: file.remotePerm.includes("R"),
          perm: file.remotePerm,
          collect: false,
          isShared: false
        });
      }
    }
  }
};
   global.statusCache = statusCache;

並且使用防抖，把重新整理的頻率降低下來,

 debounce(
      () => {
        ipcRenderer.sendTo(this.mainID, "dirChange", filePath, evt);
      },
      2000,
      { maxWait: 5000 }
    )();

經過這次的方案整改後，整體的感覺沒有卡頓，用的比較流暢，當然後續還有優化空間

總結

用electron進行pc客戶端的開發坑還是有點多的，特別是優化這一塊，electron的優勢是js和html，他的缺點也是js和html，本來是想用多執行緒做這次的優化的，發現js 的Web Worker太難用了，而且不能使用electron模組，這樣在web Worker處理的邏輯就不能方便的通知到渲染程序，所以對於卡頓優化這一塊，還是得通過其他方式進行優化，最最重要的是防止主程序阻塞。