问题背景
在去年的一场面试中,面试官向我提了一个问题:
面试官:后端一次性给你一千万条数据,渲染到页面上发生卡顿,你该怎么优化?
我:我会问候后端(bushi)
实际上我的回答是:如果没办法改变后端的情况下,我会避免给这种大数据量赋予响应式,然后手动 分页渲染。
面试官:不对哈,用Object.freeze
来优化。
我:???
这段时间突然想起这个问题,决定试一下实际遇到这种情况到底该怎么优化。
测试环境搭建
前端实现(Vue3)
vue
<template>
<div>
<div class="user-info" v-for="user in userList" :key="user.id">
我是 {{ user.name }}
</div>
</div>
</template>
<script setup lang="ts">
import { ref } from 'vue'
const tableData = ref([])
const getData = async () => {
const res = await fetch('/api/mock')
const data = await res.json()
tableData.value = data
}
getData()
</script>
<style scoped>
.user-info {
height: 30px;
}
</style>
后端实现(NestJS)
typescript
getMockData() {
function generateMockData(amount) {
const data: any = []
for (let i = 0; i < amount; i++) {
data.push({
id: i,
name: `User${i}`,
timestamp: Date.now(),
metadata: {}
})
}
return data
}
const mockData = generateMockData(1000000)
return mockData
}
初始效果: ⏳页面渲染耗时 30S 左右。
方案一:Object.freeze
面试官推荐的方案实现:
typescript
const getData = async () => {
const res = await fetch('/api/mock')
const data = await res.json()
userList.value = data.map((item: any) => Object.freeze(item))
}
测试效果:
- ⏳渲染时间:仍需要 30s 左右
- ✅优点:能够避免后续数据变更的响应式消耗
- ❌缺点:无法解决初始渲染性能瓶颈
方案二:分块渲染(requestAnimationFrame)
通过分批渲染避免 主线程阻塞 :
typescript
<script setup lang="ts">
import { ref } from 'vue'
const userList = ref<any[]>([])
const CHUNK_SIZE = 1000
const getData = async () => {
const res = await fetch('/api/mock')
const data = await res.json()
function* chunkGenerator() {
let index = 0
while(index < data.length) {
yield data.slice(index, index + CHUNK_SIZE)
index += CHUNK_SIZE
}
}
const generator = chunkGenerator()
const processChunk = () => {
const chunk = generator.next()
if (!chunk.done) {
userList.value.push(...chunk.value)
requestAnimationFrame(processChunk)
}
}
requestAnimationFrame(processChunk)
}
getData()
</script>
测试效果:
- ⏳首屏时间:< 1s
- ❌缺点:随着数据的增加,DOM节点持续增加,最终仍影响性能
方案三:虚拟列表(终极方案)
只渲染可视区域内容:
vue
<template>
<div class="viewport" ref="viewportRef" @scroll="handleScroll">
<!-- 占位元素保持滚动条高度 -->
<div class="scroll-holder" :style="{ height: totalHeight + 'px' }"></div>
<!-- 可视区域 -->
<div class="visible-area" :style="{ transform: `translateY(${offset}px)` }">
<div class="user-info" v-for="user in visibleData" :key="user.id">
我是 {{ user.name }}
</div>
</div>
</div>
</template>
<script setup lang="ts">
import { ref, computed, onMounted } from 'vue'
const userList = ref<any[]>([])
const getData = async () => {
const res = await fetch('/api/mock')
const data = await res.json()
userList.value = data
}
getData()
const viewportRef = ref<HTMLElement>()
const ITEM_HEIGHT = 30
const visibleCount = ref(0)
const startIndex = ref(0)
const offset = ref(0)
// 计算总高度
const totalHeight = computed(() => userList.value.length * ITEM_HEIGHT)
// 计算可见数据
const visibleData = computed(() => {
return userList.value.slice(
startIndex.value,
Math.min(startIndex.value + visibleCount.value, userList.value.length)
)
})
// 初始化可视区域数量
onMounted(() => {
visibleCount.value = Math.ceil((viewportRef.value?.clientHeight || 0) / ITEM_HEIGHT) + 2
})
// 滚动处理
const handleScroll = () => {
if (!viewportRef.value) return
const scrollTop = viewportRef.value.scrollTop
startIndex.value = Math.floor(scrollTop / ITEM_HEIGHT)
offset.value = scrollTop - (scrollTop % ITEM_HEIGHT)
}
</script>
<style scoped>
.viewport {
height: 100vh; /* 根据实际需求调整高度 */
overflow-y: auto;
position: relative;
}
.scroll-holder {
position: absolute;
left: 0;
right: 0;
top: 0;
}
.visible-area {
position: absolute;
left: 0;
right: 0;
}
.user-info {
height: 30px;
}
</style>
测试效果:
- ⏳首屏时间:< 1s
- ✅优点:只渲染 可视区域 内的DOM,减少不必要的消耗
- ❌缺点:实现相对麻烦,实际情况可能需要动态计算元素高度
方案对比总结
方案 | 首屏时间 | 内存占用 | 滚动性能 | 实现复杂度 |
---|---|---|---|---|
原始渲染 | 30s+ | 高 | 差 | 简单 |
Object.freeze | 30s+ | 高 | 差 | 简单 |
分块渲染 | <1s | 持续增长 | 逐渐变差 | 中等 |
虚拟列表 | <1s | 低 | 流畅 | 较高 |
彩蛋:为什么我只测了100万条数据?
当我试图测试 一千万 条数据时:
- 第一次报错:
FATAL ERROR: JS堆内存不足
🤔 - 第二次报错(调高内存上限后):
RangeError: 字符串长度超标
💥响应体过大了,超出了V8引擎的字符串长度限制🤣,如果要返回只能使用SSE了,但这就违背了问题的"一次性返回"。(Java的JVM引擎响应限制比较大,应该是可以返回的)
总结
- 响应式优化 ≠ 渲染优化:
Object.freeze
只能解决响应式开销,不能解决渲染瓶颈。 - 分块渲染算是折中方案: 也并不适合大量的数据渲染,性能开销依旧很大。
- 虚拟列表是最佳实践: 能够应对大数据量的渲染,且不影响性能。
- 实际情况: 还是应该避免后端一次性返回大量的数据。测试用例中,本地返回百万条数据(还是简单的json结构)接口都需要响应 1.7s~3s 。如果后端只能返回全量数据,那只能考虑 虚拟列表 解决方案。