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