复杂渲染引擎架构与设计--6.增量渲染
对于渲染引擎来说,如果每次都进行完整内容的计算和绘制,在低端机器或是负责页面的时候可能会出现卡顿。 因此,我们可以考虑设计一套增量渲染的能力,来实现改多少、重绘多少,减少每次渲染的耗时,提升用户的体验。
对于渲染引擎来说,如果每次都进行完整内容的计算和绘制,在低端机器或是负责页面的时候可能会出现卡顿。 因此,我们可以考虑设计一套增量渲染的能力,来实现改多少、重绘多少,减少每次渲染的耗时,提升用户的体验。
前面《渲染计算》一文中,我们提到了对于长耗时的渲染计算的优化方案,其中便包括了将大的计算任务拆分为小任务的方式。 本文我们以在线表格为例子,详细介绍下如何对长耗时的计算进行任务拆解。
前面《收集与渲染》一文中,我们简单提到说在一些复杂场景下,从服务端获取的数据还需要进行计算,比如依赖 Web 浏览器的计算,亦或是游戏引擎中的碰撞检测。 本文我们详细针对复杂计算的场景来考虑渲染引擎的优化。
前面我们介绍了复杂渲染引擎中,使用的收集和渲染、以及插件等架构设计。至于底层具体的绘制实现,前面提到的多是 Canvas,实际上我们还可以适配不同的绘制引擎。
上一篇《收集与渲染》文章中,我们提到收集与渲染的拆分设计,对后续的业务拓展会更方便。 本文将介绍渲染插件的设计,渲染插件可用于各种新特性的拓展绘制。
对于一般的渲染引擎来说,我们可以简单地拿到待渲染的数据,然后直接通过 Canvas/DOM/SVG 来将需要渲染的图形和内容渲染出来。 而在复杂场景下,比如需要自行排版的文本、表格和图形类,光是将要渲染的数据计算出来,便容易面临性能瓶颈,而对于样式多样、结构复杂的内容来说,绘制过
知晓要如何解决问题,只是真正解决问题的第一步。在工作里,我们更多时候遇到的问题不只是如何解决,而是如何有效落地。
SSR 也算是前端性能优化中最常用的技术方案了,能有效地缩短页面的可见时间,给用户带来很好的体验。
前面我们讲了很多前端应用内部的性能优化,实际上除了前端自身,我们还可结合容纳 Web 页面本身的客户端一起做优化。
Canvas 渲染在前端应用中的使用场景不算多,但在大多数用到的场景下,也常常需要考虑性能瓶颈。
如果页面中存在耗时较长的计算任务,那么卡顿也是需要关注的一个性能优化点。
对于内容复杂和变更频繁的前端应用,页面渲染也常常是性能优化的核心场景。
对于前端应用的性能优化,大多数时候我们都是从加载流程开始优化起。
对于前端开发来说,性能优化老生常谈了。不管是日常工作中,还是涉及到晋级答辩,性能都是频繁被我们提及的一个话题。 性能优化不是一劳永逸的解决方案,项目在发展过程,代码不断地迭代和变更。我们在某个阶段优化过的代码,过段时间性能又会慢慢下降,这也是前端开发常把性能挂在嘴边的原因。
前端工程化这个词出现的频率越来越高,一直没有明确的定义,有些人认为是模块化和自动化的工具,比如 Webpack/Gulp、脚手架、组件化等,但工具只是一些辅助手段,并不能作为工程化来理解。