[译]性能概述

本文选译自《Performance Overview》。

导语

性能作为所有软件产品的重要设计标准。如果程序运行缓慢或显示转圈的光标，用户很可能对产品感到失望并寻求替代品。维持软件达到一个可靠的性能水平需要你的努力，你越早考虑这些问题，就越容易找到并解决性能问题。

谁该阅读这份文档

性能概述是针对新入软件性能分析领域开发人员的基本指导。本文档提供了管理性能和定位及解决常见性能问题的一个概览。它还向你介绍了用于定位和解决性能问题的工具和文档。

本文结构

本文档包含以下章节：

• 为了性能而开发描述了影响性能的关键因素和在软件中实现最佳性能的方法。
• 性能开发基本建议描述了代码中需要分析的常见区域和提供某些基础性的技术。
• 性能开发工具描述了程序中可用于性能分析的工具。
• 做初步的性能评估带你了解某些重要工具的基础和如何使用其解决性能问题。

为了性能而开发

性能做为软件设计时需要时常考虑的因素并变得日益紧迫。如果你等到开发周期行将结束时才去做性能优化，这样对于完成关键的改进未免有点晚了。性能在设计初期就应当考虑并需要在整个开发周期持续地改进。

当然，为了完成好的性能设计，首先要理解性能到底是什么。这已章节将提供影像性能的背景知识，即OS X和iOS中这些因素的清单，以及如何对这些因素进行检测。

何为性能？

“性能”一词对于不同的人意味着不同的事物。所以在着手对你的应用进行性能改进探秘之前，最好是在当下理解这一词条的含义。

许多人将性能等同于速度。诚然，如果程序在一秒钟内完成复杂的操作，你可能会认为该程序具有良好的性能。虽然，就其本身而言速度可能是具有误导性的测量。在复杂的软件系统中，操作的速度并不是固定值。如果在不同条件下执行相同的操作，需要完成该操作的时间都会有很大的不同。这是因为程序仅仅是在本地系统上众多处理共享资源的进程中的一个，这些资源的使用（或滥用）会影响所有其他的进程。

下面的部分从两个不同的方面解释性能：资源的有效使用和性能感知。这两个概念都会对你的应用程序设计和实现产生重要的影响，只有了解如何结合使用它们才可以创造更好的整体性能。

资源的有效使用

计算机为所有运行的进程提供了有限数量的资源。在最低的层级，这些资源分为以下几类：

• CPU时间
• 内存空间
• 磁盘空间

所有的数据都存储在内存中，或是在某种大容量存储设备上，必须由中央处理器进行操作。高效的应用程序会小心地使用所有的这些资源。下面的章节提供了关于每一种类型资源的详细说明及其对程序的影响。

CPU时间

CPU时间由系统分配所以你必须尽可能地利用好这些时间。由于OS X和iOS都实现了对称多处理，系统中的每个线程都会分配的时间片（最多10毫秒）来运行。在那段时间的末端（或者多数情况下）系统会回收CPU的控制并把它分配给其他线程。

在有许多活动线程的典型系统中，如果每个线程都用完了所分配的时间，性能将非常糟糕。这就导致产生了编写应用程序的最为重要的一个目标：

如果你对程序无事可做，它就不应该消耗CPU时间。

完成这一目标的最佳方式是使用基于事件的模型。使用现代化的基于事件处理的系统，例如Cocoa以及Cocoa Touch，这意味着程序的线程只在有工作时才运行。

当你的应用有工作可以完成时，它应该尽可能高效地利用时间。这意味着需要为期望处理的数据采用合适的算法。同样意味着对于其他资源的使用，例如完成特定操作的可用的向量单元（OS X中的AltiVec和SSE）或者图形处理器，这产生了以下目标：

尽可能地将工作移出CPU。

获取如何高效地使用CPU时间，请参见基本优化建议。获取关于改进绘图操作的建议，请参见绘制代码。

内存空间

现代计算机硬件中的内存正逐渐由速度较慢（但容量却更大）的存储器构成。最快的存储器是CPU的寄存器。接下来是L1级缓存，再接着是L2和L3级缓存。再接下来稍快的存储器是内存。最慢的存储器是OS X磁盘上的虚拟内存页面组成，且必须在完成分页后才能使用。

