如何提高Angular 2的模板解析性能？

Question

我们正在使用Angular 2重写我们的UI。因为这是新的，所以资源很少，所以请原谅我，如果我的问题看起来很愚蠢并且已经得到了解答。

首先，一点背景。我们的产品是由＆＃34;模块和＃34;哪些是可以放在页面上的小部件。因为并非所有模块都被重写以使用Angular 2，所以同时在一个页面上会混合使用非Angular和Angular模块。出于这个原因，我们决定让每个Angular2模块成为一个独立的角度应用程序。

在原型阶段，所有人看起来都很精致，但是，快速前进几个月，在发布前几周，有人看了我们的页面加载时间并且不那么令人印象深刻。在我的机器上，启用prodMode后，需要5个模块大约2.5秒才能渲染我们最复杂的2个模块，每个模块需要一秒钟。我得到的两个最大的模板大小是32KB和80KB，但由于处理时间相同，我怀疑线性长度不像结构复杂性那样有贡献，而且它们非常复杂。其他3个模块要简单得多。

从这个时间线看，似乎花了很多时间来解析模板和加载组件。所以我想也许这是因为每个模块都是一个独立的角度应用程序，他们可能不会共享缓存的组件。因此，我已将BROWSER_APP_COMPILER_PROVIDERS从App Providers迁移到Platform Providers列表中。这导致所有模块重用一个RuntimeCompiler（我认为）。 然而，在规模宏大的情况下，它并没有多大改善情况。总时间下降到2.3秒，这几乎不值得麻烦。

现在，模块主要是向导。这就是他们坐下来看起来很漂亮，直到用户点击/点击它们来吸引他们。所以这让我思考，如果我可以进行模板解析怎么办？如果我可以告诉Angular按需解析向导步骤，我可以在交换模块时减少加载时间以换取一些延迟。这就是我现在正在研究的内容，但我很想听听社区的意见。

感谢您的阅读。

更新：我正在运行RC.3。

Answer 1

在角度2.4中，我们有一个名为AOT的概念，可以提高性能！

Angular应用程序主要由组件及其HTML模板组成。在浏览器呈现应用程序之前，必须通过Angular编译器将组件和模板转换为可执行JavaScript。

您可以在运行时使用实时（JIT）编译器在应用程序加载时在浏览器中编译应用程序。这是整个文档中显示的标准开发方法。它很棒，但它有缺点。

JIT编译会导致运行时性能损失。由于浏览器内编译步骤，视图需要更长时间才能呈现。应用程序更大，因为它包括Angular编译器和应用程序实际上不需要的许多库代码。较大的应用程序传输时间较长，加载速度较慢。

编译可以发现许多组件模板绑定错误。 JIT编译在运行时发现它们，这是在这个过程的后期。

提前（AOT）编译器可以及早捕获模板错误，并通过在构建时进行编译来提高性能。

Answer 2

脱机（预）编译器可以提供帮助，但还没有准备好。

您可以尝试使用单独的组件替换复制粘贴/复制的html代码以减少模板大小。具有可重用组件的树状UI结构可能会有所帮助。

另一种方法是使用延迟加载：当用户点击它时加载向导（可能使用预加载）。

我认为向角度团队提交CPU配置文件会很有帮助，这样他们就可以优化编译器/解析器。

Answer 3

好的，谢谢你写信给我。所以，如果我理解这是正确的，每个小部件就像不同的角度2应用程序。因此，基础模块或基础角度 应用程序依赖于多个相关的可注射应用程序。现在，我假设这个事实，你已经准备好捆绑和缩小生产 脚本。除此之外，只想了解为请求提供服务的API的SLA是什么。很多时候，我观察到人们抱怨UI缓慢。但， 它曾经是不符合SLA的后端。检查你的后端SLA是否正常。

接下来，角度模块的缓存策略是什么？这些请求多久回到服务器。这是一个问题。围绕缓存，所有组件 没有在战斗准备状态下释放。另一件事，我想了解的是，你是否使用RXJS来处理承诺。 RXJS，戏剧性地 改善了角度2 app的性能。

接下来，代码是可重用的，比如在指令中包装可重用代码，然后在所有需要的位置注入相同的代码。这将削减代码编译 成本。

此外，继续检查有角度的2个里程碑，以及围绕性能改进发布的新修补程序。我期待最终战斗准备生产框架 截至12月的角度2。然后，我们还将我们的应用程序迁移到角度2.即使在纳斯达克，我们目前运行的是1.5X版本。我希望这能帮到您 改善应用程序的性能。