探索Table组件虚拟化

发表于 3年以前 | 总阅读数：448 次

前言

列表及表格的虚拟优化不是个新鲜的课题，近期，团队发现：业界对于 table 虚拟化竟然没有一个相对一劳永逸的解决方案。这是为什么？又该如何解决？在本文中，我们会循序渐进的介绍在 React+AntDesign 技术栈下，团队内部对 Table 组件虚拟化的不同实践思路，分析可能遇到的难点问题。

虚拟化问题阐述

在列表页、瀑布流、Select 组件中，我们都有可能遇到渲染大数量级列表的场景。在过去，我们总结了一套卓有成效的办法：对于列表，我们通过计算，保证在滚动视窗时，每次只渲染部分元素。这样既减少了首屏压力，也保证长时间加载也不会有更多的性能负担，可以满足上述大部分场景的高性能优化需求。具体做法上，我们利用已知的固定行高和滚动偏移量，计算出滚动到的表格行索引，只渲染出有限视窗内所需要的元素，，并对列表进行相应设置，简述过程如下：

计算当前可见区域起始数据的 startIndex
计算当前可见区域结束数据的 endIndex
计算当前可见区域的数据，并渲染到页面中
计算 startIndex 对应的数据在整个列表中的偏移位置 startOffset，并设置到列表上
计算 endIndex 对应的数据相对于可滚动区域最底部的偏移位置 endOffset，并设置到列表上

这一方案是广泛被大多数开发人员探讨的。我推荐参考浅说虚拟列表的实现原理[1]，他对问题的思路，实现，均有比较详尽的描述。如今，我们的场景来到了 AntDesign 的 Table 组件。我们面对十分类似的问题：业务当中，Table 涉及1000+行 & 100+列数量级别的渲染时，由于单元格内也具有一定的复杂逻辑，因此页面渲染时长往往需要卡顿 5000ms 前后的时间。这显然是不能够接受的。实际上，从长列表到 Table 组件，我们的列表无非是从一维轴线上升到了二维平面。因此，所谓表格虚拟化，无非就是希望表格可以实现：在兼容 Table 现有功能的情况下，实现表格只渲染视窗平面内容，对于视窗外的行、列予以隐藏。

整理现状

AntDesign

我们内部的 React + umi + AntDesign 技术栈是目前前端界较为常见的一种架构基础。AntD 作为业界 react 常用组件库，它提供的 Table 组件，能够方便的帮我们解决诸多常见需求，包括并不仅限于：行选择、行展开、行筛选、数据分页、列固定... 目前 AntDesign 有 AntD@3.26 和 AntD@4.11 两大版本，后者经过一定的重构和优化，是官方推荐的最新内容。AntDesign3 文档中已经删除了对于虚拟化支持的 demo（实际也可以使用），而在 AntDesign4 文档中，能看到官方推荐用户以接入 react-window 的方式解决虚拟化表格问题。

从官方的 Demo 来看，AntD 提供了一个 components 属性，通过传入一个对象，在其 body 属性中给到一个 ReactWindow 提供的虚拟化组件，以实现需求

 ...
 // VariableSizeGrid is a component provided by react-window
 const renderVirtualList = (rawData, { scrollbarSize, ref, onScroll })=>
     <VariableSizeGrid
       {...props}
     />
 ...
 <Table
    {...props}
    className="virtual-table"
    columns={mergedColumns}
    pagination={false}
    components={{
      // overwrite the body set by AntD
      body: renderVirtualList,
    }}
  />
  ...

ReactWindow

react-window 是一个广受欢迎的用于解决表格虚拟化问题的开源代码库，它产出了不同特性的虚拟化组件，以便用户聚焦不同虚拟场景的问题解决。

react-window 的原理并不复杂，主要就是本文在虚拟化问题阐述中对于虚拟化要求内容的实现。主要是通过监控 onScroll，动态调整表格横轴偏移量，节选适当数量的部分数据，进行可视区内容渲染。

他的前身是 react-virtualized。经过了重构和升级，作者对 table 和 list 两种不同的场景做了更好的抽象，通过重用共通部分的逻辑，实现了更好的性能，代码打包大小也减少到了原先的 20%。

接入时遇到的问题

看上去，AntD 已经给出了一套虚拟化方案。但稍稍深入调查不难发现，在 Github 的 Issue 中，对于官方推荐方案，用户反馈则不甚理想。比如：

在问题#21022[2]中提出，使用 AntD3 后，展开、多选等功能点缺失。
在问题#20339[3]中提出，使用 AntD4 后，大多数表格功能点都存在缺失。

针对上述问题，官方均回复以用户自行解决，因此：

按照 AntD 文档使用虚拟化进行配置，虽然可以一定程度实现虚拟化，但会引起多处表格功能缺失。

这是目前我们主要亟待解决的问题。

rc-table

由于官方没有给出很好的虚拟化方案，我们只好深入了解 AntD 内部的架构，寻找问题的切入点。经阅读代码可以了解，在 4.11 的 AntD/Table 代码架构简述如下：

在 AntDesign/Table 中：
初始化表格大小和行列内容
初步整理事件和数据
排序、分页、过滤等功能对 data 和 column 的计算逻辑
调用 rc-table 依赖
在 rc-table 中：
注册各类行列单元格事件
完成各种样式需求，如列固定，行展开
完成渲染

至此，我们可以了解到，AntD 架构本身其实已经对表格逻辑进行了一定程度的划分，与 data 数据的顺序及内容无关的逻辑，已经被单独抽象到了 rc-table 这个库中。大致上我们可以理解为下图：

