記一次前端使用Websocket實現AI會話時卡頓的bug修復記錄

几度失手ya發表於2024-07-24
前端WebAI會話

引言

嘿，大家好！今天我想聊聊我最近在前端開發中遇到的一個頭疼的問題，以及我是如何一步步解決它的。如果你也在使用Websocket實現AI會話，或許你會遇到類似的問題。

專案背景

我最近在搗鼓一個開源專案，專案地址：GitHub - chatpire/chatgpt-web-share: ChatGPT Plus 共享方案。ChatGPT Plus / OpenAI API sharing solution. 感謝大佬的開源。原本它支援多種AI聊天介面，但我把它簡化了，只保留了OpenAI API，專注於特定功能的開發。

遇到的挑戰

在開發過程中，我發現隨著聊天輪次的增加，應用的響應速度越來越慢，記憶體佔用也異常高。這讓我有點頭疼，畢竟使用者體驗是最重要的。

初次嘗試：記憶體分析

我嘗試用開發者工具去分析記憶體，但說實話，我那半吊子的前端水平讓我有點摸不著頭腦。我在網上搜羅了各種教程，但似乎都不太對症。

思路轉變：效能最佳化

我意識到問題可能出在渲染大量echarts圖表上，於是嘗試引入了虛擬列表技術。想法是好的，但實際操作起來卻問題多多，比如訊息丟失、捲軸亂跳等等。

再次調整：簡化資料處理

在放棄了虛擬列表後，我決定換個角度思考。我發現在AI回覆時，CPU佔用率特別高。這讓我意識到，可能需要重新設計後端和前端的資料互動方式。

技術實現

我調整了後端邏輯，讓它只傳送最新的訊息增量，而不是每次都傳送全量訊息。這樣不僅減少了網路傳輸的負擔，也減輕了前端的記憶體壓力。前端程式碼也做了相應的最佳化，避免了重複的訊息處理。

        const index = currentRecvMessages.value.findIndex((msg) => msg.id === message.id);
        if (index === -1) {
          currentRecvMessages.value.push(message);
        } else {
　　　　　　// 原來的
          // currentRecvMessages.value[index] = message;
　　　　　　// 新的
          currentRecvMessages.value[index].content!.text += message.content!.text;
        }

效果

經過這些調整，應用的響應速度和記憶體佔用都有了顯著的改善，使用者體驗也大幅提升。現在，CPU佔用通常在10-35%之間，但接收echarts圖表時，會飆升至150-300%。這顯然是下一步需要最佳化的點。

未來計劃

我猜測，CPU佔用率飆升的原因可能是需要同時渲染30張圖表。我計劃進一步最佳化圖表的渲染方式，比如分批渲染或使用更高效的圖表庫。如果你有任何建議或想法，歡迎在評論區告訴我！

結語

這次的經歷讓我深刻認識到，最佳化是一個不斷試錯和調整的過程。我相信，透過持續學習和實踐，我能成為一名更出色的全棧工程師。如果你有任何建議或想法，歡迎在評論區告訴我！

相關文章