国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

vueTable大數據展示優化

JasinYip / 2634人閱讀

摘要:懶加載方式常見的有淘寶一屏用元素占據一定的高度,然后再去拉圖片數據。但這種方式還是需要元素占位,淘寶一頁的數據量其實不算大,因為它結合了分頁。

背景


大數據項目根據用戶輸入代碼查詢數據,用戶的代碼不可控(比如select from db limit 5000),有可能一頁需求要求展示100行5000列數據。由于是用戶代碼實時查詢的數據,后端不可能將所有查詢結果都存儲。因此,查詢的結果是實時的、全量的,分頁和排序都需要前端去實現

現狀

剛開始的接手項目的時候完全不能展示十萬級的數量,chrome標簽頁直接崩潰。這個在分析了需求,展示數據不需要響應式后,用了Object.freeze()后就可以勉強展示十萬級數據。雖然還是卡頓,但是需求已經實現。(值得注意的是Object.freeze()并不是深度凍結,實際應用中對象要進行遞歸操作。)

下面圖展示的是100行乘以一千列,在左右拖拽0-150列。目前也對超過兩百列的數據進行橫向的懶加載操作,實現原理時監聽scroll事件滾動到末尾時截取對應下一組數據,然后將滾動條恢復到頭部。可以從gif中明顯感覺到這個過程是滾動條恢復到原狀之間耗時比較長。而且當用戶想要看前一組數據的最后一項和后一組數據的前一項時,js就要不停地做截取數據的操作重新渲染,開銷非常大。

利用chrome devtool performance進行性能分析。(進行性能分析時使用隱身模式避免chrome插件對結果分析造成偏差)

觀察FPS圖表,有幾段紅幀證明這過程中頁面超負荷,會出現卡頓響應緩慢等。

選中紅幀區域,Main區域發生變化,變為當前選擇時段的函數調用棧詳情。點擊會在下面的Summary里發現對應的信息以及警告提示回流可能為性能的瓶頸Forced reflow is a likely performance bottleneck.。對應的問題出在監聽scroll事件后出現的js代碼中,執行的次數非常多。不僅需要去讀取scrollLeft值,還因為重新渲染數據時使組件縱向高度發生了改變,進而多次觸發了element-ui組件的updateScrollY方法。從Screenshots可以看到這時剛好是數據移動到最后要對數據進行截取重新渲染。

從上圖summary可以看到js的運行壓力很大,勾選memory項紀錄js heap占用情況,查看到占用高達161mb-325mb

優化要點

table的數據并不會有修改的需要,僅僅是展示,并不需要響應式。Object.freeze()可以阻止vue追蹤屬性的變化,減少性能的開銷

由于數據展示的table不僅大量而且經常變換數據集。為了減少回流和重繪,table做絕對定位脫離文檔流,避免布局抖動。

由于后端返回的數據一組表頭和內容分開的數組,而開源element-ui的vue組件都是以key:value的形式,大量數據情況下僅僅是將數組轉化為key:value的形式就花費掉幾百毫秒的時間。開源組件能解決的是通用情況,這種情況下為了盡量減少開銷重寫適用于業務的table組件還是很有必要的。

//后端返回的格式
data = [
    columnName: ["col1", "col2", ……],
    columns: [
        ["1", "2", ……],
        ["1", "2", ……],
        ……
    ]
]
// 開源組件需要的格式
data = [
    {
        col1: "1",
        col2: "2",
        ……
    },
    {
        col1: "1",
        col2: "2",
        ……
    }
]

后端返回的數據量有可能高達百萬級,盡管前端進行分頁還是有可能要展示到數量達十萬。其中行最多每頁只展示100條,但是列由ide用戶執行的代碼決定,這里主要影響性能的是列數。列數有可能為1000條,模擬橫向懶加載,將拿回來的數組截取部分展示,減少頁面上的dom節點。但是目前模擬懶加載的方式用戶體驗不好。

為了解決橫向滾動時相鄰列的數據能夠展示在同一屏上,而不需多次來回切換,首先做的工作是在截取數據時保留前一屏的數據,拖動后滾動條回到中間位置,在一定范圍內不需要多次滾動才能查看。(如下圖)

- 但這種方式也是非常不友好,每次滾動到最后要去檢測用戶是否按著鼠標有沒有抬起,防止觸發多次數據重新渲染。因為這種情況下,用戶拖一次只能加載一組新數據,滾動條便回到了中間位置,如果用戶需要看到最后一組數據就要多次操作。正常的懶加載應該是有一條適應高度的滾動條拖拽,無縫連接。

