前端多数据渲染优化

前言前段时间在做请求的时候，遇到了自定义列表功能。它所有的数据显示都是通过jSON字符串存储的，最开始也是通过JSON解析的。数据是有上限的，但是后来提高上限后，出现了卡顿等问题，所以本文介绍一些解决前端大量数据渲染问题的方案。innerHTML的解决方案是很久以前第一次插入innerHTML渲染解决方案。官方API，性能更好。这是一个简单的HTML渲染例子（实验中数据在10w级别，差异放大，实际中基本会小于这个级别）constitems=newArray(100000).fill(0).map((it,index)=>{return`

`}).join('')content.innerHTML=items来自谷歌的性能分析：页面在10秒滚动，可以看到dom的渲染阻塞了页面1300毫秒。性能测试中总阻塞时间控制在300ms以内为合格状态。这个时间也会受到电脑硬件的影响。总结一下这种方式的优缺点：优点：性能还算可以，但是数据量大的时候也有阻塞。缺点：存在注入危险，与框架匹配性差。当dom过多时，滚动的性能问题并没有解决。批量插入是通过分片插入的，如果有10W条数据，我们将其分成10次，每次1w次循环插入[...newArray(10)].forEach((_,i)=>{requestAnimationFrame(()=>{[...newArray(10000)].forEach((_,index)=>{constitem=document.createElement("div")item.textContent=`item${i}${index}`content.append(item)})})})经过谷歌分析：这里也是页面刷新和滚动的性能分析，可以看出阻塞时间为1800毫秒，比innerHTML差一点。这是10w的数量级。数字越小，时间间隔越小。关于requestAnimationFrame中requestAnimationFrame的作用：这个方法会告诉浏览器我要执行动画，请求浏览器在下次重绘前调用回调函数来更新动画执行方法：执行requestAnimationFrame(callback)时，回调回调函数不会立即被调用，而是会被放入回调函数队列，当页面可见且动画帧请求回调函数列表不为空时，浏览器会周期性的将这些回调函数加入到浏览器UI的队列中线程（回调函数的时机由系统决定）。一般来说，它不会阻塞其他代码的执行，但总的执行时间与innerHTML方案相差不大。总结优缺点：优点：不会阻塞代码的运行。长期以来，滚动的性能问题一直没有得到解决。其它原生方法canvascanvas是专门用于绘图的工具，可用于动画、游戏画面、数据可视化、图片编辑和实时视频处理。最近在大名鼎鼎的Flutter框架的web中使用canvas来渲染页面。同样，我们也可以使用canvas来渲染大量数据/div>letctx=canvas.getContext('2d');[...newArray(100000)].map((it,index)=>{ctx.fillText(`item${index}`,0,index*30)})经过实际尝试，canvas是受限的，最大6w左右的高度已经不能放大了，也就是说在大量数据下，canvas还是受限的，有待进一步优化这里是一个优化思路，监听外层DOM的滚动，根据高度动态渲染画布的显示，可以达到最终的效果，但是成本还是太高了。优点：在渲染次数上性能好缺点：如果想实现和虚拟列表一样的渲染，不可控（在其他场景下是更好的解决方案，比如动画，地图等）是难以控制画布中的样式IntersectionObserverIntersectionObserver提供了一个异步观察目标元素和视口的交集状态，简单的说就是我们可以监测一个元素是否会被我们看到。当我们看到这个元素时，我们可以执行一些回调函数来处理某些事务。注意：IntersectionObserver的实现要使用requestIdleCallback()，即观察者只有在线程空闲的时候才会执行。这意味着这个watcher的优先级很低，只有在其他任务完成且浏览器空闲时才会执行。通过这个api，我们可以做一些尝试来实现一个类似虚拟列表的解决方案。这里我实现了一个向下滑动的虚拟列表demo。主要思想是监控列表中的所有dom。当它消失时，移除并移除monitor，然后添加新的DOM和监听器核心代码：constintersectionObserver=newIntersectionObserver(function(entries){entries.forEach(item=>{//0表示消失if(item.intersectionRatio===0){//最后添加intersectionObserver.unobserve(item.target)item.target.remove()addDom()}})});Google的性能分析（第一次进入页面，连续滚动1000条）：可以看到基本没有阻塞，这个方案是可行的，初始渲染和滚动之间没有问题。详情请点击查看。demo只实现了滚动的解决方案：https://codesandbox.io/s/snow...进一步优化，现在实现了IntersectionObserver具有类似虚拟列表的功能，不过貌似会有隐患经常加监听和取消，所以打算采用扩展方案：总体思路：当前列表10个为一组，当前列表一共渲染30个，当滚动到第20个时，触发一个事件，加载第30个-40，同时删除0-10，依次触发。这样，触发次数和监听次数都会呈指数级下降。当然，成本是同事渲染的dom数量增加，以后我们会增加每个团队的数量，从而在dom数量和监控之间保持一个更平衡的状态。兼容性关于IntersectionObserver的兼容性，通过polyfill，可以得到大部分浏览器的兼容性，最低支持IE7。具体可以参考：https://github.com/w3c/Inters...总结的很好缺点：优点：使用原生API实现的虚拟列表方案，无数据瓶颈缺点：框架在生产中的适应性不够高，实现比较复杂无限滚动中频繁触发监听和释放，可能会出现一些问题withtheframework上面提到的很多方法都是在非framework中实现的，这里我们看一下列表在react中的表现react这是一个长度为10000的列表渲染函数App(){const[list,setList]=使用状态（[]）；useEffect(()=>{setList([...newArray(50000)]);},[]);return({list.map((item,index)=>{returnitem{index}