懒癌晚期患者，终于在本周强迫自己完成2023年的第一章文章KPI！！！
最近做了不少的业务优化，与一些技术选型上的思考，想得很多，但是还没有着手开始写这方面的思考，今天主要记录一下，关于页面渲染优化的一些实战案例思考。
OK，那下面话不多说，直接进入正题
聊干的了
**一、基于业务情况的实践，所需要的优化在哪里？
**
1、基于页面渲染的优化，减少不必要的渲染，拆分渲染流程
2、基于大量数据请求，需要减少请求时机，
OK，看完上面两条，可能有的同学会在想我的性能优化会很复杂，会想很多既要渲染优化，又要数据缓存，这个时候，应该怎么去考虑去拆分业务。
如果有这个疑惑的话，请向下看，没有，则请跳过这一段
###########################################
首先来说，我们在考虑性能优化的时间中，第一点则是定位出我们的需求核心在哪里？举个例子来说，产品同学提出了一个功能点，而后我们完成了这个功能点，但是伴随而来的问题是，页面的渲染由于大量list的问题，导致渲染过慢，那么OK，这个问题的核心在哪里？表面上来看是页面渲染的过慢问题？本质上呢，是不是由于大量数据请求过载的问题呢？那么这个问题，我们到底是应该从渲染的方面着手去做处理，还是在请求的问题上做优化呢？
OK！！还是上面那个功能点，我们的产（da）品（yuan）同（zhong）学又来提要求了，我们不光要体量的展示功能了，我们还需要做基于TYPE的切换，过滤、筛选，这个时候大量数据的灌入，是不是要做多次请求，那么这个点优化和直接是不是又联动起来了。那么这个时候请问，我们应该从哪个点上着手去做优化。
OK，那么上面这个例子我们讲完了，我们来讲下一个业务场景案例思考；
假设现在有一个数据可视化的业务，做复杂图表计算绘制，这个时候的我们所计算的数据是基于后台请求过来的，数据接口的体量还OK，那么这个时候有一个问题，我们的图表每一次的绘制需要大量的时间，在每一次的页面切换过中，它都会重新绘制，我们希望减少它绘制的次数，不希望它每次都重新绘制，那么这个时候我们应该怎么做？
###########################################
第一小节聊完了，那么到底是怎么做呢，每一个人都会有自己的答案，作者也不例外，那么我们继续聊第二节
二、基于业务场景的缓存思考
好的，看完第一小节的同学其实这个时候应该明白作者想聊的是什么了。
1、关于dom节点的缓存
2、关于data数据的缓存
其实目前业内已经有了很多的成熟的案例和方法，这里不过多做延伸，作者只聊一下关于两个方面的业务思考
好的，首先来说，dom节点的缓存，看完上述的案例之后，可能有的同学已经能反应过来了，其实作者的两个例子，就是对于dom的缓存和data的缓存的两个针对性案例，OK，这个时候可能会有同（gang）学（jing）说啊，我的业务好复杂的，又要这个又要那个的！！！OK，不杠，杠就是你对～～～
作者是一个夹带私货的比较严重的人，个人认为，不管多复杂的业务，我们应该抓重点，重点定位，而后具体解决。不管dom还是data都是解决问题的一个思路，而不是纠结于方法。
归根结底，我们用的是术，可最终是要归于道，其实也就是术与道的选择
好的，简单跑题了一下。
继续聊dom的缓存，那么基于刚才第二个案例，我们来思考，我们的需求是什么，是减少绘制次数，dom更新，那么以Vue或者React为例，页面的生命钩子依托于什么，是不是大量基于路由的切换，状态下进行渲染更新，也代表着这个图表其实就是会在不同页面进行绘制，OK，由于图表本身的绘制较慢，我们在初始化绘制同时考虑白屏的问题情况下，是不是可以将它的绘制计算放于异步操作，OK，其实还有个Web新特性 WebWorker，这里不过多延伸，有兴趣的同学可以移步MDN自行学习
好了，初始化绘制解决掉了之后，那么减少多次绘制情况，那么我们这个时候是不是可以创建一个container，而后将我们的dom放置于这个container中，存放的考虑是不是可以基于我们全局状态，亦或者全局上下文状态中。在我们的需要的时候放置于一个fixed定位元素中减少其页面结构的回流。那么简单的一个dom的缓存就完成了
简单画了一个dom的方法，请自行补充！！！
好的，dom缓存聊完了，我们来聊一聊data的缓存，其实data的缓存，目前的业内案例都已经说的很明白了，不管是数据持久化也好，还是WebWorker的多线程计算都是已经很成熟的业内解决方案了。那么这个时候其实就是很简单的聊一下，
session和local的两种缓存模式，
前端面试常用八股文。这里选用哪种方式看同学们的业务情况。
那么最后聊点拓展的吧！！！
终、所谓的预加载和懒加载
注：此节是给基础一般的同学做通透理解所用，有延伸概念的以及追求完备详细的的同学请自行左滑离开
其实这个点是要跟data缓存一起来讲的，但是作者觉得还是分开聊一聊会比较好一点，因为其实这个点方向来说，作者做了最简单的基础思考就是其实本质就是异步调用的时机，本质来说，所谓的预加载和懒加载在作者看来其实都是做了所谓的CallBack机制，只不过一个是在当前dom加载之前，上一个dom销毁之前的CallBack触发；另外一个则是在当前dom加载完成之后进行的CallBack触发；
为什么会聊到了这个问题呢，因为对于前端同学来说，其实最核心的原因就是因为js本身的单线程阻塞机制，也就是说，js本身永远性能的伪命题都在于本身的单线程，先天性的特性导致我们前端同学们要永远考虑不同的hooks状态下，我们应该先做什么，后做什么。当然，这个特性呢。既是优点也是缺点，这里就不做过多讨论了！！！
OK，2023的首次分享文章到此结束！！！
有兴趣的同学可以关注一下作者哈～～
