記一次vue長列表的內存性能分析和優化

時間 2020-07-26

原文原文鏈接

很久沒寫東西，博客又長草了，這段時間身心放鬆了很久，都沒什麼主題能夠寫了html

上週接到一個需求，優化vue的一個長列表頁面，忙活了好久也到尾聲了，內存使用和卡頓都作了一點點優化，還算有點收穫vue

寫的有點囉嗦，能夠看一下我是怎麼進行這個優化的，也許有點幫助呢node

這個長列表頁面，實際上是一個實時日誌上報的頁面，隨着頁面打開時間的增長，日誌數量也會增多，常規的頁面佈局和渲染免不了會遇到性能問題。git

使用了vue框架，框架內部的虛擬DOM和組件緩存已經作了一些優化，比起原生實現是有了一些優化處理。github

但這個頁面是用到element-ui的el-table組件，渲染出來的是表格數據列表，衆所周知，表格在渲染的時候須要繪製整個表格區，因此，web

第一步就是將表格實現改成其餘元素標籤實現chrome

這一步操做以後，其實沒什麼大的變化的，幾千條日誌（每條日誌還有不少信息）左右，滾動頁面明顯卡頓嚴重element-ui

而需求又改不了，日誌能夠展開查看詳情或收起，已經看過的日誌在下次看的時候不須要加載，新的日誌會實時添加進來緩存

之前在作大表格數據鼠標滑過行着色的時候，也有嚴重的卡頓，當時主要的優化手段是不對全部數據進行處理，僅處理視窗可見區域，也能夠在這裏試試，因此app

第二步就是僅渲染視窗可見的數據

這種方案的原理是使用一個大容器做爲滾動區域，裏面有一個內容區域，JS經過數據數量和每條數據的高度計算出內容區的高度，內容區用padding或絕對定位撐開滾動區域，讓容器可滾動，另外就是數據項了，滾動的時候，計算當前滾動位置scrollTop，再從數據項中找出各項的高度，從頭至尾計算出此時容器中放什麼數據

哈哈哈 ... 這文字描述簡直了，看不懂就不看了吧，能夠去看下別人的解說

知道原理以後，實現起來也不難，不過代碼就寫的比較凌亂了，仍是使用現成的比較成熟的vue插件吧，比較方便

複製粘貼一頓猛操做以後，頁面從新展示出來，想着應該能夠收工了吧

然鵝，測試的時候發現，頁面內存使用能夠達到一兩G，看來不只要優化卡頓，還要優化內存使用

還能遇到這種少見的頁面崩潰，也算是開了眼了

這個方案是把原先頁面應該渲染的全部DOM拆分出來，動態地渲染該渲染的部分，

因此就會有一個問題，動態計算須要時間，當滾動很是快的時候會有明顯的卡頓現象，因此

第三步就是進行函數節流，即控制scroll事件的處理，在規定的時間內僅觸發一次

// 函數節流，頻繁操做中間隔 delay 的時間才處理一次
function throttle(fn, delay) { delay = delay || 200; var timer = null; // 每次滾動初始的標識
    var timestamp = 0; return function() { var arg = arguments; var now = Date.now(); // 設置開始時間
        if (timestamp === 0) { timestamp = now; } clearTimeout(timer); timer = null; // 已經到了delay的一段時間，進行處理
        if (now - timestamp >= delay) { fn.apply(this, arg); timestamp = now; } // 添加定時器，確保最後一次的操做也能處理
        else { timer = setTimeout(function() { fn.apply(this, arg); // 恢復標識
                timestamp = 0; }, delay); } } }; var count = 0; window.onscroll = throttle(function(e) { console.log(e.type, ++count); // scroll
}, 500);

代碼參考

雖然改善不是很大，但好歹也是一種方案

接下來是針對這個磨人的內存佔用了，也花了蠻多時間去分析去定位，頭髮又少了幾根..

現象是這樣的：

剛進入頁面的時候，最初100條數據，僅渲染30條數據，內存就佔用了100+M

滾動的時候內存蹭蹭蹭往上漲，峯值能到幾個G，一段時間後又降低一部分

隨着數據總量的增多，內存最初的佔用和最後的佔用也不一樣

在常規滾動和快速滾動的時候，內存佔用也不一樣

最後發如今數據總量必定的時候，內存最大佔用量是固定的（垃圾回收以後）

嗯挺奇怪的，實際項目比較複雜，有其餘組件干擾，很差排除法分析

因此就從插件給的Demo 開刀，發現它的表現是一致的

分析要有數據，實驗和方案選取要有對比測試

因此使用Chrome DevTool 自帶的 Memory工具，另外爲了不Chrome插件的影響，在隱身窗口中進行調試

上面有個強制垃圾回收的按鈕，JS垃圾回收機制是什麼這裏就不說了，能夠去搜一下

目前垃圾回收方案主要都是標記清除法了，而實現主要是根據GC根往下一層層遍歷，遍歷不到的對象會被垃圾回收掉，當某些對象本應該被回收，但仍是能從GC根訪問的時候，就產生了內存泄漏，主要須要考慮兩類內存泄漏：普通JS的對象，遊離的DOM節點（本該被回收，卻還有對象引用它）

垃圾回收的時間點是不固定的，隨機的，咱們在代碼中無法控制

點擊左邊的第一個小圓圈就能夠開始分析了，通常來講分析以前都會自動進行垃圾回收，不過爲了更準確，能夠再強制點按鈕回收一次

經常使用的主要就是兩種分析方式：

