物理學家牛頓曾經說過：If I have seen further， it is by standing on the shoulders of giants。
荀子在《勸學》中也說過：假輿馬者，非利足也，而致千里；假舟楫者，非能水也，而絕江河。君子生非異也，善假於物也。
他們所表達的意思其實是一致的，很多事情僅僅靠自己的力量是難以解決的，但如果我們懂得利用工具就能夠輕鬆完成。
在專案開發中也是如此，開發者們也要懂得“善假於物”和“站在巨人的肩膀上”，合理的使用第三方工具，一樣可以實現事半功倍的效果。
隨著移動網際網路的發展，大部分中小企業比拼的不僅僅是產品功能，而是產品交付速度、質量、效能以及針對特定場景的定製能力。因此，對於底層技術和架構而言，完全可以藉助垂直領域的第三方工具，提高開發速度，並得到更好的產品效能。
以企業最普遍的場景 —— 表格為例，與大家探討，第三方工具是如何幫助開發人員解放生產力，又是如何幫助他們優化產品效能和使用者體驗，從而保證為終端使用者提供更具價值和更高質量的產品。
一、前言
大家應該都知道，很多企業的 IT 業務是從一張表格開始的。團隊溝通中的資訊共享大量依賴於表格，文件、報告、憑證以及基礎資料的彙總分析，大部分都需要依靠表格的形式來進行決策的支援。
而伴隨著企業數字化轉型的迫切需要，遠端辦公模式已正式開啟，純線上的表格產品儼然成為了很多企業必備的工具之一。但綜合性的協同辦公產品大部分將更多的精力投入在了文件工具的優化當中，對於表格場景並沒有投入足夠多的時間與精力；另一方面表格產品看似很簡單，但背後其實涉及到很多的技術實現，以及產品團隊對於表格場景的熟悉度處理，目前的泛用性線上表格工具都很難具備相應的經驗與能力。
因此，如果想要在企業 OA 系統中實現類似 Excel 的線上表格分析功能，為了避免耗費大量的開發精力卻只得到一個”雞肋產品“，最好的辦法就是接入更專業的前端表格控制元件作為輔助。雖然，這類控制元件數量眾多，但經過我的調查研究，能把“表格技術”這一細分場景發揮到極致的產品屈指可數。
究其原因，這些產品大多未攻克以下四個技術難點。
二、表格控制元件的四大技術難點
B/S 作為 Web 興起之後的一種網路結構模式，統一了客戶端，將系統功能實現的核心部分集中到伺服器上。
但隨之而來的問題是多瀏覽器差異、瀏覽器沙箱機制、記憶體訪問受限、客戶端效能低下等。作為資料載體的表格，最直接的影響就是經常會被“吐槽”卡頓，UI 介面“假死”，介面操作不流暢等。
引起這些問題的癥結在於瀏覽器渲染引擎的基礎原理：當介面元素越多，瀏覽器的渲染時間會顯著增長，記憶體消耗會越大。這對於強計算邏輯的前端表格控制元件來說，無疑是棘手的難題。
由此可見，開發一款前端表格控制元件需要攻克這四個技術難點：效能、記憶體消耗、可靠性和操作體驗。
1、效能
現代應用程式為了追求更好的使用者體驗，需要對 UI 介面反覆優化，而頻繁的修改介面 UI 元素，將引發多次瀏覽器重繪。在這個過程中，UI 元素的建立及修改，會啟用內部垃圾回收機制，影響資料處理效率。
除此之外，前端開發環境的多樣化、各類高 DPI 裝置、手機、平板、4K 螢幕、企業大屏等，這些無不加重了企業應用系統的處理負擔。
為此，業內目前最佳的解決方案是使用 Canvas 繪製模型。
Canvas 主要用於在網頁上繪製影像，可以將其理解為畫布，開發者們在這個畫布上構建想要的效果。它與在瀏覽器中執行的其他應用有所不同，由於 Canvas 只在螢幕上特定的區域執行並顯示效果，可以說它的功能是獨佔的，因此不太會受到頁面上其他內容的影響，反之也是如此。
作為一種不依賴於瀏覽器解析的方式，使用 Canvas 繪製模型不僅可以解決效能問題，和 DOM 相比還提供了不失真的頁面列印，做到所見即所得。
2、記憶體消耗
隨著前端工程化的高速發展，各種前端工程腳手架日漸成熟，WebComponent 標準被提上日程，企業開始由 C/S 向 B/S 應用轉型。為了優化記憶體，這就要求前端開發者，需要面對單執行緒處理複雜業務資料的挑戰。
對於表格控制元件這類鬆散的文件結構，業內目前的最佳實踐是採用稀疏矩陣儲存模型（Sparse Array)來儲存資料。
稀疏矩陣在機器學習方面是很常見的。由於稀疏矩陣含有許多數值為零的元素，可以用來壓縮矩陣物件的記憶體檯面空間，或者加速多數機器學習程式。
而在表格場景中，相較於傳統的鏈式儲存或陣列儲存，稀疏矩陣儲存構建了基於行索引的資料字典，在鬆散佈局的表格資料中，稀疏矩陣只會對非空資料進行儲存，而不需要對空資料開闢額外的記憶體空間。
這種特殊的儲存策略，不僅節省了記憶體消耗，也使得資料片段化變得更加容易。藉助這個特性，開發者甚至可以隨時替換或恢復整個儲存結構中的任何一個級別的節點，實現高效的資料回滾和資料恢復。
3、可靠性
傳統前端表格應用計算的特點，是沒有穩定的框架計算器、語言計算精度差、表格計算依賴複雜。
隨著企業數字系統應用的越來越深入，業務計算方式也變的越來越複雜，靈活度要求也越來越高。為了解決這個問題，必須瞭解計算引擎的計算流程後進行相應的可靠性優化。
如圖所示是計算引擎在構建計算依賴鏈時的一個簡單的流程圖。表示式樹從計算儲存模型中找到對應的根節點以及根節點標識，隨後遍歷整個表示式樹，找出其他依賴標識，構建依賴關係。
當整個依賴鏈中的任意節點發生變化時，如果沿著這條依賴鏈，可以查詢依賴節點並進行重算，那麼在這個過程中，沒有在依賴鏈中的節點是不會發生重算計算的，也就是我們所說的沒有髒值運算。
進行這樣的機制優化後，可以大幅提升表格產品的運算速度，從而提供更好的使用體驗和更加精準的運算結果。
4、操作體驗
隨著業務場景的豐富，表格系統需要承載更多的功能。例如觸控支援、富文字支援、前端 Excel 匯入匯出、JSON 儲存等。
我們以觸控支援為例，隨著大屏時代的來臨，觸控操作成為了一項愈發普遍的使用場景。對於觸控來說，很多時候最難的並不是技術實現，而是對於場景的理解。用手機操作技術文件，單擊單元格時，對應的位置是放大還是不放大？
對於不同的場景，使用者需要的反饋是不同的，對於一款優秀的前端表格控制元件來說，這的確是技術難點，但卻值得每一位開發者深入思考，並積極尋求優化方案。
在一切以使用者體驗為中心的網際網路時代，任何開發活動都應該以改善使用者體驗為終極目標，產品優化當然也不例外，並且，產品優化最忌陷入純粹為了追求技術極限而優化的境地。
而上述四個技術難點，在我和葡萄城的 SpreadJS 產品技術團隊詳細溝通後，也得到了充分的驗證，因為，這同樣是他們的客戶在實際應用場景中最常面臨的問題。
SpreadJS 純前端表格控制元件，由業內最早進行表格產品研發的技術團隊——葡萄城推出，如今已完美復刻了 Excel 的 UI 佈局、資料透視表、450多種計算公式和182種形狀，只要是涉及到 Excel 檔案上資訊化系統的場景，他們的產品功能都已經覆蓋到了。
而使用者之所以敢於用 SpreadJS 替代傳統 Excel，正是基於其產品層面已經完成了大量的優化和迭代任務。據我瞭解，SpreadJS 在效能優化方面除了引入了 Canvas 繪製模型，還率先使用了雙快取畫布技術，從而解決了常見的閃屏問題；此外還提供了支撐複雜邏輯運算的計算引擎，可以幫助開發者打造一個長久穩定且可靠的應用系統。
想要在產品層面進行優化，一方面需要“吃透”表格產品的底層技術邏輯，另一方面需要有大量實際的場景應用實踐，這恰恰想要做獨立開發的企業或者泛用性工具平臺所不具備的，而藉助 SpreadJS 這類專注於垂直領域的表格控制元件工具，則可以達到事半功倍的效果。
三、結語
正如我們前面所說，開發一款前端表格控制元件最難的不是技術，還有對錶格產品的熟悉程度。因為純技術的問題，在很多時候是難不住開發者的，靠時間與精力的投入總能彌補。然而，一款真正優秀的產品最重要的一點，則是對於應用場景，以及使用者使用體驗的細節把控。
就像在表格類工具中有一個算投資回報率的公式，幾乎沒有人知道這個公式用 Excel、Google Doc 算出來的結果是不一致的。而這個小到會被所有人忽略的細節，也是 SpreadJS 的研發團隊告訴我的。
隨著社會的發展，市場需要更靈活、效率更高的開發者解決方案，企業也要同時追求”開發速度“與”產品效能“，這在傳統的開發思路中是不可兼得的，但如果做到善假於物，藉助第三方工具平臺則可以完全實現。
付出一些成本換來更大的發展機會與空間，誰又能說不是一筆好買賣？
文中資源擴充套件閱讀：
SpreadJS 官網：https://www.grapecity.com.cn/...
