关于前端:HTML界的苏炳添详解Canvas优越性能和实际应用

32次阅读

共计 2580 个字符,预计需要花费 7 分钟才能阅读完成。

Google Docs 发表将会把 HTML 迁徙到基于 Canvas 渲染,这一音讯的呈现再次把几年前随 HTML5 诞生的标签从新推到了人们眼帘之中。Canvas 在刚推出时主打的劣势就是更快的渲染速度,堪称 HTML 届的“苏炳添”,刷新了人们对 Web 页面元素绘制速度的印象。但 Canvas 的劣势仅限于此吗?

(苏炳添,亚洲百米第一人)

HTML 绘图届的前辈:SVG

Canvas 是 HTML5 时代引入的“新”标签。与很多标签不同,Canvas 不具备本人的行为,只将一组 API 展示给客户端 JavaScript,让开发者应用脚本把想绘制的货色画到一张画布上。

 

在 HTML5 之前,人们通常应用 SVG 来在页面上绘制出图形。SVG 应用 XML 来定义图形,就像应用 HTML 标签和款式定义 DIV 一样,咱们也能够将一个空白的 DIV 设想为长方形的 SVG,两者的设计思维是相通的,SVG 的实质就是一个 DOM 元素。而 Canvas 则不同,Canvas 提供的是 JavaScript 的绘图 API,而不是像 SVG 那样应用 XML 形容绘图,通过 JavaScript API 间接实现绘制,比起批改 XML 来说要更简便、更间接。

 

除了定义的形式不同,Canvas 和 DOM(当然也蕴含 SVG)的差别更多的体现在浏览器的渲染形式上。

 

浏览器在做页面渲染时,Dom 元素是作为矢量图进行渲染的。每一个元素的边距都须要独自解决,浏览器须要将它们全都解决成像素能力输入到屏幕上,计算量非常宏大。当页面上内容十分多,存在大量 DOM 元素的时候,这些内容的渲染速度就会变得很慢。

(Canvas)

而 Canvas 与 DOM 的区别则是 Canvas 的实质就是一张位图,相似 img 标签,或者一个 div 加了一张背景图(background-image)。所以,DOM 那种矢量图在渲染中存在的问题换到 Canvas 身上就齐全不同了。在渲染 Canvas 时,浏览器只须要在 JavaScript 引擎中执行绘制逻辑,在内存中构建出画布,而后遍历整个画布里所有像素点的色彩,间接输入到屏幕就能够了。不论 Canvas 外面的元素有多少个,浏览器在渲染阶段也仅须要解决一张画布。

 

然而这样更加弱小的性能,不可避免的让应用 canvas 渲染有很高的门槛。Google Docs 在构建 Canvas 的过程中从新定义了平常曾经被人们所相熟的内容,例如精确定位、文本抉择、拼写查看、重画调优等。为什么更多开发者还是抉择了接收 Canvas 这个门槛更高的技术路线呢?这就得回到 Canvas 的最大劣势:渲染性能。

Canvas 的渲染模式

这里的渲染是指浏览器将页面的代码出现为屏幕上内容的过程。Canvas 和 Dom 的渲染模式齐全不同,搞清楚这个差别对了解 Canvas 的性能劣势至关重要。

Dom:驻留模式

驻留模式(Retained Mode)是 Dom 在浏览器中的渲染模式。下图粗略展现了这一过程的工作流程。

(驻留模式)

DOM 的外围是标签,一种文本标记型语言,多样性很强且多个标签之间存在各种关联(如在同一个 DIV 下设置为 float 的子 DIV)。浏览器为了更好的解决这些 DOM 元素,缩小对绘制 API 的调用,就设计了一套将两头后果寄存于内存的“驻留模式”。首先,浏览器会将解析 DOM 相干的全部内容(蕴含 HTML 标签、款式和 JavaScript),将其转化为场景(scene)和模型(model)存储到内存中,而后再调用零碎的绘制 API(如 Windows 程序员相熟的 GDI/GDI+),把这些两头产物绘制到屏幕。

 

驻留模式通过场景和模型缓存缩小了对绘制 API 的调用频次,将性能压力转移到场景和模型生成阶段,即浏览器须要依据 DOM 上下文和 BOM 中的尺寸数据,“自行判断”每一个元素的绘制后果。

Canvas:疾速模式

Canvas 采纳了和 DOM 不同的疾速模式(Immediate Mode),让咱们先来看看疾速模式是如工作的:

(疾速模式)

Canvas 的利用长处

下面介绍的两种不同的模式间接造成了 Dom 和 Canvas 的性能差别。对于应用疾速模式渲染的 Canvas 而言,浏览器的每次重绘都是基于代码的,不存在能让解决流程变慢的多层解析,所以它真的很快。除了快之外,Canvas 的灵活性也大大超出 DOM。咱们能够通过代码准确的管制如何、何时绘制出咱们想要的成果。

 

在资源耗费上,DOM 的驻留模式意味着场景中每减少一点货色就须要额定耗费一些内存,而 Canvas 并没有这个问题。这个差别会随着页面元素的数量增多而更加显著。以 B 端的企业应用场景为例,表单那种数据量比拟小的场景,不同渲染模式带来的成果差别并不显著;但在工业制作、金融财会等类 Excel 电子表格操作的场景下,单元格数量动辄便是上百万(5 万行 x 20 列)甚至上亿个,浏览器须要对表格所有单元格自身内容进行渲染,同时还波及到丰盛的数据处理,状况就齐全不同了。

(Web 页面上的电子表格,蕴含 1 百万个单元格)

在 Canvas 呈现之前,在前端渲染表格时只能通过构建简单的 DOM 来实现。这种形式下,浏览器的性能成为了 Web 利用瓶颈,让很多开发者放弃了在浏览器上实现电子表格的想法。

 

在 Canvas 呈现后,疾速模式带来的性能劣势无疑是一个微小的亮点,大量、简单的 DOM 渲染解决带来的性能问题终于有了解决路径。

 

回到电子表格的利用场景,业内曾经呈现了应用 Canvas 绘制画布的表格组件,这类组件在渲染数据层时不仅无需反复创立和销毁 DOM 元素,在画布的绘制过程中,也比 Dom 元素渲染的限度更少。除了表格之外,Canvas 也为数字孪生可视化大屏、页面游戏等场景带来了改革。

(数字孪生大屏,准确管制各种形态、款式)

总结

总结一下,在渲染模式上,Canvas 站在了 DOM 的对面,浏览器对其内容无所不知,所有渲染的权力回到了开发者的手上,这个扭转带来了显著的性能劣势。此外,咱们能够应用 Canvas 绘制品种更为丰盛的 UI 元素,如线形、非凡图形等,通过画法逻辑,还能够实现更加精准的 UI 界面渲染,解决了浏览器差别造成的款式误差,让更多利用场景能够顺利迁徙到 Web 平台上来。

 

 

参考资料:

 

·       Canvas 的 Wiki 介绍

·       Canvas 社区

·       基于 Canvas 表格组件 SpreadJS

转载请注明出处:葡萄城官网,葡萄城为开发者提供业余的开发工具、解决方案和服务,赋能开发者。

正文完
 0