在理想的情况下，每一个应用都足够的小以能够装进系统最快的高速缓存中。不幸的是，大多数应用程序的代码和数据存放在内存或者磁盘上。因此，最大程度的减少应用程序的代码和数据在这些较慢媒体上花费的时间显得尤为重要，这产生了以下目标：

减少程序的内存占用。

减少程序的内存占用可以显著地提高其性能。小的内存占用通常有两个优点。首先，你的程序越小，它所占用的内存页就越少。较少的内存页，通常意味着更少的分页。其次，代码通常较小是作为大量优化和更好结构的结果。于是，只需要较少的指令来执行既定任务以及任务的所有代码都能聚集在同一组内存页中。

除了降低应用程序的内存占用，还应该尽量减少应用程序中的可写内存页的占用。可写内存页存储应用程序的全局或已分配的数据。在OS X中，如果需要的话，这样的页面可以被写入磁盘，但这样做是比较慢的。在iOS中，这些页面的内容必须由应用程序本身清除，在以后可能需要应用程序重新创建这些在页面中的数据。在这两种情况下，系统会努力地本应该用于执行应用程序代码的时间来释放内存。

获取有关如何减少程序内存占用的基本信息，请参见应用内存占用。获取关于更加高效地使用内存的建议，请参见内存分配代码。

磁盘空间

文件系统的性能对于任何计算机都是重要的，因为几乎所有的东西都以文件的方式保存。你的应用程序、数据，以及操作系统本身都存在于文件中，相较于系统的其他部分，从设备上加载这些文件到内存则显得不可思议的慢。文件系统，无论是本地的还是基于网络的，都是性能上的最大瓶颈。这就产生了另一个目标：

消除不必要的文件操作并在其他的信息实际需要时才进行操作。

通过消除和延迟文件的操作来解决这个性能瓶颈，对于改善应用的整体性能非常重要。数以百万计的处理器周期包括文件的数据请求的时间到程序实际找到数据的时间。如果你的程序访问了大量的文件，它可能在接收所有请求数据之前等待数秒。

另一个重要的事情是你的应用程序和它创建的任何文件可能是在网络上，而不是在本地硬盘。尤其是OS X中，大量的使用了网络，所以你不应该对文件的位置进行假设。

获取关于如何改进程序中文件性能的基本信息，请参见文件访问代码。

速度的感知

即时你为优化性能调整了应用程序的代码，这完全有可能让你应用的行为在用户面前表现得缓慢。这样的问题是不可避免的：如果你有大量工作要完成，你就需要CPU时间和资源来完成相关工作。你唯一可以做的就是让应用程序来表现速度，这形成了下面的目标：

让你的程序响应用户。

对于用户来讲响应能力通常比绝对的速度更加重要。只要程序能够及时地响应命令，用户才会愿意接受任务需要更长时间完成的事实。速度的感知是让用户在程序后台处理数据时能够继续操作。提高应用中并发任务执行数量会是使其响应用户的绝好办法。并发通常使用GCD或者线程来实现。当你的应用主线程响应用户时，分发队列或者后台线程则执行计算或者耗时的任务处理。

另一种让你的应用更快的常规方式是改进其启动时间。一个应用程序花费一秒或两秒来启动都显得浪费了。在那个时间段，它没有必要去响应用户及去加载不是立即需要的（或是根本不使用的）资源，这完全就是浪费。

获取有关改进启动时间的信息，请参见启动时初始化代码。获取如何改进程序感知性能的信息，请参见利用性能感知。

性能跟踪

保证高性能的唯一方式是在产品的整个开发过程中包含性能指标并按照指标来对产品进行测量。高性能不是你在开发周期行将结束时移植到代码中的功能，它与整个开发周期密切相关。在编写代码时，清楚代码对程序整体性能所产生多大的影响非常重要。如果你尽早地检测到性能问题，你就很有机会在为时已晚之前修复它。

确定你已经完成或者超过预定目标的方法就是收集数据。苹果提供了多个工具来监测和分析程序的性能。你也可以直接在你的代码中创建测量工具来帮助自动化地收集数据。不管你使用何种方法，你都需要定期体验这些工具并分析其结果。

建立性能基线

你需要做的第一件事就是决定一组需要测定的指标的性能基线。选择对你的用户最重要的任务并定义一系列的执行限制来执行任务。例如，你也许希望应用程序在1秒内加载和启动它的初始窗口，或者你想要保持总的内存使用在一个既定的目标范围内。

