爲何你的「開發速度」和「產品性能」，都比不過競品？丨開發者必讀

物理學家牛頓曾經說過：If I have seen further， it is by standing on the shoulders of giants。

荀子在《勸學》中也說過：假輿馬者，非利足也，而致千里；假舟楫者，非能水也，而絕江河。君子生非異也，善假於物也。

他們所表達的意思實際上是一致的，不少事情僅僅靠本身的力量是難以解決的，但若是咱們懂得利用工具就可以輕鬆完成。

在項目開發中也是如此，開發者們也要懂得「善假於物」和「站在巨人的肩膀上」，合理的使用第三方工具，同樣能夠實現事半功倍的效果。

隨着移動互聯網的發展，大部分中小企業比拼的不只僅是產品功能，而是產品交付速度、質量、性能以及針對特定場景的定製能力。所以，對於底層技術和架構而言，徹底能夠藉助垂直領域的第三方工具，提升開發速度，並獲得更好的產品性能。

以企業最廣泛的場景 —— 表格爲例，與你們探討，第三方工具是如何幫助開發人員解放生產力，又是如何幫助他們優化產品性能和用戶體驗，從而保證爲最終用戶提供更具價值和更高質量的產品。

1、前言

你們應該都知道，不少企業的 IT 業務是從一張表格開始的。團隊溝通中的信息共享大量依賴於表格，文檔、報告、憑證以及基礎數據的彙總分析，大部分都須要依靠表格的形式來進行決策的支持。

而伴隨着企業數字化轉型的迫切須要，遠程辦公模式已正式開啓，純在線的表格產品儼然成爲了不少企業必備的工具之一。但綜合性的協同辦公產品大部分將更多的精力投入在了文檔工具的優化當中，對於表格場景並無投入足夠多的時間與精力；另外一方面表格產品看似很簡單，但背後其實涉及到不少的技術實現，以及產品團隊對於表格場景的熟悉度處理，目前的泛用性在線表格工具都很難具有相應的經驗與能力。

所以，若是想要在企業 OA 系統中實現相似 Excel 的在線表格分析功能，爲了不耗費大量的開發精力卻只獲得一個」雞肋產品「，最好的辦法就是接入更專業的前端表格控件做爲輔助。雖然，這類控件數量衆多，但通過個人調查研究，能把「表格技術」這一細分場景發揮到極致的產品屈指可數。

究其緣由，這些產品大多未攻克如下四個技術難點。

2、表格控件的四大技術難點

B/S 做爲 Web 興起以後的一種網絡結構模式，統一了客戶端，將系統功能實現的核心部分集中到服務器上。

但隨之而來的問題是多瀏覽器差別、瀏覽器沙箱機制、內存訪問受限、客戶端性能低下等。做爲數據載體的表格，最直接的影響就是常常會被「吐槽」卡頓，UI 界面「假死」，界面操做不流暢等。

引發這些問題的癥結在於瀏覽器渲染引擎的基礎原理：當界面元素越多，瀏覽器的渲染時間會顯著增加，內存消耗會越大。這對於強計算邏輯的前端表格控件來講，無疑是棘手的難題。

因而可知，開發一款前端表格控件須要攻克這四個技術難點：性能、內存消耗、可靠性和操做體驗。

一、性能

現代應用程序爲了追求更好的用戶體驗，須要對 UI 界面反覆優化，而頻繁的修改界面 UI 元素，將引起屢次瀏覽器重繪。在這個過程當中，UI 元素的建立及修改，會激活內部垃圾回收機制，影響數據處理效率。

除此以外，前端開發環境的多樣化、各種高 DPI 設備、手機、平板、4K 顯示屏、企業大屏等，這些無不加劇了企業應用系統的處理負擔。

爲此，業內目前最佳的解決方案是使用 Canvas 繪製模型。

Canvas 主要用於在網頁上繪製圖像，能夠將其理解爲畫布，開發者們在這個畫布上構建想要的效果。它與在瀏覽器中運行的其餘應用有所不一樣，因爲 Canvas 只在屏幕上特定的區域執行並顯示效果，能夠說它的功能是獨佔的，所以不太會受到頁面上其餘內容的影響，反之也是如此。

做爲一種不依賴於瀏覽器解析的方式，使用 Canvas 繪製模型不只能夠解決性能問題，和 DOM 相比還提供了不失真的頁面打印，作到所見即所得。

二、內存消耗

隨着前端工程化的高速發展，各類前端工程腳手架日漸成熟，WebComponent 標準被提上日程，企業開始由 C/S 向 B/S 應用轉型。爲了優化內存，這就要求前端開發者，須要面對單線程處理複雜業務數據的挑戰。

對於表格控件這類鬆散的文檔結構，業內目前的最佳實踐是採用稀疏矩陣存儲模型（Sparse Array)來保存數據。

稀疏矩陣在機器學習方面是很常見的。因爲稀疏矩陣含有許多數值爲零的元素，能夠用來壓縮矩陣對象的內存檯面空間，或者加速多數機器學習程序。

