性能优化体系化建设：BI平台的深度优化实践

1. 问题背景与建立监控基线：

场景：OMNIEYE平台的核心数据看板，用户配置了多个图表，一次性拉取并渲染数万行、数十列的数据，导致：
1. API响应时间极长（超过10s）。
2. 浏览器解析JSON和数据转换卡死（主线程阻塞超过15s）。
3. 页面渲染完成后，用户操作（排序、筛选）极度不流畅。
建立监控基线：
- 工具：基于自研的前端监控SDK（采集性能指标）和 Chrome DevTools Performance Panel（进行深度剖析）。
- 量化指标：
  - 网络层面：API请求耗时、响应体大小。
  - 关键渲染指标：FCP, LCP。
  - JS执行性能：Long Tasks（长任务）的数量和持续时间、Scripting 时间。
  - 内存：JS Heap大小，是否存在内存泄漏（通过Memory Snapshot对比）。
- 基线数据：优化前，我们记录到从发起请求到页面完全可交互（TTI）平均需要 ~25秒，其中存在超过10个长达数秒的Long Tasks。

2. 定位瓶颈：

通过Performance录制和代码分析，我们精准定位了三大瓶颈：

网络与数据传输瓶颈：单次API响应体过大（一个包含5万行*15列数据的接口，响应体高达15MB+的JSON字符串）。
主线程阻塞瓶颈：
- JSON.parse：解析一个15MB的JSON字符串本身就是一个长任务。
- 数据标准化处理：后端返回的扁平数据，前端需要遍历并转换成组件所需的嵌套结构，这个递归转换过程是O(n²) 的时间复杂度，消耗了巨量时间。
渲染引擎瓶颈：
- DOM数量爆炸：一次性将数万行数据渲染成表格DOM节点，导致DOM数量超过10万个，样式计算、布局、重绘极其缓慢。
- 内存占用过高：庞大的JS数据对象和DOM节点占用了超过1GB的内存，频繁触发垃圾回收，导致页面卡顿。

1. 数据包体结构优化

这不仅仅是启用Gzip，而是对数据协议本身的优化。

优化前：

[{ "id": 1, "name": "Alice", "value": 100 },{ "id": 2, "name": "Bob", "value": 200 },// ... 重复5万次，属性名 "id", "name", "value" 重复了5万次
]

优化后：

{"columns": ["id", "name", "value"],"data": [[1, "Alice", 100],[2, "Bob", 200],// ... 只有纯数据，没有冗余的属性名]
}

技术细节：
- 协议约定：与后端团队共同制定此新协议，并作为API标准推广。
- 反序列化器：前端编写一个轻量的 parseColumnarJSON 函数，将列式数据还原为组件所需的行式对象数组。关键在于，这个还原过程可以惰性执行，无需一次性转换全部数据。
效果：仅此一项，响应体体积减少约65%（从15MB降至5-6MB），JSON.parse 的时间相应减少了约70%。

2. 大数据量分段渲染（虚拟滚动与增量处理）

我们放弃了全量渲染，实现了基于虚拟滚动的分段渲染。

方案：
1. 虚拟滚动容器：自定义一个虚拟滚动组件，它只维护一个固定高度（如可视区域 + 上下缓冲区的总高度）的DOM元素。
2. 数据切片与索引：接收到数据后，并不立即转换为完整的JS对象数组，而是将其视为一个“数据源”。根据滚动位置和滚动条信息，动态计算当前应该显示的数据的startIndex和endIndex。
3. 增量数据转换：只对 [startIndex, endIndex] 这个区间内的数据进行从列式到行式的转换。例如，如果一屏只能显示20行，我们每次只转换和渲染 20 + 10（缓冲区） = 30 条数据。
技术细节：
- 滚动计算：监听容器的 scroll 事件（需节流），通过 scrollTop 和容器高度计算出需要渲染的数据索引。
- DOM回收与复用：使用 <div> 模拟表格行，滚动时回收离开可视区域的DOM节点，并将其复用于新进入的数据，保持DOM数量恒定。
- 与框架结合：在Vue中，我们利用 v-for 和 :key 绑定到切片后的数据数组，Vue的响应式系统会自动高效地更新DOM。
效果：首次渲染的DOM数量从 10万+ 降至 ~30个，FCP和LCP指标从秒级降至毫秒级。主线程长任务完全消失。

除了上述两种立竿见影的方案，我们还实施了更底层的优化：

1. 渲染策略：

Web Worker 异步数据处理：将最耗时的 JSON解析 和 数据标准化 过程放入 Web Worker。主线程仅负责接收Worker处理好的、已经结构化的数据切片并进行渲染。这彻底消除了脚本执行对主线程的阻塞，保证了页面的响应性。
Canvas/WebGL 渲染替代DOM：对于超大规模的关系图谱或地理信息可视化，我们放弃了基于SVG/DOM的 @antv/g6，转而使用其基于 Canvas 或 WebGL 的渲染引擎。这对于渲染数万个节点和边线的场景，性能有数量级的提升。
惰性监控与观察：对非核心的图表组件，使用 Intersection Observer API 进行监听，只有当其滚动进入视口时才开始渲染和加载数据。

2. 内存管理经验：

数据引用与释放：
- 显式解引用：当用户离开一个包含巨大数据集的看板时，我们手动将存储该数据的Vue组件中的 this.dataset 设置为 null。
- 弱引用：对于一些全局的、可被重复使用的缓存数据（如字典表），我们使用 WeakMap 或 WeakSet 来存储。这样，当这些数据不再被任何地方引用时，垃圾回收器可以自动回收它们，防止内存泄漏。
防内存泄漏守则：
- 事件监听器：在虚拟滚动组件的 beforeUnmount 生命周期中，强制移除所有全局的 scroll、resize 事件监听器。
- 定时器清理：使用 setInterval 进行轮询的组件，必须在 unmounted 钩子中调用 clearInterval。
- Detached DOM Nodes：定期使用Memory工具快照，检查是否存在因不当的DOM操作而产生的“分离的DOM节点”，这些是常见的内存泄漏源。
结构化克隆与传输：当使用 Web Worker 时，我们利用 postMessage 的第二个参数，即 Transferable Objects。对于 ArrayBuffer 这类二进制数据，可以直接“转移”所有权给Worker，而不是复制一份，这实现了零拷贝，极大提升了大数据传输效率并降低了内存占用。