一、背景

表格和表單在前端里面是最復雜的兩類需求，在BI工具平臺上，這2類組件需求更多，并且需要實現一些特有的交互展示。目前在敏捷BI平臺上進行報表配置，表格類組件的使用占比達到了1/3，在可視化組件庫里使用范圍很廣。為了滿足不同的數據分析場景，表格組件主要分為分組表、交叉表、明細表三種類型，其中又以交叉表功能最為豐富強大。隨著敏捷BI的業務的發展，交叉表組件也經歷了多次設計改版以支持高性能的數據渲染和個性化的展示配置。

術語注解

• 【敏捷BI】
  專為 vivo 生態用戶量身打造的 自助式 BI 平臺，提供從數據接入、數據準備、到數據分析、可視化應用、數據管理的一站式數據解決方案，同Quick BI，FineBI。
• 【圖表類型】
  圖表是數據視覺化表示的特殊方式。表示數據的方法有很多，如使用不同的符號、形狀和排列，我們把這些稱之為圖表的類型。一些圖表類型你比較熟悉，如條形圖、餅圖、折線圖，但其他類型你可能就很少見了，如?；鶊D、樹圖、等值線圖的地圖。
• 【交互方式】
  交互式可視化允許您修改，操作和探索計算機顯示的數據。絕大多數交互式可視化系統在計算機網絡上，但越來越多出現在平板電腦和智能手機上。相比之下，靜態可視化只顯示單一的、非交互數據，它通常是為了打印和在屏幕上顯示。
• 【度量值】
  表示數值的規模和范圍。度量通常以間隔表示(10、20、30等等)，代表度數字的單位，如價格、距離、年，或百分比。
• 【指標】
  同度量，表示具體某項值，單個值本身沒有任何業務意義，一般需要對應的指標口徑解釋，才會具有業務價值。

二、交叉表介紹

交叉表（Cross Tabulations）是一種常用的由 行、列、匯總字段 三個元素組成分類匯總表格。利用交叉表查詢數據非常直觀明了，在進行數據分析中也被廣泛應用。這里牽涉到另外一個概念即分組報表，分組報表是所有報表當中最普通，最常見的報表類型，也是所有報表工具都支持的一種報表格式。從一般概念上來講，分組報表就是只有縱向的分組，傳統的分組報表制作方式是把報表劃分為條帶狀，用戶根據一個數據綁定向導指定分組，匯總字段，生成標準的分組報表。交叉表有多列查詢能力、分類匯總、多角度排序、交互式分析等特性。

三、架構演變歷程

為了提高交叉表的數據渲染性能和功能擴展能力，敏捷BI的表格組件經歷了三次的設計升級。最開始用的jQuery拼接表格方式實現，隨著組件化方案的推行，采用了組件化的方式實現升級，隨著業務的發展，用多維度、多指標交叉分析場景越來越多了，尤其是通過交叉表進行分析時，大數據量出現了渲染崩潰等問題，所以我們最后通過微前端方式實現。  下面我們從開發難度，性能，功能擴展性，學習成本等方面的調研來講解對底層表格的升級實踐。

3.1 V1版表格

敏捷BI平臺第一版表格，技術棧是基于jQuery+DIV的方式實現的。表格拼接屬于jQuery時代的常見開發風格，這種方式，代碼可維護性會非常差，很容易會出現標簽不匹配的情況，不帶縮進，調試起來也比較費勁。這個版本的表格組件支持的業務場景主要是數據的基本展現，無法滿足用戶對表格的數據分析的需求。

架構設計

圖片

// 簡單的拼接代碼demo
function createTable() {
  var data = new Array();
 data.push('<table border=1><tbody>');
   for (var i = 0; i < 2000; i++) {
     data.push('<tr>');
     for (var j = 0; j < 5; j++) {
       data.push('<td>' + i + ',' + j + '</td>');
     }
     data.push('</tr>');
   }
   data.push('</tbody><table>');
   document.getElementById('table1').innerHTML = data.join('');
 }

