語雀在線表格自研之路

作者 | 遇春

趙勇，花名叫遇春，2009年加入阿里巴巴淘寶UED，2015年加入到螞蟻體驗技術部，目前在語雀團隊負責在線表格的研發工作。

背景介紹

語雀是螞蟻金服體驗技術部的一個創新產品，目前已經在商業化運作。面向個人和組織提供知識創作，組織，交流服務。如果你或者你的團隊有知識管理的需要，可以嘗試使用語雀。語雀一直很看中創作體驗，所以我們在編輯器這個領域一直持續的投入研發，不斷迭代，今天要介紹的就是我們自主研發的在線電子表格：

在準備這個分享的時候，我特意去看了下代碼的第一次提交記錄，是去年的5月29日，剛好一年的時間，在分享的前面，先給大家介紹下語雀電子表格這一年的研發時間表：

2019年

5月：立項
8月: beta版上線，具備基本的行列操作，基本樣式，合併單元格，篩選排序，支持插入鏈接，圖片，附件，checkbox，下拉選項等
9月：導入功能，多sheet，公式，統計欄，增加日期、貨幣、時間類型
10月：格式刷，圖片複製粘貼，支持附件預覽，邊框功能上線
11月：導出功能上線，實時協同上線，單元格保護功能
12月：圖表功能上線，選擇性粘貼

2020年：

1～3月：穩定性，兼容性，性能，體驗優化
4月：條件格式，下拉選項優化
5月：表格模版，篩選優化，顏色篩選

有興趣的同學可以到語雀的更新日誌裡瞭解更多詳情。

經過一年的研發，語雀已經能夠滿足 80～90% 普通 Excel 用戶的功能需求，以下是目前我們的功能集，接下來我們會控制新功能的上線節奏，會專門針對已有功能做深度優化，我們希望這些最基礎的功能，能夠給用戶帶來喜悅。

通過上述介紹，希望大家能對語雀目前的狀態有一個整體的瞭解。

接下來會分三部分介紹語雀的自研歷程：Why, How, What

在語雀團隊以及體驗技術部，不管做什麼，我們都會多問自己幾個為什麼，想透為什麼做往往比去思考怎麼做更重要。

Why：介紹我們在做表格前期的思考。

How：講的是怎麼做，以及研發過程中的一些方法和技術選型。

What: 談一談關於自研的一些心得。

WHY

這一部分我會介紹兩個問題：

為什麼做在線電子表格
為什麼選擇自研

為什麼做在線表格

電子表格起源
提到電子表格，大家可能最先想到的是 Excel，我們的一些用戶在向我們諮詢問題的時候也有的說“你們語雀的Excel做的怎麼怎麼樣”，我覺得這是 Excel 這麼多年來在大家心裡形成了根深蒂固的影響，認為表格就是Excel，但其實 Excel 並不是第一個電子表格軟件。第一個電子表格要追溯到 1978 年，美國的一個大牛 Dan Bricklin，在大學實驗室做的一款叫做 VisiCalc 的程序。

這是首次利用行列布局來完成數字的錄入和計算的軟件，雖然簡單，但已經具備瞭如今電子表格最核心的行列模型，當時人們做生意都是用筆記在賬本上，一條條記錄，到了月底要做彙總對賬，效率非常低，而且容易出錯，一旦出錯就得重頭算，所以 VisiCalc 一面世就獲得人們的喜愛。這款軟件當時就是安裝在蘋果2代的個人電腦上。

就是靠這款軟件，當時蘋果電腦 2 代打開市場，大賣特賣，喬布斯當年接受採訪時說電子表格促進了產業發展，VisiCalc 促成了蘋果的成功。

電子表格關鍵歷程

1985年：
Excel 1.0 面世，這版 Excel 是微軟專門為蘋果開發的軟件，後來蓋茨覺得給人寫軟件不過癮，就搞出來windows。這裡面還有一段喬布斯和蓋茨的一段恩怨故事。