被你选来评测的功能应该能反应用户的需求。你的市场部门应该能够帮助你找到一系列和用户相关的任务。如果你有一个既定的产品，请和你的用户交流并找出他们认为慢的以及可以改进的功能作为你计划更新的部分。

一旦你有了想要追踪的任务列表，你需要为每一个任务设定性能指标。对于已经存在的产品，你可以简单地在之前版本的基础上改进性能。你同样也可以试着去测量竞品的性能并设定达到或超过它性能的指标。如果你有一个新产品，你可能不得不体验大量的产品来找到合适的值。或者，你想要建立激进的基线值来试图尽可能的接近那些产品。

正如其他性能指标一样，一致性非常重要。建立基线指标的过程应该包括你收集这些指标的系统信息。记录系统的硬件和软件配置，并在同一个配置上运行测试。尝试使用尽可能低的硬件配置来建立你的基线。在一台快速机器上的测量可能会导致你相信软件执行得很好，但许多用户会在较慢处理器和更少内存的计算机上运行软件。

尽早测量并经常测量

性能数据不是你收集一次就希望在应用中找到所有的性能瓶颈。如果你长时间维护着应用的性能，就越容易找到问题。维护历史使得容易观察应用的性能是提升了还是下降了。如果下降了，你可以在产品发布前采取措施来解决问题。

另一个需要时常测量性能的原因是你可以关联代码与测试结果。如果性能在特定的里程碑下降了，你可以复查那个阶段的代码并且试图从中找到原因。同样的，如果性能提升了，你可以使用近期的代码作为好的编程实践模型并鼓励你的团队使用相同的技术。

当你完成部分程序的部分功能时就应该着手做性能的测量。当新功能完成添加时，你可以为这些新的功能进行测量。将一套自动诊断程序引入你的程序，这使得团队中的成员能够更加容易地立即查看到结果。有了随时可用的信息将使他们更方便地在检查代码之前解决性能问题。

分析结果

收集数据是定位性能瓶颈最为重要的步骤。但是当你有了数据，如何使用它找到问题同样重要。分析性能数据不是简单地看输出结果就能够立即找到问题的。你也许幸运地快速找到了问题，但是某些微妙的问题需要更加细心的分析才能发现。

帮助分析结果的一种方法是将其绘制成图形。可视化的性能数据可以帮助你查看趋势，这比数据在电子表格中或者基于文本的媒介中来得更快。例如，你可以绘制完成一个单独操作的时间对于特定的版本，以确定性能在个版本间是提升还是下降。在相同里程碑下绘制多个数据集也能够揭示性能趋势，并提供为什么性能增加或减少的洞察力。

分析更高级的算法

当你分析性能数据时，请对问题所在的抽象层次保持一个开发的思维。假设你的数据暗示一个特定的函数内花费了很多时间。这有可能说明函数中的代码需要优化以便使其执行更快，但这是造成问题的真正原因吗？再次运行你的程序，但这次检查该函数被调用的次数。如果这个函数调用了一百万次，问题可能发生最初调用它的更高级别的算法中。如果函数被调用一次，那么问题的所在就是这函数本身。

注意：Instruments是一个分析代码运行时行为的强大工具。Instruments可以为你记录多个指标并依此显示它们，使得更加容易查看趋势。Instruments的数据挖掘能力是另一种快速地在更高级别算法中定位问题的好方法。获取更多关于Instrument及其他苹果提供的相关工具的信息，请参见性能工具。

在分析数据时，你需要了解和考虑到性能工具本身有一定的局限性。例如，采样程序可能会采集应用程序花费了大量时间的地方，但你应该明白这些工具得出众多结论之前如何收集数据。采样工具并不跟踪每一个函数调用。相反，它们提供了基于在固定的时间间隔采样的程序的统计分析。使用这些工具的输出作为指南，但确保将你记录的其他数据与之关联。

其他分析技术

如果你对某个性能问题的真正原因有疑问，请避免对问题的原因做出假设。相反，通过关注数据收集工作的相关代码来改进你的分析。尝试使用不同的工具来收集新的信息。不同的工具可能提供一个揭示了更多的实际问题的独特视角。

一些额外可以用来分析程序的方法如下：

