大背景如是说：
不知道你是不是碰到过那些情形：
被通告下周前很大要化解某一bug，那时早已是周四上午了；上架封版前一晚被通告顾客电脑操控性没用，看不清楚某一网页，彼时早已是早上10点了；早上2点收到电话号码，某一系统那时运转不起来，但今晚要给顾客党委模拟，接着你还出带笔记本电脑回去…倘若你也有那些情形，所以恭贺你，这而已开始…
倘若没有，所以也恭贺你，你决不会碰到的…
所以， 如果他们能找出一些加速韦谢列的方式，宿苞机率能防止这样的问题，大幅提升工作效率。
紧密结合具体内容的实例来撷取呵呵我是怎样借助Performance操控性液晶和console液晶来韦谢列的，结尾也和我们撷取一个采用这个方式强化后制出的车轮。
一、Performance操控性预测液晶
那时看呵呵Performance操控性研究报告：
能看见本篇上面包涵FPS、CPU、互联网等；这几块主要 ，检视是不是上扬的地区，可功能定位到上面的Main分项相关联的js继续执行操作过程，检视流程哪部份影响了网页操控性，这能协助他们加速确认须要强化的标识符边线；
堵塞天数，这是对现阶段网页运转是否流畅的一个总体评价，应尽可能减少堵塞天数；
摘要部份，对比正在继续执行脚本与渲染天数，确认JS继续执行和网页渲染哪个为主要强化对象（强化往往是两者并行）。
上面两个实例分别侧重JS继续执行工作效率和网页渲染工作效率进行强化，JS继续执行工作效率主要降低标识符空间复杂度，减少不必要的内存开销，避免深拷贝，及时清除定时器等；网页渲染工作效率主要减少网页重排次数，尽量同步网页动画与显示器帧数刷新。
二、JS继续执行操控性强化实例
出现问题DOMM定制化项目：现场某场景内G6拓扑组件节点数量一多，浏览器假死，开发环境无法重现。
预测：网页假死通常是js线程堵塞、栈内存溢出，或者是网页动画过于复杂导致css线程卡死、频繁布局抖动等造成的。
Performance预测：
从上图能看见js继续执行天数比较长，渲染天数占用比较短。这种情形先排除css线程以及布局抖动的影响，确认问题是在JS继续执行上。并且在网页操控性强化时针对这种情形想要再去较大地强化网页渲染工作效率是很难也是不划算的，这个时候的重点也是在JS继续执行工作效率上。
采用console打印各环节天数消耗，确认问题标识符通过对于Performance的Main进行预测并紧密结合标识符预测，确认问题标识符地区，在标识符继续执行主要节点上打印天数消耗，针对耗时较大的地区标识符进行细化，最终确认问题标识符。
计算耗时打印
耗时打印情形：
预测：能看见这部份JS标识符总继续执行时长1027ms，其中计算节点、计算连线耗时最长，而且重复继续执行了两次，设置防抖函数。
预测：设置防抖后，此段JS总继续执行时长599ms，继续细化“计算连线”部份耗时打印。
细化耗时打印：
a、“连线计算”耗时过长
预测：“计算连线”段JS标识符被多次引用，继续细化这部份耗时打印；
b、单次连线耗时
预测：“连线耗时”为计算单次节点间连线耗时，大量继续执行且单次耗时不短，对此部份标识符继续细化，发现存在可疑的标识符–深拷贝。
c、深拷贝耗时
预测：“克隆耗时”的打印规律和“连线耗时”相当，且存在耗时较长问题，采用累加计时打印深拷贝总体耗时。
预测：深拷贝累加有三次打印，总耗时679ms，占比很大。
耗时功能定位：每次深拷贝耗时较长，深拷贝算法须要强化或者连线计算逻辑避开深拷贝
预测：拷贝层级过深，造成耗时较长，采用浅拷贝代替。
强化深拷贝耗时后打印
预测：采用浅拷贝打印总耗时6ms，相对于原来的679ms耗时很短。
动画渲染预测那时不能确认现场部署就没有问题，再来看看拓扑节点数量对于JS继续执行以及网页渲染工作效率的影响。
i 加载200个节点后端渲染耗时
ii 加载1个节点后端渲染耗时
预测：能看见200节点与单节点网页渲染耗时相差不大，主要是继续执行JS脚本多了25ms，因为现场最大会有800多个节点的情形，简单计算了下，发现耗时对比原先的1027ms仍有很大提升。
三、动画渲染操控性强化实例
碰到问题：之前开发一张大屏，本地跑没有问题，但联调测试发现右侧的滚动组件模块（有4个）中有一个模块没有东西，接口正常返回，字段也是正常的。最后发现是接口返回了190多条数据，前端全部渲染了那些组件，致使模块假死。
先看下现场效果图。左侧分别是地图、轮播图、饼图、轮播图，中间上面是两个拓扑链路图轮播，上面是4个echarts图表，右侧是4个滚动模块（图片不全）。那时除了要化解上述问题还得做好整张大屏的加载同步。
现场大屏的展示效果↓
预测：那时来看这个问题，既然全部加载会导致模块假死，那就不加载全部，而是采用过一条渲染一条（onebyone）方式，那时模拟单个效果：
onebyone模式单模块效果
注：绿框为可视地区，红框为滚动组件，渲染固定数量的滚动单位，借助css控制网页动画，定时刷新相关联的滚动单位。
onebyone模式 单模块Performance预测液晶
预测：单组件运转已产生JS线程堵塞，继续执行JS脚本、渲染耗时相当。
onebyone模式 4模块Performance预测液晶
预测：继续执行JS脚本、渲染耗时相当，产生较长JS线程堵塞，且网页会发生布局抖动、掉帧。
标识符预测：由于每次一个滚动单位过场后会被替换，引发重排，接着每个模块如此，4个模块叠加，会一直连续引发网页重排，接着这里用的是js控制布局导致间距不一致。彼时的改进方案是要减少重排次数以及替换布局方案，怎么减少重排次数？
“一次计算整个过场液晶，每次过场液晶过场后才去更新整个液晶，替换为flex布局。”
那时来看呵呵这个方案的效果：
twomove模式单模块情形
twomove模式单模块Performance预测面板
预测：单组件运转未产生JS线程堵塞，单个模块同屏产生的dom数量比onebyone模式多，所以优势并不明显。
twomove模式4模块Performance预测液晶
预测：继续执行JS脚本、渲染耗时相当，JS线程堵塞天数减少，网页未出现布局抖动、掉帧，多模块下优势突出。
四、总结
通过Performance操控性预测确认主要强化方向，针对JS继续执行能紧密结合Main分项采用console对问题标识符进行功能定位，针对页面渲染应减少网页重排降低网页渲染消耗，重点强化堵塞天数、网页掉帧问题。
继续对这个组件成果进行强化，增加了endWithNum属性，控制一轮循环完成之后隔开的单位数量，并且修复了一些bug，包括网页不可视后raf停止，css继续运转造成的不同调问题，进行反复测试，确保稳定性，并新增了一些配置属性，做成了车轮react-rollfree。
最后：车轮撷取 react-rollfree
react-rollfree适用于各种滚动组件场景，包括文本、图片、动画等，支持大数据量动态更新，基本能覆盖各种滚动动画场景，后面会增加弹幕模式，扩展更多应用场景。
下载方式：npm install react-rollfree
源码地址：https://github.com/Markuuuu/react-rollfree
原文连接：https://my.oschina.net/u/5459109/blog/5346685
具体内容配置：
`* @animationDirection boolean –滚动方向，默认从下到上，从左到右`
`* @animationTime number –过场天数 单位：S`
`* [@children](https://my.oschina.net/children117cl) [<jsx>] –滚动组件，支持隐式传入`
`* @childrenUpdateModel string –数据更新后更新列表，now立即更新，later跑完更新`
`* @contextHeight number –单条轮播组件height`
`* @contextWidth number –单条轮播组件width`
`* @endWithNum number –结尾空置滚动单位数量`
`* @height number –滚动外框height`
`* @horizontal boolean –横纵向轮播`，默认横向
`* @pauseWithHover boolean –默认开启，鼠标hover组件滚动停止`
`* @showBorder boolean –是否显示辅助设计边界`
`* @width number –滚动外框width`
采用：
`<RollFree`
`animationTime={20}`
`contextWidth={2036}`
`contextHeight={2036}`
`horizontal={false}`
`width={2048}`
`height={1583}`
`>`
`{滚动dom[]}`
`</RollFree>`
react-rollfree默认效果
1000个滚动模块效果图（实现黑客帝国特效）
