记一次前端使用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张图表。我计划进一步优化图表的渲染方式,比如分批渲染或使用更高效的图表库。如果你有任何建议或想法,欢迎在评论区告诉我!

结语

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

热门相关:傲世武皇   呆萌配腹黑:倒追男神1000次   呆萌配腹黑:绝宠小冤家   带着仙门混北欧   娇女种田,掌家娘子俏夫郎