记一次vue长列表的内存性能分析和优化 |
您所在的位置：网站首页 › vue组件重新渲染占用内存 › 记一次vue长列表的内存性能分析和优化 |
记一次vue长列表的内存性能分析和优化
|
好久没写东西，博客又长草了，这段时间身心放松了好久，都没什么主题可以写了 上周接到一个需求，优化vue的一个长列表页面，忙活了很久也到尾声了，内存使用和卡顿都做了一点点优化，还算有点收获 写的有点啰嗦，可以看一下我是怎么进行这个优化的，也许有点帮助呢 这个长列表页面，其实是一个实时日志上报的页面，随着页面打开时间的增加，日志数量也会增多，常规的页面布局和渲染免不了会遇到性能问题。 使用了vue框架，框架内部的虚拟DOM和组件缓存已经做了一些优化，比起原生实现是有了一些优化处理。 但这个页面是用到element-ui的el-table组件，渲染出来的是表格数据列表，众所周知，表格在渲染的时候需要绘制整个表格区，所以， 第一步就是将表格实现改为其他元素标签实现 这一步操作之后，其实没什么大的变化的，几千条日志（每条日志还有很多信息）左右，滚动页面明显卡顿严重 而需求又改不了，日志可以展开查看详情或收起，已经看过的日志在下次看的时候不需要加载，新的日志会实时添加进来 以前在做大表格数据鼠标滑过行着色的时候，也有严重的卡顿，当时主要的优化手段是不对所有数据进行处理，仅处理视窗可见区域，也可以在这里试试，所以 第二步就是仅渲染视窗可见的数据 这种方案的原理是使用一个大容器作为滚动区域，里面有一个内容区域，JS通过数据数量和每条数据的高度计算出内容区的高度，内容区用padding或绝对定位撑开滚动区域，让容器可滚动，另外就是数据项了，滚动的时候，计算当前滚动位置scrollTop，再从数据项中找出各项的高度，从头到尾计算出此时容器中放什么数据 哈哈哈 ... 这文字描述简直了，看不懂就不看了吧，可以去看下别人的解说 知道原理之后，实现起来也不难，不过代码就写的比较凌乱了，还是使用现成的比较成熟的vue插件吧，比较方便 复制粘贴一顿猛操作之后，页面重新展现出来，想着应该可以收工了吧 然鹅，测试的时候发现，页面内存使用可以达到一两G，看来不仅要优化卡顿，还要优化内存使用  还能遇到这种少见的页面崩溃，也算是开了眼了  这个方案是把原先页面应该渲染的所有DOM拆分出来，动态地渲染该渲染的部分， 所以就会有一个问题，动态计算需要时间，当滚动非常快的时候会有明显的卡顿现象，所以 第三步就是进行函数节流，即控制scroll事件的处理，在规定的时间内仅触发一次 代码语言：javascript复制// 函数节流，频繁操作中间隔 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是各种操作之后的内存快照 代码语言：javascript复制这个长列表总共10w条数据，仅仅渲染了50条（6 + 44）数据，每条数据仅仅是短短的字符串，不该占用这么多内存 去看下内存具体占用情况  内容有点多，因为用的是vue，所以我们只需要关注比较重要的虚拟DOM对象 VNode和渲染的组件就行了 VNode基本就是所有的数据了，VueComponent是当前渲染的，所以，这里的VNode是不是有很多内存浪费了，与之关联的很多东西也占坑了  看看字符串内容，每条仅仅占用了32字节，所以这里想到的一个点是要缩减Item项的数量 然后，想想为什么所有虚拟DOM都留在了内存中呢，展开一个来看对象的引用关系，有一个$slot.default  然后回去看看插件的实现，插件是将所有子项目都放到了子元素中，以slot的方式插入，然后在内部抽出进行再创建   容器组件在重新渲染的时候，确实能触发了组件的销毁函数 destroy，而这个也将对象间的关系清的干干净净的了 具体可以看vue中组件是怎么销毁的 代码语言：javascript复制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节点 代码语言：javascript复制items 是数据项，itemComponent是 import 进来的一个组件单元，itemBinding是一个函数，返回类似渲染函数的data对象，用以传递属性 代码语言：javascript复制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方式也可以支持 代码语言：javascript复制for (var i = delta.start; i |
【本文地址】