记一次前端使用Websocket实现AI会话时卡顿的bug修复记录

引言

嘿，大家好！今天我想聊聊我最近在前端开发中遇到的一个头疼的问题，以及我是如何一步步解决它的。如果你也在使用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张图表。我计划进一步优化图表的渲染方式，比如分批渲染或使用更高效的图表库。如果你有任何建议或想法，欢迎在评论区告诉我！

结语

这次的经历让我深刻认识到，优化是一个不断试错和调整的过程。我相信，通过持续学习和实践，我能成为一名更出色的全栈工程师。如果你有任何建议或想法，欢迎在评论区告诉我！