Ember改进渲染性能

Ember社区发布了Ember 1.8版本。该版本最显著的更新是使用了“金属视图”，改善了渲染性能。该特性也为进一步改善性能打好了基础，将来作为“HTMLBars”的一部分。

在Ember以前的版本中，页面的HTML以字符串形式创建（通过Handlebars），然后通过字符串拼接进行组装。现在，页面片段还是以字符串形式创建（通过Handlebars），但会解析为DOM，然后组装为DOM树。

此种方式的优势如下：

• Ember再也不用使用<script>标签来标记数据绑定内容区域（为了跟踪DOM中哪些地方需要更新绑定值）。现在可以使用独立的DOM对象进行跟踪；
• 在内嵌SVG文档中，提供组件、数据绑定、逻辑支持；
• 移除渲染层的递归，既降低GC压力又可以在渲染时重用对象。

但是与Ember 1.6相比，新版本看似性能有所降低，尤其在IE和Android的浏览器上。该问题可能是因为引入了额外的中间步骤（首先将Handlbars转换为字符串，然后解析为DOM），但尚未得到证实。将来的版本会移除多余的步骤。

Matthew Beale在HackerNews上发表了评论，对重构渲染过程的目前状态和未来计划做了说明：

我们开始使用HTMLBars这个术语的目的是为了对Ember的渲染流水线进行一系列改善。在当前的版本（1.8）上我们增加了金属视图（渲染引擎重构），在下一版本（1.9）中我们计划增加流（数据绑定重构），在1.10版本我们希望能够采用新语法和基于DOM的模板引擎。

我们尽力以渐进方式发布HTMLBars特性，而不是完全重写，部分原因是该计划的落地比预期要花更长的时间。但是我个人还是很高兴看到该变化目前进行得很顺利，如果您是Ember.js用户，应该有同感。

Matthew 提到的“流”是一种崭新的Ember.js内部实现，用于替换Ember渲染[z5] [zw6] 流水线底层的数据绑定。该特性会简化模板助手的实现。与Ember 1.8版本同时发布的Ember 1.9 beta版本提供了该特性。

Ember社区欢迎HTMLBars特性的原因有如下几点：无需修改语法，现有应用即可获得显著的速度提升——完全是因为渲染过程的改变（解析为DOM而不是操作字符串）；还有就是支持很多新特性，如组件的HTML语法。这些计划变更在“Ember 2.0 RFC路线方案”一文中有详尽的描述。

然而这些修改需要的时间远远超出预期，特别是因为需要大量的测试。

Ember 1.8还带来了其他方面的性能提升：

• 在对字符串标准化（查找类或路由）的若干操作中（命名方式转换、单复数转换）引入了缓存策略；
• MANDATORY_SETTER从运行期标识改为构建期的特性标识，使得getter和setter中的代码路径在构建后的生产版本中更短；
• 重写Ember.Map，使其更快也更接近ES6的实现。

该版本还弃用了很多功能，发布在Ember官网的过期功能指南中。欲知新版本变更和bug修复的全部内容请参考Ember的修改日志。

查看英文原文：Ember Gets Rendering Improvements, More Slated

感谢臧秀涛对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。