• 在调试器中查看代码。在调试器中走查代码可以揭示导致代码的速度减慢的逻辑错误。
• 为代码添加有代码执行的相关的日志输出的断点。添加断点追踪初始化代码的例子，请参见启动时初始化代码。
• 尝试编码时使用解决问题的替代方案并看看它们释放遭遇类似问题。

性能开发基本建议

本章为如何优化你的程序提供了实际建议。它提供了你应该使用性能工具监控的区域的建议，也提供了一系列改善性能的实际建议。

常见区域监测

许多性能问题可以在程序中的特定部位被追踪到。当你设计和实现你的代码时，你应该监视那些区域以确保它们满足你设定的性能目标。

程序的关键任务代码

当你设计你的程序时，考虑用户使用最多的任务或工作流。在实现阶段，确保监视那些任务的代码并保证它们的性能不低于预期水平。如果遇到了性能问题，你应该立即采取措施来修复这些问题。

程序的关键任务在各个程序之间各有不同。例如，一个文字处理工具可能需要在文本输入和显示上表现得很快，然而一个文件管理程序却需要在硬盘上扫描文件及目录时很快。这取决于你决定哪一项任务是用户最希望实现的。

绘制代码

大多数程序都完成一定数量的图形绘制工作。如果你对程序只使用标准的窗口和控制器，那你也许不需要太过于担心图形绘制的性能。然而，如果你做任何自定义的绘制操作，你需要监视你对图形绘制代码并确保其运行在可以接受的水平。特别的，如果你支持下面的功能，你需要探究优化图形绘制代码的方法。

• 自动缩放。
• 自定义的视图绘制代码，尤其是部分视图的更新而不是整个视图。
• 文本的图形化。
• 完全的透明视图。

启动时初始化代码

启动时间作为初始化程序数据结构以及应用准备接收用户输入的时机。然而，许多程序在启动时完成了超过其所需的大量工作。在大多数情况下，启动时执行的任务可以被推迟到应用已经显示界面以及开始处理事件的时候。这样的延迟会让你的用户感觉应用很快，这会留下一个好的印象。

对于运行在OS X 10.3.3及其早期版本上的应用程序，另一种改善启动时间的方式是预绑定应用。预绑定涉及到库地址范围的预计算并将这些值存储到应用的二进制文件中。这一步骤消除了启动时动态加载器（dyld）对于地址范围的计算。在OS X 10.3.4及其以后版本中dyld的预绑定改进将不再必须。同样的，iOS也不需要预绑定。

文件访问代码

文件系统是讲信息传入到内存和CPU中的重要部分。在访问一个文件的时候，会执行数以千万计的指令。因此，检查你的程序使用文件的方式并确保这些文件确实是必要的且使用得当显得尤为必要。

尽量减少使用文件的数量是提高文件相关性能的一种方法。当你访问文件时，头脑中要记住以下几点：

• 了解系统如何缓存文件数据，并知道如何优化这些缓存的使用。避免自己缓存数据除非你打算不止一次使用它。
• 尽可能顺序地读写数据。在一个文件中跳跃需要花去额外的时间去寻找新的位置。
• 尽可能从文件中读取稍大的数据块，记住一次性读取过多的数据可能会导致不同的问题。例如，读取一个32 MB字节文件的全部内容可能在操作完成之前触发这些内容的分页。
• 避免非必要地关闭和重新打开文件。如果在允许缓存的情况下，这样做可能造成即使在数据不改变的情况下缓存等待刷新。

应用内存占用

代码的容量大小可以对系统的性能产生巨大的影响。程序使用的内存页面越多，系统及其他程序的可用内存将会更少。内存压力会实际地造成分页以及整个系统运行放缓。

管理代码的内存占用主要关乎于代码和数据结构的组织。你需要在内存中拥有正确的区段以及不会造成任何的内存分页和不必要的读取。造成内存的大量占用有以下原因：

• 代码中包含未使用的代码。编译器通常会按照编译模块来组织代码，这并不总是最好的技术。基于代码的功能来组织代码模块会是更好的选择。
• 静态或常量数据存储在可写内存页。在内存分页时，数据会被不必要地写入磁盘。尽其所能地将这些数据移到不可写的内存页以便能够快速地销毁。
• 程序导出多于实际需要的符号文件。符号文件会占用空间并仅被应用中需要调用的外部模块代码使用。移除任何不在外部使用的符号文件。
• 代码未被编译器和链接器正确优化。确保尝试编译器的优化设置并观察哪一个对应用效果最好。
• 程序中引入太多的框架。只加载程序中实际使用的框架。