1988年：
求伯君在小黑屋裡寫了14個月開發出來的一個國產辦公軟件 WPS，為國內程序員所敬仰。

1993年：
微軟推出Office辦公套件，將 Excel 捆綁進來，再後來就是 Excel 一騎絕塵，不斷迭代，幾乎沒有對手。

2006年：
出現了一個新鮮事物 Google Docs，所有程序員都看呆了，原來在網頁上可以實現客戶端辦公軟件的能力，這也一定程度掀起了前端行業的逐步繁榮。

2007年：
蘋果開發了自己的電子表格 Numbers, 這是一款體驗很棒的電子表格，不改蘋果一貫的簡單風格，但藏在裡面的有非常強大的功能，目前還不支持在線協同。

2011年：
微軟開始關注在線辦公體驗，推出在線版的 Office 365, 在線版的Excel體驗真的很一般。

2013年：
Airtable 出現，人們開始意識到，原來的電子表格可以這麼玩，這就是後面要說到底同構表。

2016年：
國內才陸續出現在線電子表格的產品，其中wps, 石墨在這塊做的比較早，再後來騰訊和飛書等大廠也開始跟進。

從上述持續40幾年的歷史長河中，電子表格始終保持著旺盛的生命力，功能不斷完善，從客戶端軟件走向線上，足以證明人們對數據處理的需求始終旺盛。
語雀與 DIKW 模型
再說回來，為什麼語雀要做電子表格，這得從一個詞來說起，那就是“知識”，知識怎麼定義。

語雀的產品定位是雲端知識庫，我們內部一直有一個有意思的討論就是：“什麼是知識”，知識和數據之間又有什麼關係，直到我們發現這個模型，早在1888年，就有人在思考這個問題，托馬斯·斯特爾那斯·艾略特在一本《The Rock》書中思考過知識，智慧，諮詢之間的關係，後來學者們逐步完善這樣一個模型，DIKW模型

數據層：數據是最原始的素材，這一層的關鍵任務是記錄，數據本身也具備信息屬性，但反應的更多的是過去，比如杭州市2019年每天的氣溫，溼度，降雨等數據。
信息層：從數據層中提煉一些濃度更高的信息，或者根據數據的關係進行統計分析，發現一些規律性，比如杭州的年平均氣溫，幾月份最熱，幾月份最舒服，這些信息已經足夠精煉，也已經具備了一定參考價值。
知識層：通常信息層已經具備生活和生產的指導性了，但信息層的信息還比較零碎，知識層則是結合更多維度的信息，有針對性，有目的性的將零碎的信息進行歸類，連接，產出一些更全面的信息，比如把全球近100年的氣象數據進行分析，就會發現地球溫度在上升，於是結合數據之間的關係，發現了溫室效應，經過驗證發現，二氧化碳是造成溫室效應的原因，這種知識的價值就更大了，所以：知識就是來源於生活，被大眾認可，最終能夠幫助人們作出決策的東西。
智慧層：隨著對知識的運用，人們通過收集到的數據就可以預測未來會怎樣發展，這就是智慧。

在這個模型中，可以很清楚的看到，要形成知識，人們首先要從數據處理中產出信息，在這一步表格就發揮了非常重要的作用。文檔則是從信息到知識的進一步整理，所以，作為要打造專業的雲端知識庫，我們在整個知識的產生過程中，自然不能缺失數據處理這一環。

為什麼自研

為什麼選擇自研，我記得小米有品的一個營銷負責人有一句話說的很好：“生活中99%的產品都值得被重新創造一次”。

作為電子表格這樣一款幾十年歷史的產品，如何重新創造？Airtable 給出了他的答卷，他更像一個在線版的 Database。其實，語雀曾經也在集團內部推出過一版類似 airtable 的同構表格，是基於 spreadjs 來做的，發現用戶並不是很買賬這個新鮮事物，加上後續的一些變故，我們停止繼續研發，因為總有一種手腳被束縛的感覺。