而在表格場景中，相較於傳統的鏈式存儲或數組存儲，稀疏矩陣存儲構建了基於行索引的數據字典，在鬆散佈局的表格數據中，稀疏矩陣只會對非空數據進行存儲，而不須要對空數據開闢額外的內存空間。

這種特殊的存儲策略，不只節省了內存消耗，也使得數據片斷化變得更加容易。藉助這個特性，開發者甚至能夠隨時替換或恢復整個存儲結構中的任何一個級別的節點，實現高效的數據回滾和數據恢復。

三、可靠性

傳統前端表格應用計算的特色，是沒有穩定的框架計算器、語言計算精度差、表格計算依賴複雜。

隨着企業數字系統應用的愈來愈深刻，業務計算方式也變的愈來愈複雜，靈活度要求也愈來愈高。爲了解決這個問題，必須瞭解計算引擎的計算流程後進行相應的可靠性優化。

如圖所示是計算引擎在構建計算依賴鏈時的一個簡單的流程圖。表達式樹從計算存儲模型中找到對應的根節點以及根節點標識，隨後遍歷整個表達式樹，找出其餘依賴標識，構建依賴關係。

當整個依賴鏈中的任意節點發生變化時，若是沿着這條依賴鏈，能夠查找依賴節點並進行重算，那麼在這個過程當中，沒有在依賴鏈中的節點是不會發生重算計算的，也就是咱們所說的沒有髒值運算。

進行這樣的機制優化後，能夠大幅提高表格產品的運算速度，從而提供更好的使用體驗和更加精準的運算結果。

四、操做體驗

隨着業務場景的豐富，表格系統須要承載更多的功能。例如觸摸支持、富文本支持、前端 Excel 導入導出、JSON 存儲等。

咱們以觸摸支持爲例，隨着大屏時代的來臨，觸摸操做成爲了一項愈發廣泛的使用場景。對於觸摸來講，不少時候最難的並非技術實現，而是對於場景的理解。用手機操做技術文檔，單擊單元格時，對應的位置是放大仍是不放大？

對於不一樣的場景，用戶須要的反饋是不一樣的，對於一款優秀的前端表格控件來講，這的確是技術難點，但卻值得每一位開發者深刻思考，並積極尋求優化方案。

---

在一切以用戶體驗爲中心的互聯網時代，任何開發活動都應該以改善用戶體驗爲終極目標，產品優化固然也不例外，而且，產品優化最忌陷入純粹爲了追求技術極限而優化的境地。

而上述四個技術難點，在我和葡萄城的 SpreadJS 產品技術團隊詳細溝通後，也獲得了充分的驗證，由於，這一樣是他們的客戶在實際應用場景中最常面臨的問題。

SpreadJS 純前端表格控件，由業內最先進行表格產品研發的技術團隊——葡萄城推出，現在已完美復刻了 Excel 的 UI 佈局、數據透視表、450多種計算公式和182種形狀，只要是涉及到 Excel 文件上信息化系統的場景，他們的產品功能都已經覆蓋到了。

而用戶之因此勇於用 SpreadJS 替代傳統 Excel，正是基於其產品層面已經完成了大量的優化和迭代任務。據我瞭解，SpreadJS 在性能優化方面除了引入了 Canvas 繪製模型，還率先使用了雙緩存畫布技術，從而解決了常見的閃屏問題；此外還提供了支撐複雜邏輯運算的計算引擎，能夠幫助開發者打造一個長久穩定且可靠的應用系統。

想要在產品層面進行優化，一方面須要「吃透」表格產品的底層技術邏輯，另外一方面須要有大量實際的場景應用實踐，這偏偏想要作獨立開發的企業或者泛用性工具平臺所不具有的，而藉助 SpreadJS 這類專一於垂直領域的表格控件工具，則能夠達到事半功倍的效果。

3、結語

正如咱們前面所說，開發一款前端表格控件最難的不是技術，還有對錶格產品的熟悉程度。由於純技術的問題，在不少時候是難不住開發者的，靠時間與精力的投入總能彌補。然而，一款真正優秀的產品最重要的一點，則是對於應用場景，以及用戶使用體驗的細節把控。

就像在表格類工具中有一個算投資回報率的公式，幾乎沒有人知道這個公式用 Excel、Google Doc 算出來的結果是不一致的。而這個小到會被全部人忽略的細節，也是 SpreadJS 的研發團隊告訴個人。

隨着社會的發展，市場須要更靈活、效率更高的開發者解決方案，企業也要同時追求」開發速度「與」產品性能「，這在傳統的開發思路中是不可兼得的，但若是作到善假於物，藉助第三方工具平臺則能夠徹底實現。

付出一些成本換來更大的發展機會與空間，誰又能說不是一筆好買賣？

文中資源擴展閱讀：
SpreadJS 官網： https://www.grapecity.com.cn/...