3.2 V2版表格

隨著系統整體架構升級，前后端分離的推進，我們從原生的table組件遷移到Vue組件化上，開發了V2版表格組件。  平臺的整體架構全面遷移到vue+ant-design-vue上面。

1. 功能拓展

鑒于ant-design-vue上正好有table組件，對此我們對比了antd的table組件和element的table組件。2 種表格對比來看，ant-design-vue參照ant.design的React版開發出來，配置相對element更豐富，考慮到本身復雜場景支持性，更適合深度定制，最終選擇了ant.design的vue版本。

V2版的表格主要支持這幾類場景配置（條件格式，合計行/列，單元格/行樣式/內容定制等）：

業務場景&具體實現

（1）數據展示

整體就是根據不同情況設置不同的column的字段，另外為了達到點擊交互下，能夠獲取業務的數據，需要在column上掛一些冗余數據，這樣會讓column的數據信息很龐大。

columns是一個tree結構，這里采用的是dfs遍歷，depth標識層級，item， itemType就是冗余的數據信息，在處理業務的時候會用到。

（2）數據排序

（3）數據過濾

（4）單元格自定義渲染

（5）多級表頭定制

這個實現難點主要在于把已有的列如何放到新增的表頭里，保持樹形children結構具體實現代碼也比較復雜，總共80行。

圖片

