译文 | Angular中的AoT编译( 六 ) _组件

在某些场合， JiT模式的编译根本就无法进行，这是由于JiT在浏览器中，不仅生成代码，它还使用 eval 来运行它们，浏览器的内容安全策略以及特定的环境不允许这些被生成的代码被动态的运行。
最后一个但不是唯一的：节能！在接受到的是编译后的代码时，用户的设备可以花更少的时间运行他们，这节约了电池的电力。节能的量有多少呢？下面是我做的一些有趣的计算的结果：
基于《WhoMy :》这偏文章的结论，访问时，下载和解析的过程大约需要消耗4焦耳的能量。这个文章没有提及所使用的的确切版本，基于文章发表的日期，我估计版本号是1.8.x 。采用了gzip对静态资源做压缩，这意味着.8.3的尺寸约33k 。而被最小化并且gzip压缩后的 @/ 包的尺寸在103k ，这意味着对这些代码的下载和解析需要消耗12.5焦的能量（我们可以忽略JiT的运算还会增加能耗的事实，这是因为和@/这两个场景，都是使用了要给单一的TCP链接，这从是最大的能耗所在）。
的电池容量是6.9Wh ，即24840焦。基于.x官网的月访问量可以得知现在大约有一百万名开发者，平均每位开发者构建了5个应用，每个应用每天约100名用户。5个app 1m 100用户 = 500m ，在使用JiT编译这些应用，他们就需要下载 @/ 包，这将给地球带来 500m * 12.5J = 焦（=1736.千瓦时）的能量消耗。根据搜索结果， 1千瓦时约等于12美分，这意味着我们每天需要消耗约 210 美元。注意到我们还没进一步对代码做摇树操作，这可能会让我们的应用程序代码降低至少一半！
结论
的编译器利用了JS虚拟机的内联缓存机制，极大的提升了我们的应用程序的性能。首要的一点是我们把编译过程作为构建应用的一个环节，这不仅解决了非法eval的问题，还允许我们对代码做高效的摇树，降低了首次渲染的时间。
不在运行时编译是否让我们失去是什么吗？在一些非常极端的场景下，我们会按需生成组件的模板，这就需要我们价值一个未编译的组件，并在浏览器中执行编译的过程，在这样的场景下，我们就需要在我们的应用代码包中包含 @/ 模块。AoT编译的另一个潜在缺点是，它会造成中大型应用的代码包尺寸变大。由于生成的组件模板的代码比组件模板本身的尺寸更大，这就可能造成最终代码包的尺寸更大一些。
总的来说， AoT编译是一个很好的技术，现在它已经被集成到了-seed和-cli中，所以，你今天就可以去使用它了。
参考资料题外话
【译文 | Angular中的AoT编译】这些文章都是我们在研发七巧板过程中的技术总结，如果你喜欢这个文章，请帮忙到七巧板的工程上点个星星鼓励我们一下（点击阅读原文看直达），这样我们会更有动力写出类似高质量的文章。七巧板现在处于起步阶段，非常需要各位的呵护。