- 懶加載方式常見的有:
    1. 淘寶一屏用元素占據一定的高度,然后再去拉圖片數據。滾動條便適應高度的拖動距離。但這種方式還是需要元素占位,淘寶一頁的數據量其實不算大,因為它結合了分頁。
    2. 掘金沸點的無限加載:掘金的方式是監聽到底部時,再去拉響應的數據追加,滾動條會自適應滾到相對應的地方。但是掘金這種懶加載一直加載數據沒有截取掉舊數據,所以滾動條距離也是一直適應數據的。嘗試將掘金沸點一直拖動到2000條,網頁已經開始有點卡頓。而在ide項目中,兩千條數據算是少量數據。
- 啟發于[https://github.com/tangbc/vue-virtual-scroll-list](vue-virtual-scroll-list),利用了padding值模擬了淘寶固定高度,不需要元素占位,模擬出全部數據量的滾動條縱向滾動距離,拖動時完全無感知數據的重新渲染。目前vue-virtual-scroll-list只支持縱向,但稍微改造下就能用在ide項目的橫向懶加載。(改造后如下圖,gif軟件錄制時稍微有點卡頓感)

scroll長時間運行的重新計算樣式事件,其時間如果超過 16.7 毫秒,并且恰好發生在滾動期間,導致用戶體驗到明顯的抖動。為了在拖動過程中數據變化以連貫、平滑進行過渡,函數節流改setTimeout為requestAnimationFrame(rAF),由系統來決定回調函數的執行時機;它能保證回調函數在屏幕每一次的繪制間隔中只被執行一次,這樣就不會引起丟幀現象,也不會導致渲染數據出現卡頓的問題,并且rAF能兼容到ie9以上了。

優化后結果分析

拖動幾百條數據截取的performance在FPS圖表中已經沒有最初的紅標,沒有Forced reflow,每幀的rendering也由rAF控制在16.7ms以內,js內存占用也從161mb-325mb,降低到157mb-196mb。

組件接口設計原則

復用性:配置參數的方式去差異化體現,參數的可配置性提高了組件的復用率和靈活性。
可維護性:組件化后,組件內部的邏輯只對組件負責,外部的邏輯只通過配置參數適配,提高了代碼的邏輯清晰度,可以快速定位代碼出現問題的地方。

這個組件設計時對外提供toLefttoRightonScroll事件,分別是滑動過程中到了頭、尾,及滑動過程的回調。提供了offsetremainbench參數表示剛渲染時的偏差,顯示的列數,及保留多少列在實際dom中。

小結

以前沒有想過js也會承受那么大的壓力,一點點優化都能顯著減輕內存。在寫代碼時要特別關注高頻事件的觸發,一切的優化方向就是在實現功能的前提下減少重新渲染的發生。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/98196.html

相關文章

  • 推薦給新手的35個好用的Vue開源庫

    摘要:無論是開發新手還是經驗豐富的老手,我們都喜歡開源軟件包。所幸的是,隨著社區的不斷壯大,每天都會出現一些很好的軟件包。在下文中,我們將推薦一些非常好用的開源庫是一個非常易用的漸進式框架,用于構建用戶界面。的一個極簡主義的深色設計系統。 無論是開發新手還是經驗豐富的老手,我們都喜歡開源軟件包。對于開發者來說,如果沒有這些開源軟件包,很難想象我們的生活會變得多么疲憊不堪,而且靠咖啡度日也會成...

    oliverhuang 評論0 收藏0
  • 一個通用的vue的表格組件

    摘要:在做業務組件的時候需要自己自己封裝一個通用的表格,這個表格需要符合我們一切的好的幻想,左右固定,表頭固定,分頁,選擇,一直表格內容的行數限制等等,下面就為大家介紹一下這一款表格組件功能以及怎么使用。 在做業務組件的時候需要自己自己封裝一個通用的表格,這個表格需要符合我們一切的好的幻想,左右固定,表頭固定,分頁,選擇,一直表格內容的行數限制等等,下面就為大家介紹一下這一款表格組件功能以及...

    caoym 評論0 收藏0
  • Vue前端開發規范

    摘要:正例復制代碼反例復制代碼組件數據組件的必須是一個函數。正例更好的做法復制代碼反例這樣做只有開發原型系統時可以接受復制代碼為設置鍵值總是用配合。這條規則只和單文件組件有關。基于Vue官方風格指南整理一、強制1. 組件名為多個單詞組件名應該始終是多個單詞的,根組件 App 除外。正例:exportdefault{name:TodoItem,//...}復制代碼反例:exportdefault{n...

    番茄西紅柿 評論0 收藏2637
  • 使用Performance對頁面進行分析優化(實戰篇)

    摘要:在此,我們可以使用懶加載方式對其進行優化,僅展示其對應類型的圖,避免了不必要的資源浪費和計算時間。 這篇文章將介紹下實際使用performance對頁面進行優化的過程。總的來說,chrome performance工具讓我們更方便的發現在代碼運行過程中的問題在哪里,便于對一些可能注意不到的問題進行定位、分析和優化。原文首發于個人博客 渲染優化 首先,我們對進入整個詳情頁進行分析,整個頁...

    luodongseu 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<