大文檔首屏渲染的一些思考和嘗試

大文檔首屏渲染方案的一些思考和嘗試

最近在處理一些優化方面的東西， 大文檔渲染的優化方案。 這裏簡單記錄分享一下。

1、服務端渲染

• 優勢：服務端性能比較好，對移動端手機做用明顯
• 缺點：大文檔渲染完可能體積比較大，網絡傳輸佔時間比以前多，sheet仍是得回到前端渲染，得維護一套node代碼，增長成本

2、分片滑動加載渲染

• 優勢：因爲只渲染到首屏和預加載一到兩屏的文檔，速度炒雞快，理論上不會有邊界，能夠渲染任意大小的文檔
• 缺點：須要解決未加載徹底複製全文的bug，拉滾動條可能卡頓（參考Sheet插入Doc性能後續優化點文中說的拉動卡頓問題 ），CMD + F 沒法全文搜索，須要本身開發全文搜索的功能。須要修改Changeset計算的一些邏輯。

3、多線程分片拼接渲染

• 方案：利用webworker多線程，主線程將文檔分爲幾個塊，分發給worker，worker將這些塊輸出爲字符串，最後拼接輸出
• 優勢：能夠將主線程讓給sheet並行渲染，渲染速度應該會快，不存在二中缺點
• 缺點：理論上仍是存在邊界，超級大的文檔，仍是渲染時間會有天花板
• 我決定週末試一波

週日簡單開發了一下方案三

將580行約2w6千字的文檔，clientVars分爲三塊，分發給三個worker計算成html字符串。

渲染的核心代碼並無加入插件模塊，只簡單輸出字符串。

方案 render字符串出來的時間爲 ms

優化前: 380 ms

方案三處理以後: 1200ms...

尷尬的事情發生了，一頓操做猛於虎，一看戰績零槓五，居然是負優化。。。。

難受之餘，分析了一下1200ms時間的構成，發現從main thread到worker之間postMessage的時間是整個負優化的來源，多達900ms到1000ms。

看了worker的資料:

https://developers.google.com...

用Transferable Objects能大大提升postMessage的性能。

再試了一波，能把整個時間提高到780ms，仍然有400ms在的時間能夠優化。爲毛官方的 demo postMessage如此之快，我本身試的這麼慢呢？

緣由是個人worker的js至關的複雜，體積很大，每一個worker啓動的時候都須要去編譯這些js，因此致使了這個負優化的產生。理論上咱們能夠將各個plugin拆分爲只render和其餘的業務邏輯，能大大減小worker js的包體積。若是在包體積很差縮減的狀況下，也能夠採用預先初始化worker的方式來減小這個時間。這個方法能夠在web容器化的方案裏面使用.

後續

在文檔1100多行（約4w字）的時候，全文渲染的時間達到520ms，而此時多線程渲染依然保持在220ms左右.

結論

對於超大的文檔，多線程提高的結果是顯著的，而小一些的文檔500行左右，意義不大。對於Doc插sheet的渲染可能有一些做用，能夠把主線程讓給表格渲染。