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

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

一、服務端渲染

• 優點：服務端效能比較好，對移動端手機作用明顯
• 缺點：大文件渲染完可能體積比較大，網路傳輸佔時間比之前多，sheet還是得回到前端渲染，得維護一套node程式碼，增加成本

二、分片滑動載入渲染

• 優點：由於只渲染到首屏和預載入一到兩屏的文件，速度炒雞快，理論上不會有邊界，可以渲染任意大小的文件
• 缺點：需要解決未載入完全複製全文的bug，拉滾動條可能卡頓（參考Sheet插入Doc效能後續優化點文中說的拉動卡頓問題 ），CMD + F 無法全文搜尋，需要自己開發全文搜尋的功能。需要修改Changeset計算的一些邏輯。

三、多執行緒分片拼接渲染

• 方案：利用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的渲染可能有一些作用，可以把主執行緒讓給表格渲染。