背景
公司需要做一個同步盤的客戶端,框架技術選型方面使用了支持跨平臺的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處理的邏輯就不能方便的通知到渲染進程,所以對於卡頓優化這一塊,還是得通過其他方式進行優化,最最重要的是防止主進程阻塞。