全面提升Web 2.0应用程序性能3.docVIP

简介：?您知道为什么您的页面需要如此长的时间来渲染吗？您想知道哪个 JavaScript 脚本函数占用了大部分时间吗？本文将继续介绍 Web 2.0 应用性能分析过程中对于页面渲染性能分析的方法学和工具，并结合 IBM Mashups Center 产品，介绍如何对一个在浏览器端进行渲染的页面做性能剖析 （profiling），分析剖析结果并且定位浏览器端脚本执行过程中的性能问题与瓶颈。本文是?“全面提升 Web 2.0 应用程序的性能”?系列文章的第 3 篇。 查看本系列更多内容 谁在调用运行时间最长的方法？ 简化的浏览器响应时间的计算模型 浏览器响应时间 = 服务器响应时间 + 页面装载时间 + 页面渲染时间 页面渲染时间 = 脚本执行时间 + 浏览器引擎渲染时间 衡量一个 Web 2.0 应用是否成功的一条关键准则是客户对于应用页面装载时间的感受和满意度。用户对于一个应用的第一感受来自于他访问您的第一个页面，通常是应用的主页。从技术上讲，我们认为“浏览器响应时间”是指用户感受到的，在浏览器上做出动作（通常是鼠标点击或者键盘敲击）开始到新页面（或者部分页面）显示完整的这段时间。 “浏览器响应时间” 包含三个主要的部分： 浏览器响应时间 = 服务器响应时间 + 页面装载时间 + 页面渲染时间 对于“页面装载时间”的性能分析与优化，我们在?前面的文章中?已经进行了讨论。在这篇文章中，我们着重讨论页面渲染时间，以及如何剖析和分析浏览器页面渲染时间，并通过找到其存在的性能问题与瓶颈来提高应用的性能。 页面渲染时间主要包含两个部分： 页面渲染时间 = 脚本执行时间 + 浏览器引擎渲染时间 其中： “脚本执行时间”包含浏览器脚本执行引擎解析和执行脚本的时间， 本文只讨论 JavaScript 脚本。 “浏览器引擎渲染时间”包含浏览器引擎渲染和显示图形界面 UI 的时间。不同的浏览器和浏览器版本有可能采用不同页面渲染技术，其执行效率和显示行为有一定的差别，比如有些引擎在实现行为上进行了优化，使用户能先看到部分被渲染完成的页面，然后逐渐显示后续的内容，这部分对于引擎的技术差异不在这篇文章的讨论范围。对于一个设计良好的页面，它在浏览器端的引擎渲染时间通常是固定且快速的，在这里我们不打算深入讨论。 Web 2.0 应用中，越来越多的逻辑层和表现层的实现被转移到浏览器端。对应用本身，这样不仅可以减轻服务器的负担，并且能提供非常丰富的用户体验，使应用有非常好的可用性。浏览器端的页面聚合特性，也使得服务器的架构设计更加灵活，使应用有更大的可扩展性。而从应用的性能角度来看，这势必加重了页面的渲染时间，过于差的页面显示延时，会严重影响用户的体验。所以我们应该认识到应用里面的脚本已经变的很重要，而且可能成为应用的性能瓶颈。为了提升脚本的执行性能，首先需要开发者在设计和实现的时候把性能考虑进去，同时也有一些成熟的 JavaScript 脚本编程的性能建议可供开发者作为参考（参见?参考资源），这可以帮助开发者在程序实现或者从服务器端迁移代码的时候避免调用一些在脚本执行中性能比较差的方法或算法。有些时候，开发者并不能预测到代码中可能存在的性能问题，这时候性能分析技术能提供一些性能剖析的方法和工具，帮助我们对一些方法或者代码片段做性能剖析，从而分析内部潜在的性能问题。 在脚本语言中，主要的性能剖析方法有时间片剖析和调用流程剖析： 时间片剖析：时间片剖析能记录与统计一段时间内各个方法被调用的次数以及占用的时间片长度。它的结果通常能帮我们回答这些问题：“时间都花在哪些方法里了？” “谁用了最多的时间？” “每个方法被调用了多少次？”。 调用流程剖析：调用流程剖析记录一段时间内每个方法的调用、退出以及它调用的子方法，同时记录该方法消耗的时间。它的结果能显示每个方法的调用流程与方法在这个堆栈所消耗的时间。它通常能帮我们回答这些问题：“是谁调用了这个方法？”，这个方法都调用了哪些其他方法？” 这两个性能剖析方法包含两个相同的步骤：数据搜集与数据后处理与分析，通过合适的工具，我们可以同时得到这两个剖析结果。 这个结果能帮我们回答我们最想知道的问题：”谁在调用运行时间最长的方法？“，这将毫无疑问的帮我们定位到应用中存在的性能问题。 回页首 JavaScript 性能剖析工具 目前许多浏览器都提供了适用于自身的性能剖析工具或者插件，不同的工具提供了不同的功能，能帮助我们在不同浏览器上进行脚本执行性能的分析。这里我们以 Mozilla Firefox FireBug 插件、MicroSoft Internet Exporlor 8 与 Webkit（Safari）Web Inspector 三个工具为例子比较他们在功能上的区别，见?表 1。 Mozilla FireFox Fir