内存分配代码

程序会分配内存来存储固定的及临时的数据结构。每次内存的分配都与CPU及内存的消耗相关联。了解程序何时分配内存以及内存如何使用将帮助你降低上述的性能消耗。

了解程序中内存的用处可以帮助你决定减少内存使用的方法。你可以使用可用的性能工具在造成大量内存分页之前来找出自动释放的Objective-C对象是否被释放掉。你也可以使用这些工具来找到由代码缺陷造成的内存泄漏。观察调用malloc的次数也许可以找出你可以重用的内存块而不是创建新的内存空间。

一个内存分配的重要法则是保持“懒惰”。延迟内存的分配直到你真正地使用这部分内存时。获取更多延迟内存分配的信息，请参见保持懒惰。

获取更多优化内存分配的信息，请参见《Memory Usage Performance Guidelines》。

基本优化建议

在你开始实现新的程序之前，有几个你需要考虑的性能强化的点。尽管你不会在所有情况下利用好全部的优化，但你至少应该在设计阶段考虑它们。

保持懒惰

一个改善应用性能的简单方式就是保证应用不去做任何不必要的工作。应用程序的每一时刻都应当被用来响应用户的当前请求，而不是预测将来的请求。如果你不是立即需要某个资源，比如包含属性窗口的nib文件，那就不要加载它。类似的行为会耗费时间来执行，因为它访问了文件系统，并且如果用户并没有打开这个属性窗口，加载nib文件的过程就是在浪费时间。

需要遵循的基本法则就是等待用户向你的应用程序请求，然后使用必须资源来满足其请求。只有在可测量的对性能有益的情况下才去缓存数据。基于应用程序会变快的假设去提前做缓存事实上会在低内存情况下反而降低性能。在这种情况下，你缓存的数据在其使用前也许会被交换到磁盘上。如此，之前缓存数据所得到的任何好处都变成了性能的损失，因为这些数据必须在试用期两次从磁盘上读取。如果你真的想要缓存数据，请在完成一次操作之后进行。

其他一些保持“懒惰”的注意事项如下：

• 延迟内存的分配直到实际使用该部分内存时。
• 不要零初始化（zero-initialize）内存块。调用calloc函数来完成。
• 给系统懒加载代码的机会。配置和组织你的代码以便系统只加载当前操作所需的代码。
• 延迟读取文件的内容直到实际使用这些信息的时候。

利用性能感知

在多数情况下性能的预估和实际性能同样有效。许多程序的任务可以在后台执行，使用分布队列（dispatch queue）或者空转时间（idle time）。这样做可以让应用的主线程去自由地处理同用户的交互并使用户感觉程序界面更具响应性。当你设计你的程序时，考虑哪些任务可以有效地移到后台去。例如说，如果你的程序需要扫描一些文件或者做长度的统计，请使用分布队列来做。

另一个提高性能感知能力的方法是让你的应用快速启动。在启动时，延迟任何不立即用于应用程序界面展示的任务。例如，延迟创建大量的数据直到应用程序完成启动后并将其显示在主窗口。如果你的主窗口显示的某些数据需要在启动时计算或者获取，在窗口上显示一个进度指示器或者其他的状态信息来提示数据正在被加载。对于那些使用插件的应用，避免加载插件直到代码真正需要插件时。

使用基于事件的处理

所有现代的Mac应用都应该使用Cocoa事件系统或者Carbon事件管理器。（同样的，iPhone应用必须使用由UIKit框架提供的基于触摸的事件系统。）你的应用程序绝不应该向系统轮询事件。这样做相当地低效。事实上，当没有事件处理时，轮询代码百分之百地是浪费CPU时间。现代化得基于事件的API都被设计成能提供以下优点：

• 它们使你的应用程序对用户更具响应性。
• 它们降低了应用程序的CPU消耗。
• 它们最小化了应用的工作集-在任何时间加载进内存的代码页数量。
• 它们使得系统持续地管理电源（省电）。

