衡量一个 Web 2.0 应用是否成功的一条关键准则是客户对于应用页面装载时间的感受和满意度。用户对于一个应用的第一感受来自于他访问您的第一个页面，通常是应用的主页。从技术上讲，我们认为“浏览器响应时间”是指用户感受到的，在浏览器上做出动作（通常是鼠标点击或者键盘敲击）开始到新页面（或者部分页面）显示完整的这段时间。
“浏览器响应时间” 包含三个主要的部分：
浏览器响应时间 = 服务器响应时间 + 页面装载时间 + 页面渲染时间
对于“页面装载时间”的性能分析与优化，我们在 前面的文章中 已经进行了讨论。在这篇文章中，我们着重讨论页面渲染时间，以及如何剖析和分析浏览器页面渲染时间，并通过找到其存在的性能问题与瓶颈来提高应用的性能。
页面渲染时间主要包含两个部分：
页面渲染时间 = 脚本执行时间 + 浏览器引擎渲染时间
其中：
- “脚本执行时间”包含浏览器脚本执行引擎解析和执行脚本的时间， 本文只讨论 JavaScript 脚本。
- “浏览器引擎渲染时间”包含浏览器引擎渲染和显示图形界面 UI 的时间。不同的浏览器和浏览器版本有可能采用不同页面渲染技术，其执行效率和显示行为有一定的差别，比如有些引擎在实现行为上进行了优化，使用户能先看到部分被渲染完成的页面，然后逐渐显示后续的内容，这部分对于引擎的技术差异不在这篇文章的讨论范围。对于一个设计良好的页面，它在浏览器端的引擎渲染时间通常是固定且快速的，在这里我们不打算深入讨论。
Web 2.0 应用中，越来越多的逻辑层和表现层的实现被转移到浏览器端。对应用本身，这样不仅可以减轻服务器的负担，并且能提供非常丰富的用户体验，使应用有非常好的可用性。浏览器端的页面聚合特性，也使得服务器的架构设计更加灵活，使应用有更大的可扩展性。而从应用的性能角度来看，这势必加重了页面的渲染时间，过于差的页面显示延时，会严重影响用户的体验。所以我们应该认识到应用里面的脚本已经变的很重要，而且可能成为应用的性能瓶颈。为了提升脚本的执行性能，首先需要开发者在设计和实现的时候把性能考虑进去，同时也有一些成熟的 JavaScript 脚本编程的性能建议可供开发者作为参考（参见 参考资源），这可以帮助开发者在程序实现或者从服务器端迁移代码的时候避免调用一些在脚本执行中性能比较差的方法或算法。有些时候，开发者并不能预测到代码中可能存在的性能问题，这时候性能分析技术能提供一些性能剖析的方法和工具，帮助我们对一些方法或者代码片段做性能剖析，从而分析内部潜在的性能问题。
在脚本语言中，主要的性能剖析方法有时间片剖析和调用流程剖析：
- 时间片剖析：时间片剖析能记录与统计一段时间内各个方法被调用的次数以及占用的时间片长度。它的结果通常能帮我们回答这些问题：“时间都花在哪些方法里了？” “谁用了最多的时间？” “每个方法被调用了多少次？”。
- 调用流程剖析：调用流程剖析记录一段时间内每个方法的调用、退出以及它调用的子方法，同时记录该方法消耗的时间。它的结果能显示每个方法的调用流程与方法在这个堆栈所消耗的时间。它通常能帮我们回答这些问题：“是谁调用了这个方法？”，"这个方法都调用了哪些其他方法？”
这两个性能剖析方法包含两个相同的步骤：数据搜集与数据后处理与分析，通过合适的工具，我们可以同时得到这两个剖析结果。 这个结果能帮我们回答我们最想知道的问题：”谁在调用运行时间最长的方法？“，这将毫无疑问的帮我们定位到应用中存在的性能问题。
目前许多浏览器都提供了适用于自身的性能剖析工具或者插件，不同的工具提供了不同的功能，能帮助我们在不同浏览器上进行脚本执行性能的分析。这里我们以 Mozilla Firefox FireBug 插件、MicroSoft Internet Exporlor 8 与 Webkit（Safari）Web Inspector 三个工具为例子比较他们在功能上的区别，见 表 1。
- Mozilla FireFox Firebug 插件：Firebug 插件是一个很好的 Firefox 上的 JavaScript 开发与调试工具，这个插件也支持对 JavaScript 执行做性能剖析。
- MicroSoft Internet Exporlor 8：从 Internet Explorer 8 开始，浏览器默认有“开发者工具”支持。可以通过“工具 -> 开发者工具”或者按 F12 键激活。
- Webkit（Safari) Web Inspector：Webkit 开源项目发布的 Web Inspector 工具可以很好的集成到 Apple Safari 浏览器中，并为 Apple Safari 浏览器提供 JavaScript 脚本开发、调试与性能剖析功能。
表 1. JavaScript 性能分析工具功能对比
| 功能 | Mozilla Firefox Firebug | Internet Explorer Developer Tools | Webkit (Safari) Web Inspector |
|---|---|---|---|
| 时间片剖析 | 支持 | 支持 | 支持 |
| 调用流程剖析 | 不支持 | 支持 | 支持 |
| 无关过滤 | 不支持 | 不支持 | 不支持 |
| 父子节点统计分析 | 不支持 | 不支持 | 不支持 |
| 离线分析 | 不支持 | 不支持 | 不支持 |
| 快速检索 | 不支持 | 不支持 | 不支持 |
| 匹配匿名函数名 | 部分支持 | 支持 | 不支持 |
| 包含程序源代码 | 支持 | 不支持 | 不支持 |
功能描述 :
- 时间片剖析：支持时间片剖析。
- 调用流程剖析：支持调用流程剖析。
- 无关过滤：支持快速过滤无关或者占用很小的函数，帮助分析主要的问题。
- 父子节点统计分析：支持显示父子关系并且能便捷的在父子节点之间导航。
- 离线分析：支持离线分析。
- 快速检索：支持通过函数名称快速搜索。
- 匹配匿名函数名：能够得到 JavaScript 中使用的匿名函数的方法名或者成员函数名称。
- 包含程序源代码：分析的时候支持查看程序源代码。
相对于基于 Java 语言上的各类性能剖析工具，基于 JavaScript 的性能剖析工具目前还不是很丰富，而且不同浏览器提供的功能也各不相同。从上面的功能对比表中，我们可以看到目前的 JavaScript 性能工具对于后期的离线分析、无关过滤以及快速检索的支持还不完善。但这已经可以帮助我们查找与解决 JavaScript 执行上的性能问题。对于特定的浏览器上的 JavaScript 性能问题，我们可以选择其中最合适的工具进行性能剖析。
剖析 IBM Mashups Center 的 JavaScript 执行性能
接下来，我们将逐步展示一个典型的脚本剖析过程。示例将使用 Developer Tools for Internet Explorer 8（IE8）来对 IBM Mashups Center 的应用做一个 JavaScript 执行的剖析。对于其它浏览器上的性能剖析工具，其基本步骤基本类似，就不再重复叙述。这里，我们准备剖析 IBM Mashups Center 在用户登录的动作，在用户输入用户名和密码做登录后，IBM Mashups Center 会显示该用户的默认主页。下面是主要的步骤：
- 启动浏览器：打开 Internet Explorer 8 浏览器，清空浏览器缓存。
- 装载页面：输入我们需要剖析的 URL，等待页面装载完毕。这里我们建议 Internet Explorer 8 只装载我们准备剖析的页面而没有同时装载其他页面。
- 启动性能剖析工具：启动 Internet Explorer 8 的“工具”菜单，找到“开发者工具”（Tools->Developer Tools），点击启动“开发者工具”界面。
- 开始性能剖析：在“开发者工具”用户界面，选择“Profiler”条目。当我们准备好开始做剖析动作时，点击“开始剖析”按钮。
- 完成用户动作：回到 IBM Mashups Center 页面，做页面登录动作，等待页面登录完成。
- 停止性能剖析：回到“开发者工具”界面，点击“停止剖析”。
- 得到并分析结果：“开发者工具”界面显示这次性能剖析的结果。
当剖析动作结束以后，“开发者工具”界面会显示此次剖析的结果。它可以有两种显示方式剖析结果：调用流程树视图 或者 函数列表视图。
- 调用流程树视图：在这个视图，用树状图来显示 JavaScript 脚本执行流程和它们的父子结构。在每个节点显示一个方法，并列出该方法的父方法、它被父方法调用的次数统计、它调用的子方法以及包含子方法的时间和不包含子方法的时间。
- 调用次数（count）：表示在结构树里，当前方法被其父方法在当前调用关系里的调用次数统计。它并不代表该方法在剖析采样时间段内被调用的总次数。
- 包含子方法的时间（inclusive time）：表示在结构树里，当前方法消耗的总时间，包含花销在当前方法调用的子方法的时间。
- 不包含子方法的时间（exclusive time）：表示在结构树里，当前方法内部消耗的总时间，不包含花销在当前方法调用的子方法的时间。
图 1. 调用流程树视图
- 函数列表视图：在这个视图，列表显示每个方法的统计信息。对于每个方法，显示总的被调用次数、总的包含子方法的时间、和总的不包含子方法的时间。
图 2. 函数列表视图
前面我们通过 Developer Tools for Internet Explorer 8（IE8）对 IBM Mashups Center 的登录动作进行了 JavaScript 性能剖析，下面我们来分析一下这个结果。通过“函数列表视图”，我们很容易找到那个方法调用占用了最多的时间，或者被调用的次数最多。通过“调用流程树视图”，我们可以查找是哪些方法调用了那些最重的函数。
- 被调用次数最多的函数：通常需要我们在“调用流程树视图”中看他们被调用的情况，调查是谁在调用这个方法。是不是设计要求被调用这么多的次数？或者是被包含在了一个不被预期的循环里。当发现这类情况时，通常我们需要结合源程序看程序逻辑来判断，一个常见的问题比如循环里面一个子函数调用总是返回相同的值，把这个子函数调用移动到循环外面可以提高性能。
- 包含子方法的时间占用最多：通常需要我们同时考虑不包含子方法的时间的占用情况。如果不包含子方法的时间比较小，那就是它的方法占用了大部分时间，需要在“调用流程树视图”里查找其调用的子函数。
- 不包含子方法的时间占用最多：通常我们需要结合该方法的被调用次数来计算平均时间。如果单次平均时间比较小，那表示这个方法被调用的次数太多，需要我们考虑如何减少调用次数。如果单次平均时间比较大，那就需要结合源程序去优化程序的结构或者算法。
在我们对 IBM Mashups Center 的登录动作的性能剖析结果中，我们可以发现：
- 在 函数列表视图 中，函数“changePageContent”内部占用了超过 45% 的时间，这是不包括子方法的时间。我们需要进一步了解是谁在调用这个方法，以及它为何会占用这么多的时间。
- 然后，我们切换到 调用流程树视图，开始查找这个占用时间最多的函数它在 JavaScript 调用堆栈里的位置，最后我们找到了它的上下文关系。如图 3 所示：
图 3. 示例：changePageContent 函数在调用流程树视图中的位置
- 根据图 3 指示的上下文关系，我们可以得到几个相关的函数名称，以及它们之间的调用关系。从初步判断，我们可以理解为 JavaScript 脚本在处理 Mashups page 的内容更新与渲染。
- 如果需要进一步分析，需要结合 JavaScript 的源码来进行进一步的分析。
通过以上的性能剖析，已经能够帮助我们找到页面 JavaScript 脚本执行在各个函数中的分布以及它们的上下文关系。对于比较复杂的 JavaScript 脚本性能问题，通常需要结合源码源码阅读，添加日志输出等方法来定位问题，所有这些可以帮助我们快速定位、分析、验证脚本中的性能问题。
本文我们主要讨论了如何对于页面渲染时间的性能分析，首先介绍了几个主要浏览器的性能剖析工具，然后结合对 IBM Mashups Center 的性能剖析示例，介绍了如何利用工具来进行性能剖析与问题定位。
学习
3817
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