2018年，我們開啟了全面自研，先是 kindEditor 的作者隆昊老師的加盟, 語雀的文檔編輯器開始全面自研，上線後，性能上有了明顯的提升，而且後期的研發和維護效率非常高。用戶提的很多問題我們都能第一時間響應，快速解決，這次自研給我們團隊帶來了很大的信心，我個人也是從文檔表格開始進入編輯器領域。

2019年5月我們決定重啟表格的研發，拋開 Spreadjs, 全面自研，自研給我們帶來的底層的可控性，拓展性，而且從長期看，自研的綜合成本效率都很優，選擇自研你要慎重的考慮以下幾個因素：包括：模型，體驗，性能，研發，維護，業務等各種要素。

模型：數據模型是業務發展的根本，也是所有功能實現的基礎，掌握數據模型的設計，才有可能更好的滿足未來的業務和功能需要，自研可以完全掌控模型的設計。
體驗：廣義的體驗包含很多方面，包括性能，服務，這裡主要指狹義的體驗：交互體驗，自研可以更大程度的按照業務的需要來設計體驗，技術實現更加融為一體，而不是在別人的功能上打補丁。
性能：掌握模型就可以在關鍵性能的地方通過數據結構的優化來解決，架構也可以做針對性的設計
研發：從長期來看，自研的研發成本反而更低
維護：由於對底層掌控性，遇到問題修復起來更快。也不會遇到因為底層的缺陷而無法修復的問題
業務：自研可以根據業務需要來設計模型。更有拓展性。

HOW

用了什麼技術
一些技術方案選型的案例

用了什麼技術

首先是表格的前端架構圖，這是一個非常經典的 MVC 架構，Model 層處理數據，View 層有渲染部分以及工具欄和麵板等 UI 部分，渲染部分採用原生的 Canvas 進行繪製，UI 層用了 React,組件庫是antd,圖表用了antv，UI 層的事件收斂到 control層，handler去處理事件的參數以及准入規則，然後就交給 command 去執行數據操作，command裡會有一個history對象去維護一條條命令，包含執行這條命令的參數以及執行中需要攜帶的快照數據，方便撤銷並通過 websocket 協同服務將命令同步到其他用戶端，架構很簡單，在選擇技術方案上，語雀一直追求實用與簡單。

同構還是異構

我想分享的第一個選型是在設計模型時需要考慮的問題，關於產品的選型，也就是前面大家聽到的，同構表還是異構表

同構表：每一列數據具備相同的數據結構，比如文本，日期時間，這些在列頭定義，一旦定義好，整列的數據都會按這個數據結構來處理，所以他的數據格式屬性只需要定義在列頭即可
異構表：每一個單元格都可以設置自己的數據格式，整個表格更像一個行列布局的畫布，每個單元格可以設置公式，會更加靈活。

可以看出，他們各自有自己的優勢和劣勢，在數據處理上的實現差異也特別大。

該如何選擇，我們最終還是去看用戶的需求，會發現兩類非常經典的場景，一種是信息結構化，一種是數據處理，這兩種場景都非常重要

數據處理不用多說了，肯定要滿足。那信息結構化是什麼，就是利用表格天然的行列布局，讓信息佈局更合理，更容易理解。而信息結構化本身也是前面我們提到的，是知識形成過程中重要的環節，有時候結構化佈局也是知識的展現形態的一部分。有些信息必須通過表格才能更好的展現，比如元素週期表，而我們知道同構表是沒法做合併單元格的，在信息佈局能力上存在較大的缺陷，所以我們最終選擇了異構表。

多人協同編輯

多人實時協同一直是編輯領域最大的難題，表格編輯也同樣會遇到，而且會更加複雜，我們先從多人協同的模型說起：