包括用户的事件，你同样应该避免去轮询。OS X和iOS中的线程会使用run loop来提供对定时器、网络事件以及其他收入数据的按需响应。许多框架同样会使用针对特殊任务的异步编程模型，并在任务完成时通知指定的回调函数或方法。在OS X 10.6及其以后版本中，分发源（dispatch sources）同样提供了异步接收事件并在分布队列上执行的功能。

改进任务的并发能力

在多核计算机上，并发是另一种同时改进程序的感知性能和实际性能的方式。一个可以同时执行多个任务的程序可以并行地在多核计算机执行这些任务。甚至当计算机只有一个核心时，可以将你的代码分解为多个部分且异步的任务，使之快速且正确地执行。特别地，你应该在分布队列上执行自定义的任务并让你的主线程有时间主要去处理用户事件以及更新用户界面。

在你开始添加并发支持前，请确保你的程序如何正确地实现任务的完成。将你的代码分解成不同的任务需要考虑到程序的数据结构及代码路径。执行共享数据的任务可能需要在串行的分布队列上同步地访问这些数据。

获取更多在应用如何实现并发的信息，请参见《Concurrency Programming Guide》。

使用Accelerate Framework

如果你的应用程序执行大量的数学运算，你应当考虑使用Accelerate Framework（Accelerate.framework）来加速这些运算。Accelerate Framework利用了处理器中的任何可用向量单元比如Intel x86的SSE扩展）来执行并行的多重运算。通过该框架编码，而不是直接使用这些向量单元，可以避免为每个平台架构单独单独的代码。Accelerate Framework在所有OS X支持的架构中得到了高度的优化。

类似Instruments 的工具可以帮助你找到程序中能受益于Accelerate Framework框架的部分。关于更多如何使用这些工具的信息，请参见性能工具。

使应用现代化

如果你的程序最初被设计运行在旧版本的Mac OS上，你应该更新你的代码以支持OS X。尤其，你应该避免使用旧的技术，如Carbon或QuickDraw类似的传统技术。相反的，你应该使用Cocoa或Cocoa Touch来构建应用。同时你需要更新二进制形式到Mach-O。Mach-O格式仅支持基于Intel的Macintosh和基于iOS的设备。

获取iOS中可用技术列表，请参见《iOS Technology Overview》。

性能工具

有几个用于性能数据收集的图形工具和命令行工具。一些工具和Xcode同时安装。其他的可用工具可以从苹果开发者网站下载。

关键应用

尽管Xcode自带多个收集性能数据的工具，但这里只有少数你会经常用到。

Instruments

Instruments由一系列提供图形界面的高性能分析工具组成，这些工具为你的应用在运行时的行为提供前所未有的信息。并非某一时刻只显示你的程序的一个方面，你可以使用多个Instruments工具来配置每一次分析会话，而每一中工具都收集了特定性能的数据。所有Instruments工具的数据都会并排显示，这使得关联数据到某一个工具和检测应用行为趋势更加容易。

你可以使用Instruments工具收集如下类型的数据：

• 基于Core Data的应用程序性能。
• 文件系统读、写及其他操作。
• 垃圾回收代码的相关统计。
• 图形操作和性能相关的信息。
• 关于对象及内存分配的统计。
• 内存泄漏信息。
• 应用程序运行时统计采样。
• 关于进程和系统级活动的信息。
• 关于Java线程活动的信息。
• 关于Cocoa分发的事件信息。

获取如何快速使用Instruments的方法，请参见使用Instruments。欲了解详细信息，请参见《Instruments User Guide》。

分析工具

Instruments不仅是收集应用性能数据的分析工具。一些分析工具还面向寻找特定类型的性能问题。表3-1列出了Xcode中以及安装的和可供下载的分析工具。

表3-1 分析工具

工具	描述
OpenGL Driver Monitor	收集GPU相关的性能数据，包括显存相关的数据、视频总线交通以及硬件间的stall（译者注：stall是停止运转的意思，发生在当CPU执行时，所需要的数据却不在寄存器或缓存中，需要去装载内存的数据，这期间有一个等待，这里叫做stall。）你可以使用这些信息来找到OpenGL应用中造成偶然 地变慢的原因。该工具作为Xcode中图形工具的一部分，也可以在苹果开发者网站下载。
OpenGL Profiler	为你的OpenGL应用创建运行时文件。你可以查看函数统计和应用中OpenGL的调用栈历史。该工具作为Xcode中图形工具的一部分，也可以在苹果开发者网站下载。
heap	列出指定进程中所有堆内存malloc的区域。该工具安装在“/usr/bin/”目录下。
leaks	在进程的内存区间中搜寻所有已分配却为被引用的内存块。该工具安装在“/usr/bin/”目录下。
vmmap	显示分配给指定进程的虚拟内存区域。你可以使用该工具来分析进程的内存使用。该工具安装在“/usr/bin/”目录下。

