图表列表性能优化：可视化区域内最小资源消耗

最新推荐文章于 2023-03-06 14:35:13 发布

周陆军的个人博客

最新推荐文章于 2023-03-06 14:35:13 发布

阅读量208

点赞数

分类专栏：前端文章标签： vue.js html5 javascript

本文链接：https://blog.csdn.net/u012244479/article/details/118252004

版权

67 篇文章 2 订阅

订阅专栏

之前写过《懒加载优化：JavaScript IntersectionObserver API监听元素是否可见》，基于上一篇文章，做个滚动懒加载完全不是问题。

但是，如果页面定时自动刷新，不可见区域内的刷新完全是浪费前后端的资源。

本篇在上篇的基础，通过自己的一个改版案例，来看IntersectionObserver+ResizeObserver+getBoundingClientReact+Object.freeze是如何提升项目的整体性能与用户体验的

案例如下：

这个页面，不只是简单的滚动加载那么加载。图表也比较复杂

这个页面之前的实现的挺复杂，而且时不时的报bugger(代码复杂了，出问题的概率肯定会加大）。

来看看你的项目存是否也可能存在以下几个致命问题：

多图表的列表，多用户设置定时自动刷新，服务器请求特别多，资源消耗严重（如果限制视窗内刷新，十屏滚动，资源就是减少90%)
图表列表数据过大时，页面卡死，甚至崩溃（
1. BUS、echarts事件组件注销时没有解绑——函数多次重复执行
2. 图表数据Vue 深度watch——大数据图表，CPU、内存爆棚，页面直接崩溃
页面整体事件响应慢——父容器不断遍历通知子组件，性能消耗。
echarts图表刷新慢——很多时候echarts实例重建，而不是调用原来的实例 setOption
定时刷新时间不精准，内存泄露——setInterval直接设置定时刷新
windows全局手动管理echarts实例，项目内存占用巨大，甚至内存泄露，页面崩溃

容器滚动，通知容器内组件，需要重新渲染；组内再调用组件内刷新。

同理，当父容器尺寸变化时；或者编辑列表，尺寸调整时；做同样的操作。

这个就是原来的实现方式

面板页面组件：贴出来肯定是简化版的，实际业务复杂得多得多……

然后再每个图表组件，再次感觉被轮奸一遍

然后又在每个图表组件里面，去重新渲染子组件。

这个代码就不贴了……

上面代码基本实现了上述的功能，但肯定不符合 高内聚低耦合 的，都俄罗斯套娃了。

先概括地说一下优化思路：

对于滚动加载，有IntersectionObserver API，滚动时，组件自己判断是否可见，去加载。但是，这里面还要注意下条件
1. 未初始化时，滚动时候，直接加载就是。并存储当前加载的请求参数，以后后面加载时核验
2. 已经加载中（组件loading时），无需再加载）
3. 已经初始化了，需要判断查询条件是否改变，如果改变了，需要再次加载——如查询参数、定时刷新时间
对于尺寸变化，有ResizeObserver，无论是页面尺寸变化、还是其父组件、爷爷组件尺寸变化，都会反馈到之间本身的尺寸变化，直接监听组件本身就好。
对于刷新事件，组件自己储备上次加载的参数，接手刷新事件后，自己觉得干啥。
对于内存CPU+内存爆炸，杜绝图表配置项(option参数)在vue上绑定与监听，可以数据采样；echarts实例、各类绑定事件，及时销毁。