兩個人同時基於一條基線開始編輯，當這兩條指令O1,O2,傳遞到對方那裡的時候，要進行變換(OT)，這裡是最細顆粒的OP，而通常對於表格操作，比如移動行列，可能會有上千條OP, 如果剛好另外一個用戶也做了類似的批量操作，那麼瞬間產生的大量OP傳遞到服務端，服務端需要花費很長時間來做OP轉換，這就是導致響應延遲，那麼用戶會進一步產生OP，造成更多的計算和延遲，形成擁塞。

對於表格的操作，我們可以看這張圖：

一個大的數據對象，執行一條command, 產生數條op, 如果同步op對性能有太大的挑戰，是否可以直接同步command？我們可以對比看兩種模型的差異性：

通過對比兩種方案：

我們最終選擇了基於 command 來做數據同步，每一條 command 會攜帶這條命令需要的參數值，傳遞到其他端，服務端不需要做操作變換，客戶端收到 command 後會直接運行，整個過程非常快，通常一條指令從發出到接收到指令可以在100ms以內甚至更快完成，我認為快速將指令同步到各端，是減少衝突的最好辦法。

我們知道，通常單元格編輯的指令並不會存在衝突，只有在做行列位置變換或者增減行列時才有可能出現衝突，那麼我們需要考慮的問題是：在 100ms 以內同時操作行列的概率有多大，從實際場景來看，這個概率非常小。我們再配合一些衝突後禁止撤銷等策略來防止數據的混亂。最終我們採用了一個權衡的方案，同步 Command。從使用效果看，已經能夠滿足大多數的協同場景。

單元格數量上限

做電子表格過程中會遇到很多極限邊界，比如最大的可計算的數，日期的可識別範圍等，接下來我們說說表格最大能支持多少單元格數量。

我們首先看看幾個有明確限制的競品，Google明確支持500w單元格，超過就會報警。飛書是50w，騰訊文檔是25w。Google是將數據存儲在服務端，運算也在服務端，所以其實理論上可以支持更大的數量，所以看上去只是單元格數量上限的差異，卻引來一個很重要的架構選型：數據運算在客戶端還是服務端。但其實選擇起來也不難，還是要回歸業務本身，在線電子表格的大多數場景都不會有那麼大的數據量，再基於兩個考慮點：

充分利用客戶端計算資源
保持架構簡單

我們選擇客戶端計算，就是將數據一次性加載到客戶端，在用戶的瀏覽器中進行計算，那麼這種模式下我們能支持到的最大單元格數量是多少呢？

我們做一個這樣的計算，以最小的存儲單元格，存儲一個十位數的數值，這裡只考慮存儲值，如果再加上格式，樣式，一個單元格大概需要20～200個字符，為了做本地的臨時存儲，我們採用了localstorage，上限是5M，（當然，有同學說可以使用 IndexedDB, 還是考慮簡單原則，IndexedDB的異步模型會使整個編程模型變複雜，能不用複雜的方案，我們儘量不用），利用 localstorage，可以支持的單元格數量上限是25w（10000行25列）。

在這個方案的基礎上，我們做了再次壓縮優化，最終可以做到250w單元格，當然這是在保證離線編輯時體驗無損的場景，如果是網絡環境好的時候，並且沒有大量公式和樣式的話，語雀表格可以支持更大量級。

我們看看在百萬量級下的數據編輯性能效果：

複製粘貼的破損修復

在表格的操作中，經常會遇到複製粘貼的操作來從其他地方搬運數據過來，比如從網頁，或者excel, numbers 將數據遷到線上，複製和粘貼在解決局部或少量數據的時候是最高效的，而通常我們從這些地方複製出來的表格都會遇到一些奇怪的問題，那就是破損。

像上圖這樣的複製行為，剪切板裡的html就會有奇怪的單元格 Td 或者 Tr 的丟失，對於表格來說，如果解析的時候缺少Tr,Td，那麼單元格的位置就容易解析錯誤，最終導致粘貼出來的數據錯亂，可以看下面的動畫
640 (1).gif
語雀表格在還原各種複製粘貼中的破損時，表現的更為出色