资料下载：高性能JavaScript.pdf

高性能JavaScript.pdf

http://www.100md.com 2020年11月6日

第1页

第9页

第20页

第28页

第49页

参见附件(3874KB，350页)。

高性能JavaScript揭示的技术和策略能帮助你在开发过程中消除性能瓶颈。你将会了解如何提升各方面的性能，包括代码的加载、运行、DOM 交互、页面生存周期等

    为什么优化是必要的

    在 1996 年，引擎只要能支持页面里数十行的代码就好，而今天，却运行着成千上万行代码的 Web 应用。从许多方面来说，如果不是因为自身在语言管理和基础设施方面的落后，本可能取得更大规模的成功。IE 6 就是一个明证，发布之初，它的稳定性和性能都被人们称颂，但后来却因为自身的 Bug 和反应迟钝而被痛批为令人讨厌的 Web 应用平台。

    事实上，IE 6并没有变慢，它只是被寄予了厚望。2001年IE 6刚发布时出现的各类早期Web应用比2005年后出现的应用更轻量，代码也远没有那么多。代码数量的增长带来的影响变得明显，IE 6 的引擎吃不消了，原因在于它的“静态垃圾回收机制”译注。该引擎监视内存中固定数量的对象来确定何时进行垃圾回收。早期的 Web 应用开发人员很少会遇到这个极限值，随着更多的代码产生越来越多的对象，复杂的 Web 应用开始频繁遭遇这个门槛。问题变得清晰起来：开发人员和 Web 应用都在发展，而引擎却没有。

    尽管其他有着更加完善的垃圾回收机制和更好的运行性能，但大多数仍然使用解释器来执行代码。解释性代码天生就没有编译性代码快，因为解释性代码必须经历把代码转化成计算机指令的过程。无论解释器怎样优化和多么智能，它总是会带来一些性能损耗。

    编译器已经有了各种各样的优化，使得开发人员可以按照他们想要的方式编写代码，而不需要担心是否是**。编译器可以基于词法分析去判断代码想实现什么，然后产生出能完成任务的运行*快的机器码来进行优化。解释器很少有这样的优化，这很大程度上意味着，代码怎么写，就被怎么执行。

    实际上，通常在其他语言中由编译器处理的优化，在中却要求开发人员来完成。

    前言

    当作为 Netscape Navigator 的一部分在1996年出现时，性能问题并不重要。当时的互联网仍处在发展初期，各个方面都很慢。从拨号上网到低配置的家用电脑，上网冲浪往往比任何事情都需要耐心。人们都做好了等待网页加载的心理准备，页面加载能完成就是一件值得庆祝的事了。

    *初的目标是改善网页的用户体验。能代替服务器处理页面中类似表单验证的简单任务，这样做节省了与服务器连接的大量时间。想象一下当你填完一个很长的表单，提交后等待了30~60秒，却得到一个字段出错的信息是什么感觉。显而易见，为早期的互联网用户节省了很多时间。

    互联网的发展

    在接下来的10 年里，电脑和互联网不断发展。首先，两者都变得更快。高速的微处理器，内存的廉价供应，以及光纤连接的出现将互联网推向了一个新的时代。随着高速网络的普及，网页开始变得丰富，并且承载着更多的信息和多媒体内容。Web 从简单的关联文档演变成了各式各样的设计和界面。一切都变了，除了一样东西，那就是。

    这项曾用于节省服务器消耗的技术日益普及，但代码也从数十行的发展到成百上千行。IE 4 和动态 HTML译注 (改变页面显示而无需重新加载的技术)的推出更是使得网页中的代码量只增不减。

    近一次的重大更新是文档对象模型(DOM)的推出，这是一个被IE 5、Netscape 6及Opera所一致接受的动态HTML接口。紧接着，被标准化，并推出了ECMA-262

    下一代引擎

    2008 年，引擎迎来了一次大的性能升级。Google 发布了全新的，名为 Chrome。Chrome 是**款采用优化后的引擎的，该引擎的研发代号为 V8。V8 是一款为打造的实时(JIT)编译引擎，它把代码转化为机器码来执行，所以给人的感觉是的执行速度超快。

    其他紧跟着也优化了它们的引擎。Safari 4 发布了名为 SquirrelFish Extreme(或称为 Nitro)的 JIT 引擎，而Firefox 3.5 的 TraceMonkey 引擎对频繁执行的代码路径做了优化译注。

    这些全新的引擎带来的是编译器层面的优化，这也是它应该做的。或许有一天，开发人员完全无须关心代码的性能优化。可是，那一天还未到来。

    高性能JavaScript截图

附件资料：

高性能JavaScript.pdf（3873KB）

本页网址：

http://www.100md.com/html/file/202011/065294.htm