亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專欄INFORMATION COLUMN

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

Elle / 582人閱讀

大文檔首屏渲染方案思考

一、服務(wù)端渲染

優(yōu)點(diǎn)：服務(wù)端性能比較好，對(duì)移動(dòng)端手機(jī)作用明顯

缺點(diǎn)：大文檔渲染完可能體積比較大，網(wǎng)絡(luò)傳輸占時(shí)間比之前多，sheet還是得回到前端渲染，得維護(hù)一套node代碼，增加成本

二、分片滑動(dòng)加載渲染

優(yōu)點(diǎn)：由于只渲染到首屏和預(yù)加載一到兩屏的文檔，速度炒雞快，理論上不會(huì)有邊界，可以渲染任意大小的文檔

缺點(diǎn)：需要解決未加載完全復(fù)制全文的bug，拉滾動(dòng)條可能卡頓（參考Sheet插入Doc性能后續(xù)優(yōu)化點(diǎn)文中說的拉動(dòng)卡頓問題 ），CMD + F 無法全文搜索，需要自己開發(fā)全文搜索的功能。需要修改Changeset計(jì)算的一些邏輯。

三、多線程分片拼接渲染

方案：利用webworker多線程，主線程將文檔分為幾個(gè)塊，分發(fā)給worker，worker將這些塊輸出為字符串，最后拼接輸出

優(yōu)點(diǎn)：可以將主線程讓給sheet并行渲染，渲染速度應(yīng)該會(huì)快，不存在二中缺點(diǎn)

缺點(diǎn)：理論上還是存在邊界，超級(jí)大的文檔，還是渲染時(shí)間會(huì)有天花板

周日簡單開發(fā)了一下方案三

將580行約2w6千字的文檔，clientVars分為三塊，分發(fā)給三個(gè)worker計(jì)算成html字符串。渲染的核心代碼并沒有加入插件模塊，只簡單輸出字符串。

方案 render字符串出來的時(shí)間/ms

優(yōu)化前: 380

方案三: 1200

尷尬的事情發(fā)生了，一頓操作猛于虎，一看戰(zhàn)績零杠五，竟然是負(fù)優(yōu)化。。。。

難受之余，分析了一下1200ms時(shí)間的構(gòu)成，發(fā)現(xiàn)從main thread到worker之間postMessage的時(shí)間是整個(gè)負(fù)優(yōu)化的來源，多達(dá)900ms到1000ms。

看了worker的資料:

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

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

再試了一波，能把整個(gè)時(shí)間提升到780ms，仍然有400ms在的時(shí)間可以優(yōu)化。為毛官方的 demo postMessage如此之快，我自己試的這么慢呢？

原因是我的worker的js相當(dāng)?shù)膹?fù)雜，體積很大，每個(gè)worker啟動(dòng)的時(shí)候都需要去編譯這些js，所以導(dǎo)致了這個(gè)負(fù)優(yōu)化的產(chǎn)生。理論上我們可以將各個(gè)plugin拆分為只render和其他的業(yè)務(wù)邏輯，能大大減少worker js的包體積。如果在包體積不好縮減的情況下，也可以采用預(yù)先初始化worker的方式來減少這個(gè)時(shí)間。這個(gè)方法可以在web容器化的方案里面使用.

后續(xù)
在文檔1100多行（約4w字）的時(shí)候，全文渲染的時(shí)間達(dá)到520ms，而此時(shí)多線程渲染依然保持在220ms左右
結(jié)論：對(duì)于超大的文檔，多線程提升的結(jié)果是顯著的，而小一些的文檔500行左右，意義不大。對(duì)于Doc插sheet的渲染可能有一些作用，可以把主線程讓給sheet渲染。

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://www.ezyhdfw.cn/yun/95905.html

