技术博客 技术博客
  • JAVA
  • 仓颉
  • 设计模式
  • 人工智能
  • Spring
  • Mybatis
  • Maven
  • Git
  • Kafka
  • RabbitMQ
  • RocketMQ
  • Redis
  • Zookeeper
  • Nginx
  • 数据库套件
  • MySQL
  • Elasticsearch
  • MongoDB
  • Hadoop
  • ClickHouse
  • Hbase
  • Hive
  • Flink
  • Flume
  • SQLite
  • linux
  • Docker
  • Jenkins
  • Kubernetes
  • 工具
  • 前端
  • AI
GitHub (opens new window)
  • JAVA
  • 仓颉
  • 设计模式
  • 人工智能
  • Spring
  • Mybatis
  • Maven
  • Git
  • Kafka
  • RabbitMQ
  • RocketMQ
  • Redis
  • Zookeeper
  • Nginx
  • 数据库套件
  • MySQL
  • Elasticsearch
  • MongoDB
  • Hadoop
  • ClickHouse
  • Hbase
  • Hive
  • Flink
  • Flume
  • SQLite
  • linux
  • Docker
  • Jenkins
  • Kubernetes
  • 工具
  • 前端
  • AI
GitHub (opens new window)
  • 工具

    • vscode ide 配置
    • cursor AI
  • 前端

    • VUE3知识点
    • Echarts 优化
      • 背景
      • 调研
        • 检查性能
        • 总体分析
        • 一帧分析
        • 无数据分析
        • 少数据分析
        • 分析结果
      • 方案及测试
        • 修改echarts
  • AI

    • AI 基础知识
目录

Echarts 优化

# 背景

规定要求要显示 6 张图,1 长图的数据量在 200*50 ,需要很流畅,在 100ms 以内一帧,比较丝滑的那种,但是实际使用下来发现一帧渲染会在 200-500ms ,实际做不到很丝滑,于是项目现在每张图定位 1s 一帧,但是最终发现,6 张图若同时展示数据,页面其他动画会很卡。

# 调研

我是用的是 echarts 内置的图,曾怀疑 echarts 因为其他兼容或 API,所以没有原生的快,于是我调研了 canvas 以及 threejs,发现其实效果是一样的,依然很卡顿。所以我就不打算换了,继续使用 echarts 想办法优化。

# 检查性能

使用 edge 检查工具,查看 20s 内数据渲染过程中的性能

# 总体分析



# 一帧分析



# 无数据分析

我把 echarts 的数据渲染关闭,但但只看 echarts 的图渲染的性能




# 少数据分析




# 分析结果

再显示一张有数据的图时,可以看出 GPU 并不耗时,主要是 js 脚本执行耗时,js 脚本应该包括了柱子的生成,数据的处理等。但不渲染数据只渲染图的时候可以发现,只有 echarts 初次渲染,以及定时器会消耗 js 耗时,那么基本可以断定还是数据量的问题导致

# 方案及测试

# 修改 echarts

  • setOption 更改,跟性能无关,单纯的规范优化
    // 不推荐写法,目前用于测试,getOption 获取的是已经合并过默认值了的,所以在修改了某些配置项后会导致原本是根据这些配置项值去设置的默认值失效
    let oldOption = chart.getOption()
    // oldOption.series[0].data = nv.prps
    chart.setOption(oldOption)
    
    // 推荐
    chart.setOption({
      series:[
        {
          data: nv.prps
        }
      ]
    })
    
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
  • 有效数据替换:后端检查两个二维数组,在 [x,y,z] 中,过滤 x y 相同,z+-5 的数据,也就是找相同坐标差异过大的数据,推送前端替换已有二维数组里的相同 x,y 数据并渲染。测试结果并不理想,脚本时间反而变的更长,也对应了那句,不要在前端做数据处理。

  • 定向定位推送数据合理规划数据结构:6 张图我都是用 websocket 推送的,除了所看到的一个 websocket 负责 6 张图的数据,其中一帧数据的结构包含多种类型的图,为的是切换后能立即看到效果。
    后端方案:
      1. websocket改为sse
      2. 6张图6个id,各自请求sse接口
      3. 根据事件推送对应显示图的数据
      4. 增加帧率减少数据,从左往右顺时针推送,前端使用append追加,达到容量后替换数据
    
    1
    2
    3
    4
    5
    结论:改为 sse 还没 ws 稳定,但各自一个 id 开一个 ws 会话,虽然对服务器造成一定负担,但明显 ws 并没有并发错误,可渲染依然慢,所以跟后端关系不大 纯前端问题。但又有个新问题就是,后端推的块,前端处理慢,会造成浏览器缓存数据,直到因浏览器缓存饱满 ws 报错,所以需要注意后端推送频次。(想改为前端消费一帧,请求 ws,然后 ws 推,但效率会更慢,最好的方案测好前端帧率,固定推,但各个机器性能不一样依然会有问题)
上次更新: 6/11/2025, 4:10:30 PM
VUE3知识点
AI 基础知识

← VUE3知识点 AI 基础知识→

Theme by Vdoing | Copyright © 2023-2025
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式