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

本文轉載自查看原文 2019-02-25 00:39 11105 chrome/ Web前端/ vue/ 內存/ 性能

好久沒寫東西，博客又長草了，這段時間身心放松了好久，都沒什么主題可以寫了

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

寫的有點啰嗦，可以看一下我是怎么進行這個優化的，也許有點幫助呢

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

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

但這個頁面是用到element-ui的el-table組件，渲染出來的是表格數據列表，眾所周知，表格在渲染的時候需要繪制整個表格區，所以，

第一步就是將表格實現改為其他元素標簽實現

這一步操作之后，其實沒什么大的變化的，幾千條日志（每條日志還有很多信息）左右，滾動頁面明顯卡頓嚴重

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

以前在做大表格數據鼠標滑過行着色的時候，也有嚴重的卡頓，當時主要的優化手段是不對所有數據進行處理，僅處理視窗可見區域，也可以在這里試試，所以

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

這種方案的原理是使用一個大容器作為滾動區域，里面有一個內容區域，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