检测工具

检测工具作为自动收集数据的被动工具。为使用这些工具，请在运转程序功能的时候同时保持这些工具运行。然后，你就可以分析这些工具产生的数据以更好地理解你的程序性能特征。某些程序可能会一直运行。其他大多数的程序会在收集完性能数据后终止运行。表3-2列举了OS X中的和可供下载的检测工具。

表3-2 检测工具

工具	描述
Activity Monitor	显示当前活动进程常用的内存使用和CPU使用相关的统计数据。你同样可以从当前应用的进程进行采样。该工具提供的信息和top工具类似。该工具安装在“/Applications/Utilities/”目录下。
Quartz Debug	显示被重绘屏幕的实时更新。你可以使用该工具来分析你的绘图行为。该工具作为Xcode中图形工具的一部分，也可以在苹果开发者网站下载。
fs_usage	当生成页面故障及调用文件系统函数时，显示正在进行的文件系统活动列表。你可以使用该工具来理解程序的文件访问模式。该工具安装在“/usr/bin/”目录下。
sc_usage	显示正在进行的系统调用和页面故障统计数据。该工具安装在“/usr/bin/”目录下。
top	显示当前活动进程常用的内存使用和CPU使用相关的统计数据。该工具会动态更新信息，以便在运行时看到趋势。该工具安装在“/usr/bin/”目录下。

硬件分析工具

CHUD工具包括一些OS X中用于硬件及低等级软件分析的补充工具。（这些工具不支持iOS。）表3-3列举了这些工具中的一部分，也可以在苹果开发者网站下载。

表3-3 CHUD工具

名称	描述
Reggie SE	让你检查并修改CPU和PCI的配置。
acid	分析TT6E指令追踪和细节分析的命令行工具。你可以使用该工具来检测队列中的错误指令，如操作数未对齐，数据依赖等待及加载溢出。
simg4	Motorola 7400 处理器上的精确累加模拟器的命令行工具。（译者注：不解释了，OS X 10.5及更早版本可用）
simg5	IBM 970 处理器上的精确累加模拟器的命令行工具。（译者注：不解释了，OS X 10.5及更早版本可用）

其他命令行工具

表3-4列举了OS X中你可以用来检测和分析性能的其他命令行工具。（这些工具在iOS中不可用。）这些工具全部位于“/usr/bin/”目录下且必须以命令行方式运行。大多数工具随Xcode工具安装。获取更多有关这些工具的信息，请参见OS X的man帮助页。

表3-4 命令行工具

名称	描述
atos	在正在运行的可执行文件中，将符号名称和该符号的数字地址之间的转换。
c2ph	根据对象文件中成员的偏移值显示其C结构。
gprof	基于对程序执行分析来创建执行配置文件。
malloc_history	显示指定进程malloc的行为历史。
nm	显示一个或多个对象文件的符号表信息。
otool	以可读性更高的方式显示Mach-O执行文件的内容。
pagestuff	显示Mach-O执行文件的逻辑页信息。
pstruct	根据对象文件中成员的偏移值解析并显示其C结构。
sample	基于对程序执行分析来创建一个执行配置文件。
vm_stat	显示Mach的虚拟内存统计数据，包括活动的、非活动的、线性的（译者注：线性指一定时间内不能被交换的存储区域）以及空闲的内存页统计。该工具同样显示页面故障和其他活动信息。

初步性能评估

以下内容由于可读价值不高，译者并不会进行翻译。对于下面的一些工具和命令的使用，如top命令，可以在终端中使用man top命令来查看帮助文档；Instruments的使用，可以参考《Instruments User Guide》；Quartz Debug已经不在Xcode工具中提供，需要去单独下载Graphics Tools才能使用。

使用top

使用Instruments

使用Quartz调试