相關(guān)文章

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

    摘要：大文檔首屏渲染方案的一些思考和嘗試最近在處理一些優(yōu)化方面的東西，大文檔渲染的優(yōu)化方案。對(duì)于插的渲染可能有一些作用，可以把主線程讓給表格渲染。 大文檔首屏渲染方案的一些思考和嘗試 最近在處理一些優(yōu)化方面的東西， 大文檔渲染的優(yōu)化方案。 這里簡單記錄分享一下。 一、服務(wù)端渲染 優(yōu)點(diǎn)：服務(wù)端性能比較好，對(duì)移動(dòng)端手機(jī)作用明顯 缺點(diǎn)：大文檔渲染完可能體積比較大，網(wǎng)絡(luò)傳輸占時(shí)間比之前多，shee...

    shengguo 評(píng)論0 收藏0

  • 關(guān)于首屏時(shí)間采集自動(dòng)化的解決方案

    摘要：關(guān)于首屏首屏?xí)r間是指從轉(zhuǎn)向該頁面到屏幕中該頁面所有內(nèi)容都可見時(shí)的時(shí)間。如在事件處理函數(shù)中，計(jì)算高度，如果大于屏幕高度則意味著首屏的結(jié)構(gòu)已渲染完畢，開始計(jì)算首屏?xí)r間。 關(guān)于首屏 首屏?xí)r間是指從轉(zhuǎn)向該頁面到屏幕中該頁面所有內(nèi)容都可見時(shí)的時(shí)間。已經(jīng)有太多的關(guān)于首屏?xí)r間的計(jì)算，在本文中并不重復(fù)闡述這些已經(jīng)被提出或者實(shí)現(xiàn)的方案，而旨在探索與討論更多的首屏自動(dòng)化采集方案，擴(kuò)大思考范圍，你我思想之間...

    Rindia 評(píng)論0 收藏0

  • 關(guān)于首屏時(shí)間采集自動(dòng)化的解決方案

    摘要：關(guān)于首屏首屏?xí)r間是指從轉(zhuǎn)向該頁面到屏幕中該頁面所有內(nèi)容都可見時(shí)的時(shí)間。如在事件處理函數(shù)中，計(jì)算高度，如果大于屏幕高度則意味著首屏的結(jié)構(gòu)已渲染完畢，開始計(jì)算首屏?xí)r間。 關(guān)于首屏 首屏?xí)r間是指從轉(zhuǎn)向該頁面到屏幕中該頁面所有內(nèi)容都可見時(shí)的時(shí)間。已經(jīng)有太多的關(guān)于首屏?xí)r間的計(jì)算，在本文中并不重復(fù)闡述這些已經(jīng)被提出或者實(shí)現(xiàn)的方案，而旨在探索與討論更多的首屏自動(dòng)化采集方案，擴(kuò)大思考范圍，你我思想之間...

    1treeS 評(píng)論0 收藏0

  • 前端思考 - 收藏集 - 掘金

    摘要：并嘗試用為什么你統(tǒng)計(jì)的方式是錯(cuò)的掘金翻譯自工程師的文章。正如你期望的，文中的前端開發(fā)單一職責(zé)原則前端掘金單一職責(zé)原則又稱單一功能原則，面向?qū)ο笪鍌€(gè)基本原則之一。 單頁式應(yīng)用性能優(yōu)化 - 首屏數(shù)據(jù)漸進(jìn)式預(yù)加載 - 前端 - 掘金前言 針對(duì)首頁和部分頁面打開速度慢的問題，我們開始對(duì)單頁式應(yīng)用性能進(jìn)行優(yōu)化。本文介紹其中一個(gè)方案：基于 HTTP Chunk 的首屏數(shù)據(jù)漸進(jìn)式預(yù)加載方案，該方案總...

    LinkedME2016 評(píng)論0 收藏0

  • 前端網(wǎng)頁加載渲染鏈路優(yōu)化

    摘要：所以，關(guān)于優(yōu)化實(shí)戰(zhàn)我們主要分為兩部分加載渲染鏈路優(yōu)化和編程代碼優(yōu)化。加載渲染鏈路優(yōu)化從訪問到頁面呈現(xiàn)，整個(gè)鏈路可以做優(yōu)化的思路。資源緩存這一節(jié)我們單獨(dú)介紹緩存，是的，利用好緩存可以解決很多問題，包括頁面加載和渲染的問題都能得到很好的優(yōu)化。 優(yōu)化實(shí)戰(zhàn) 本文屬于思否課堂VirtualDOM到AST玩轉(zhuǎn)前端性能原理解析與代碼實(shí)戰(zhàn)課程官方博客：fed123.com 我們已經(jīng)全面分析總結(jié)了評(píng)估頁...

    zhaofeihao 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<