（6）條件格式渲染(條形圖，熱力圖）

根據設定的條件，定制表格內單元格內容的樣式

（7）合計行/列配置

添加合計列和行，內置min，max，avg，sum表達式，支持自定義簡易字段表達式運算這個功能難點在于合計列與行交叉的場景，也就是如何計算合計列的合計行。

2. 架構設計

3. 渲染優化

這個階段的交叉表，在功能上已經能夠滿足絕大多數分析場景，但是一些數據量大的表格反饋渲染白屏時間過長，經常會出現瀏覽器崩潰，表格的性能面臨新的挑戰。另外表格在渲染時，CPU會占滿，導致其他圖表也會卡住等待，形成假死的現象。我們通過分析大數據表格渲染流程，發現有30%的時間會花銷在數據適配，因此我們思考能不能把數據計算部分隔離出來，計算的時候，不阻塞渲染主進程，這樣的話，瀏覽器渲染就可以處理其他的渲染任務。在做性能優化調研時，我們引入了service worker，worker在處理cpu密集型任務有獨特的優勢，所以我們把數據預處理的過程交給了Worker。之前沒有使用worker時，我們前端邏輯會處理很多數據初始化和計算的操作，對于一個數據量很大的表格，會導致渲染卡頓2~3s，有些個別情況會導致瀏覽器崩潰的現象。

Worker原理和定義：

W3C 組織早在 2014 年 5 月就提出過 Service Worker 這樣的一個 HTML5 API ，主要用來做持久的離線緩存。service worker是瀏覽器的一個高級特性，本質是一個web worker，是獨立于網頁運行的腳本。

web worker這個api被造出來時，就是為了解放主線程。因為，瀏覽器中的JavaScript都是運行在單一個線程上，隨著web業務變得越來越復雜，js中耗時間、耗資源的運算過程則會導致各種程度的性能問題。

而web worker由于獨立于主線程，則可以將一些復雜的邏輯交由它來去做，完成后再通過postMessage的方法告訴主線程。service worker則是web worker的升級版本，相較于后者，前者擁有了持久離線緩存的能力。

3.3 V3版表格

在開發V2表格時，我們意識到數據處理部分不應該交給前端，列拼接上摻雜了太多的業務場景處理，另外渲染性能和崩潰問題急需解決，對此我們進行了V3版本迭代，提前對表格版本進行了技術升級，為之后的新一批列匯總行匯總，分組小計等高級交叉分析需求做好技術儲備。

1. 技術選型

我們對比了react，vue及canvas生態有代表性的表格組件。綜合三者優劣勢最終確定了基于react的table組件。

S2：https://github.com/antvis/S2

ali-react-table：

https://github.com/alibaba/ali-react-table

vxe-table：

https://github.com/x-extends/vxe-table/tree/v2

vxe-table設計初衷是解決單元格編輯的問題，主要用于大量增刪改查的場景，性能不是它唯一的目標；S2是建立在電子表格需求上的，對篩選、排序、搜索、復制、框選、聚合分析都有訴求。

同時需要在大數據量下保持高性能，解決之前商業軟件版本實現的性能問題和拓展性問題，所以它覆蓋的場景更全更復雜，但是它的缺點就是定制型不強，不太適合我們自身的業務。

所以最終我們選擇了ali-react-table，它本身體積小，在基礎能力都滿足的情況下，擴展新功能也很容易，而且在大數據量渲染下有高性能的優勢。

2. 架構設計

后端接口返回數據和配置部分，基于渲染模型：左樹 + 上樹 => 表格，根據配置生成左樹leftTree和上樹topTree，構造數據源，參照了ant-design的Table組件數據源構造的流程，與自身的pipeline插件機制結合，實現了表格的交互操作（排序，篩選，分頁）。

由于本項目里接入了微前端架構，采用了loadApp的方式實現了異構應用混合開發：

圖片

運作流程圖如下：

3. 升級實踐

（1）架構升級：

（2）底層渲染：

虛擬滾動：長列表渲染受制于瀏覽器本身限制，在大量DOM下，會達到瀏覽器本身的渲染瓶頸，在這種情況下，虛擬滾動可以解決這種渲染問題，它是一種按需渲染的理念的體現。所以虛擬列表是一種根據滾動容器元素的可視區域來渲染長列表數據中某一個部分數據的技術。

大致原理如下圖：

我們發現長列表在展示時，用戶只會關注可視區域，其他非可視區域部分，我們可以把已經渲染的DOM銷毀，不需要立即渲染的DOM延后。所以優化策略就是只渲染可見區域的內容。

在滾動事件觸發后，根據滾動 Offset 調整相應渲染的內容即可。在用戶看來，還是一個完整的長列表。這種懶加載的方式，和早期頁面圖片資源懶加載和非必須資源異步加載屬于同一種思路。

在新版版本里，ali-react-table自帶了虛擬滾動的特性，在大列表下，框架會自動開啟，可以明顯提升表格渲染性能和滾動的性能。

四、同類產品對比

4.1 技術架構對比

1. Quick BI

① 架構設計

② 技術實現

• 使用原生div和flex布局，不使用原生table表格
• 列寬，固定列，固定表頭等表格不好實現的問題，都易實現，渲染性能也較好
• 有2個版本的表格，舊版表格使用table，在這種情況下，性能，復雜交互，分組都存在瓶頸，這一點和我們類似，新老版本的表格同時在線上應用
• 虛擬滾動支持橫向，縱向滾動

③ 優劣勢

• ali-react-table不維護了，源碼不太復雜，可以二次迭代開發；基本滿足交叉表所有功能；大數據量下渲染高性能
• 接口數據略冗余

④ 備注

• 數據結構明確行維、列維、指標列數據；
• 數據匯總和小計是存放在后端

2. 敏捷BI

① 架構設計

圖片

② 技術實現

• 使用table布局
• 使用position:sticky實現固定列；固定表頭使用獨立的單表頭表格模擬，這里需要強制table設置列寬，保證列對齊
• 支持橫向，縱向虛擬滾動，在10w列下依然可以正常渲染
• 在ali-react-table基礎上擴展了按維度合并，表頭篩選等feature

③ 優劣勢

• flex布局靈活，不受表格本身布局限制，易實現固定列和表頭，列寬；canvas開發成本較高，bug不好調試
• 接口數據更精簡

④ 備注

• 數據結構不明確，需要對二維數組轉換，存在一定的預處理邏輯；
• 數據結構存在冗余現象

4.2 應用場景對比

以實際測試為準

1. Quick BI

業務場景

（1）字段配置

• 行：數據集的維度字段拖拽到行選擇區
• 列：數據集里的維度或者度量字段拖拽到列選擇區
• 過濾器：數據集字段拖拽到過濾器選擇區，對字段進行篩選

（2）樣式配置

• 標題與卡片：設置標題樣式
• 備注和尾注：設置圖表備注和尾注內容
• 組件容器：設置內邊距和背景色，圓角
• 展示型配置：設置主題，表頭樣式，內容樣式，凍結列，序號等配置
• 功能型配置：條件格式配置，針對字段滿足特定條件下突出顯示配置的樣式
• 總計配置：支持列匯總和行匯總，行總計和行小計，列總計和列小計

（3）高級配置

• 聯動：圖表里的字段與其他圖標關聯
• 跳轉：圖表字段跳轉傳值

 技術實現

• 實現使用原生，未使用第三方庫
• 自定義主題使用主色編輯
• 拖拽方式交互

2. 網易有數

業務場景

• 沒有復雜的交叉表場景，只支持普通明細表
• 配置方式主要包括主題，表頭，內容的字體樣式，背景，對齊等樣式
• 支持下鉆，字段跳轉
• 數據集字段支持維度層級和組的概念
• 沒有虛擬滾動

 技術實現

• 內部使用table表格實現
• 主題配置支持上傳主題json文件

3. 敏捷BI

（1）字段配置

• 行維：數據集維度字段放置區
• 列維：數據集維度字段放置區
• 指標：數據集指標字段

（2）圖表屬性和圖表樣式配置

• 支持條件格式，自定義代碼樣式嵌入，主題配置

（3）字段過濾

• 使用字段過濾數據

 技術實現

• 最開始使用smooth-dnd庫，來實現從數據集字段拖拽到行列、指標區
• 因為smooth-dnd有性能問題，不再維護等問題，就廢棄掉了，使用原生的拖拽實現
• 主題使用在線代碼編輯主題，基于codemirror在線代碼，接入css variables，實時應用，不需要刷新

4.3 部分核心代碼實現

應用場景① ：表頭篩選

代碼實現

應用場景②：按維度合并

代碼實現

4.4 渲染性能對比

1. Quick BI

（1）數據量級 <50列

• 接口耗時300ms 接口大小<5kb
• 渲染耗時 < 1s

注：數據量不是很大的情況下，數據加載忽略不計，合入到數據渲染時間，差別不大

（2）數據量級 ≥ 200列

• 接口耗時1.88s 接口大小<10kb
• 表格渲染 < 3s

注：數據量很大的情況下，數據加載需要單獨計入時間

（3）數據量級 > 1W列

極端情況下，表格渲染崩潰

圖片

2. 敏捷BI

（1）數據量級 <50列

• 接口耗時250ms 接口大小~100kb
• 渲染耗時 < 1s

（2）數據量級 ≥ 200列

• 接口耗時300ms 接口大小~300kb
• 渲染耗時 <3s

（3）數據量級 > 1W列

• 接口耗時2s 數據大小2M
• 渲染耗時~10s

4.5 總結

網易有數表格組件較為簡單，只有簡單的數據展示和排序篩選，適用于明細數據展示場景。

Quick BI表格和敏捷BI在交互，可視化能力，業務場景上都保持著同樣的功能，底層實現 Quick BI采用原生DIV+Flex布局模擬表格實現，在渲染上比表格會有渲染的優勢，這點是瀏覽器自身渲染機制決定，我們內部實現需要滿足極端數據量下數據展示，所以特定做了橫向的虛擬列表優化，這種場景看業務需求，否則表格會過于復雜，得不償失。

表格渲染性能基本與Quick BI性能相當，極端情況下，敏捷BI依舊可以正常渲染，這點優于Quick BI。

五、規劃

• 數據預處理部分不由前端處理，交給后端，和后端協調好返回的數據結構，直接返回；
• 表格擴展的功能與表格耦合嚴重，表格渲染不夠純凈；
• 開發一個Headless UI，不依賴渲染框架，提供一個數據適配層，同時支持在Vue3生態上使用。