页面性能优化

发布于:2025-07-29 ⋅ 阅读:(19) ⋅ 点赞:(0)

优化点

解决方案

效果

  1. 双向绑定数量过多

竞对设置单元格内部涉及双向绑定的输入组件过多,线上页面最多有88个该和抽屉中的编辑表格一样的组件,共计930+个(按每行最少6个来计算的)双向绑定的组件,严重拖累页面性能。

数据计算依据:88 = 竞对信息单元格数,930 = 155(编辑表格行数)*6(每行最低的双向绑定组件数)

问题截图

将竞对设置的编辑表格改为纯文本展示表格全局仅维护一个编辑表格,点击对应单元格的编辑按钮后,显示抽屉,将目标单元格数据带入编辑表格进行编辑操作,编辑完成后将修改后的数据同步到目标单元格对应的数据对象中。

通用的编辑表格组件数量由88个缩减到1个,双向绑定组件由930+个缩减到20个以内(线上数据每个编辑表格大概2-3行)

优化前

优化后

M3 Mac

进入页面后13s后可以进行页面交互

感官卡顿时间:6s

滚动会有明显卡顿

进入页面后6s后可以进行页面交互

感官卡顿时间:1s

滚动无卡顿

Windows测试机

页面崩溃无法打开

刷新后13s后可以进行页面交互

感官卡顿时间:5s

滚动无卡顿

2. 高并发重复请求​

这是在子组件请求接口,没有做接口缓存,导致调用N次请求。

缓存后,不切换城市只请求一次。

3. 树型选择器渲染函数时间复杂度高

线上场景组织节点数为5377个,当选择父级节点时,树型选择器renderTag方法使用了O(n2)的查找父节点遍历方法。

该renderTag方法在初始化、点击选择框、选择值、选择框失焦等多个事件中都会触发。

问题截图:

使用Map进行缓存,将函数时间复杂度降为O(n)

              // 优化前:filter+some 二层嵌套循环 时间复杂度为O(n2)
                const allTagList = data.filter((item) => {
                // 如果 item 有父节点,检查父节点是否选中
                if (item.parentId) {
                  // 查找时间为O(n)
                    return !data.some((dataItem) => dataItem.id === item.parentId);
                }
                // 如果 item 没有父节点,直接选中
                return true;
            });
// 优化后:Map直接读数时间复杂度为O(n)
const allTagList = data.filter((item) => {
                // 如果 item 有父节点,检查父节点是否选中
                if (item.parentId) {
                    // 使用 Map 的 has 方法,时间复杂度 O(1)
                    return !selectedIdMap.has(item.parentId);
                }
                // 如果 item 没有父节点,直接选中
                return true;
            });

优化前

优化后

M3 Mac

点击全选果蔬组织

JS逻辑层执行时间4046ms

页面卡顿时间:6s

点击选择果蔬中心全选

JS逻辑层执行时间 6ms

页面卡顿时间:2s

Windows测试机

点击全选果蔬组织,页面崩溃

点击选择果蔬中心全选

页面卡顿时间:4s

感官卡顿计时方式

  1. 开始计时:使用计时器,点击全选果蔬按钮后开始计时

  2. 结束计时:页面可以随意滚动交互

感官卡顿时间 = 结束时间点-开始时间点

JS逻辑计时方式

在renderTag问题函数的开始结束位置获取时间戳,在函数执行完毕后打印两者差值。

JS逻辑层执行时间 = 点击全选果蔬按钮后控制台输出的最长renderTag执行时间

4. 写法优化。

使用Set (n1)查找

避免模版直传方法渲染,替换为计算属性


网站公告

今日签到

点亮在社区的每一天
去签到