第一種是進行堆快照（JS的對象通常放在堆中），查看當前的內存分佈狀況

第二種是進行內存時間線分析，查看一頓操做以後的內存增加狀況，主要針對這個操做過程（這個時候能夠結合Performance標籤功能中來分析）

上圖中左側是兩個快照的結果，64.5M是進入頁面以後的內存快照，149M是各類操做以後的內存快照

<VirtualList :size="50" :remain="6" :bench="44" class="list" :start="startIndex" :debounce="10">
            <Item v-for="(udf, index) of items" :index="index" :key="index"></Item>
        </VirtualList>

這個長列表總共10w條數據，僅僅渲染了50條（6 + 44）數據，每條數據僅僅是短短的字符串，不應占用這麼多內存

去看下內存具體佔用狀況

內容有點多，由於用的是vue，因此咱們只須要關注比較重要的虛擬DOM對象 VNode和渲染的組件就好了

VNode基本就是全部的數據了，VueComponent是當前渲染的，因此，這裏的VNode是否是有不少內存浪費了，與之關聯的不少東西也佔坑了

看看字符串內容，每條僅僅佔用了32字節，因此這裏想到的一個點是要縮減Item項的數量

而後，想一想爲何全部虛擬DOM都留在了內存中呢，展開一個來看對象的引用關係，有一個$slot.default

而後回去看看插件的實現，插件是將全部子項目都放到了子元素中，以slot的方式插入，而後在內部抽出進行再建立

容器組件在從新渲染的時候，確實能觸發了組件的銷燬函數 destroy，而這個也將對象間的關係清的乾乾淨淨的了

具體能夠看vue中組件是怎麼銷燬的

Vue.prototype.$destroy = function () { var vm = this; if (vm._isBeingDestroyed) { return } callHook(vm, 'beforeDestroy'); vm._isBeingDestroyed = true; // remove self from parent
      var parent = vm.$parent; if (parent && !parent._isBeingDestroyed && !vm.$options.abstract) { remove(parent.$children, vm); } // teardown watchers
      if (vm._watcher) { vm._watcher.teardown(); } var i = vm._watchers.length; while (i--) { vm._watchers[i].teardown(); } // remove reference from data ob
      // frozen object may not have observer.
      if (vm._data.__ob__) { vm._data.__ob__.vmCount--; } // call the last hook...
      vm._isDestroyed = true; // invoke destroy hooks on current rendered tree
      vm.__patch__(vm._vnode, null); // fire destroyed hook
      callHook(vm, 'destroyed'); // turn off all instance listeners.
 vm.$off(); // remove __vue__ reference
      if (vm.$el) { vm.$el.__vue__ = null; } // release circular reference (#6759)
      if (vm.$vnode) { vm.$vnode.parent = null; } };

把$vnode的對象關係都切的差很少了，但slot方式的使用下是處理不了的，因此在垃圾回收以後，內存中的vnode對象很是多

再來看看內存佔用的最大值

能夠發現VNode增加了一部分，而最爲矚目的是VueComponent數量居然有那麼多，按道理應該只有渲染的幾個組件的

爲了作對比，咱們通常使用comparison對比兩個快照，看看相差的地方

相關使用能夠去看文檔

有興趣的也能夠導入我這兩個快照自行分析 default maximum

這段時間裏建立的vue對象基本沒能被清理掉，說明有不少不該該出現的對象引用關係，其中detached HTMLDivElement是指遊離的DOM對象，通常用於分析DOM相關的內存泄漏，能夠猜想出這裏的主角應該是vue的組件

挑一個組件來看看，能夠發現它仍是和slot有關的，因此滾動期間建立的組件，屬於VNode節點的componentInstance屬性，而VNode節點無法被回收，因此組件駐留在內存中

接下來的問題是，既然一開始VNode是全部的數據了，爲什麼在滾動期間，還會有那麼多VNode會建立出來

挑一個這期間增長的VNode來看看引用關係，能夠發現VNode中有兩種，增長的是不一樣的_vnode

@後面帶的是對象的id，另外咱們也能夠在調試的時候，console打印出它們是不一樣的對象

通過上面各類分析，有兩個問題須要去解決：

減小駐留的VNode和Vue組件

減小操做期間增長的對象

減小駐留，即不用slot的方式，那隻能改插件了

插件中vm.$slots.default 獲取到的是vnode節點，而後再使用render函數傳遞vnode進行建立組件並渲染

由此想來，咱們也能夠本身建立vnode節點，

不直接寫成子組件，而是將純粹的數據項和組件單元傳遞給插件，讓插件來建立vnode節點

<VirtualList :size="50" :remain="6" :bench="44" class="list" :start="startIndex" :items="items" :item-component="itemComponent" :item-binding="itemBinding">
        </VirtualList>

items 是數據項，itemComponent是 import 進來的一個組件單元，itemBinding是一個函數，返回相似渲染函數的data對象，用以傳遞屬性

itemBinding(item, idx) { return { key: item, props: { index: item } }; // return {
                // key: item.id,
                // props: {
                // index: item.num,
                // },
                // nativeOn: {
                // dblclick: (...args) => {
                // console.log(idx, 'dblclick');
                // }
                // }
                // }
            }

在插件內部，接收傳遞進來的items和itemComponent，構造出相應的vnodes，固然slots方式也能夠支持

for (var i = delta.start; i <= Math.ceil(delta.end); i++) { targets.push(!this.itemComponent ? slots[i] // create vnode, using custom attrs binder
                        : this.$createElement(this.itemComponent, this.itemBinding(this.items[i], i) || {}) ) } return targets