我们也必须要想清楚：

这三层逻辑，我们分别对他们做保留，改造，还是替换？
如保留，如何解决引入虚拟化逻辑后，虚拟化逻辑对现有框架造成的影响？
如不保留，新的框架如何选择？

组内方案陈列

项目组内对于 table 的虚拟化工作产生了多种不同思路：

方案 1：基于 rc-table 不依赖 react-window 和 AntD 实现虚拟化

实现思路：

在不同业务中，我们需要的表格组件功能点并不一致，极端场景下，我们可能只需要使用少量 AntD 的 Feature，且定制化较高。因此我们可以考虑放弃使用 AntD，直接使用 rc-table 并做一定改造。

实现方式：
fork 一份稳定版本 rc-table 放入代码库内
按照虚拟化原理对 rc-table 完成必要改造
自己实现排序、选择、列固定等上层功能点

方案优劣：
丢失了 AntD 的功能基础。
不再需要自己实现基础的表格呈现，这部分有 rc-table 完成，我们只需要针对虚拟化对滚动事件做少量改造。
外部功能 feature 方便自定制。
优点：
缺点：

方案 2：AntD 中截取显示数据，手动销毁表格外 dom，手动创建占位符。

实现思路：

当业务重度依赖 AntD 的各个功能，不能直接移除 AntD。我们只能保留整体框架，找到切入点做部分改造。所以改造 antD 内表格 scroll 事件，使用新的 onScroll 逻辑：

判定 dom 行位置，计算 index
setState 动作完成后，手动销毁超出视窗的 dom 内容，同时创建等高空白区域，以维护滚动条位置。
对 data 数据内容进行裁切并更新，保证视窗内数据的正确性。

该逻辑下只修改了 AntD 传入的 data 内容，其余操作均基于 jsdom 手动完成，影响面小，完成度高。但需要仔细测试对各个表格功能点的影响。

方案优劣：
需要小心处理改方案对列固定、行展开等特性的影响。
由于无法提前获取行高，暂不支持直接定位，等价方案是需要先搜索到对应的数据，然后将结果装入 InfinityTable
向前兼容 Antd Table 的配置参数，只需要新增少数 props，改造成本极低
直接操控 dom，开发工作除了数据截取，其余大部分不依赖 AntD/rcTable 代码，性能有保障。
优点：
缺点：

方案 3：重新实现表格

实现思路

当项目定制化程度较高时，考虑直接放弃 antd。方案 3 保留了 AntD 的 props 定义，以保证从 AntD 迁移时的便利性，随后利用 react-table 完成大多数功能，虚拟化部分借助了 react-window，底层开发了全新的具有虚拟化功能的基础表格。

框架选择理由

该方案中引入了 github 上炙手可热的开源 react hook 框架 react-table，这是个数据逻辑 hook 框架，因为排序、选择、等数据逻辑是具有相似性的，所以没必要重写，它帮助节省了数据处理的成本，同时也没有干涉 UI 及虚拟化工作。

方案优劣：
表格基础实现的成本高，基础 table 需要结合 react-table 的 api 重新实现，遇到各种坑都需要自己踩
深入改造，重构程度高，方便后续做任何扩展，方便性能优化
利用开源产品实现原 AntD 的开发内容，节省一定成本
优点：
缺点：

改造重点问题复盘

空白闪烁

问题陈述：

在 react-window 的 README 中，可以看到对此问题的描述。当应用虚拟化后，过快的 scroll 动作会导致占位符尚未更新，只能看到空白内容，需要等少量时间后才加载。当连续快速滚动表格时，呈现不断闪烁空白内容的状态。

问题解决：
目前没有较好解决办法，增加预载区大小，且优化单元格渲染内容，可以减缓问题严重性。
有同学提出通过监控 scroll 时候的 speed 动态调整预载区大小，不失为一个没实践的思路。

单元格自适应换行

问题陈述：

当单元格文本内容较长时，希望高度可以自适应。此需求乍一看似乎可以利用 react-window 的不定高组件解决，但实际上，该组件需要提供一个高度函数：

// Returns the size of a item in the direction being windowed.
// For vertical lists, this is the row height.
// For horizontal lists, this is the column width.
itemSize: (index: number) => number

当文本变化时，我们也需要 render 后才能获取每一行的高度，所以这个 api 并没有想象中美好。该问题还是必须借助二次渲染后，通过 ref 拿 dom 节点才能解决，但这样会拖慢性能，因此考量后，对此方案不予支持

列固定

问题描述

在方案 3 中，由于使用了 div 的 flex 排版而不是原生 table，为了实现列固定时，我们需要使用三个 table 来做固定效果，因此滚动时，我们需要同时改变多个表格的 scrollTop 以及其数据截取。

问题解决
可以使用一个 state 同步多个 table 之间的 scrollTop，但这种实现有可能因为性能，产生表格渲染的先后，进而产生三张表对不齐的问题。（AntD 的 Header 与 body 对齐本身也有此问题）
AntD 不区分三个 table，而是在一个 table 内利用原生 tr/td，以及 css 的 sticky 特性，部分回避了该问题，但没有解决的很好，fixedcolumn 存在的场景下，header 和 body 的同步依旧存有类似问题。
可以将三个表格改为一个表格，然后利用性能最好的 3Dtransform 来解决此问题。下方推荐的开源产品 rsuite-table 比较好的通过此方案解决了问题。