利用持续改进循环，为 App 建模并测量和提升 App 的性能。
概览
用户会期待 App 能够运行良好。如果 App 启动用时很长，或者对输入的响应很慢，那么用户可能会觉得 App 工作不正常或反应迟钝。如果 App 发出大量网络请求，那么可能会增加用户的流量费并消耗设备的电池电量。任何这类行为都可能会让用户不满，导致他们卸载 App。
科学地处理问题，从而规划和实施性能改进：
-
收集用户所遇问题的相关信息。
-
衡量 App 的行为来查找问题的根源。
-
规划一项更改来改善状况。
-
实施这项更改。
-
观察 App 性能有没有改善。
这些活动会形成一个持续改进的循环，如下图所示。
为用户着想，尽可能减少资源使用，改善用户对你 App 的观感。下面列出了一些具体的益处：
-
缩短 App 启动时间可以提升用户体验，并降低 iOS 看门狗计时器终止 App 的几率。
-
减少内存总体用量可以降低 iOS 在后台释放 App 内存的概率，并加快用户切回到你的 App 时的响应速度。
-
减少磁盘写入可以加快 App 的整体性能，使它更加灵敏，同时减少对用户设备存储的损耗。
-
降低挂起率并缩短挂起时间，让用户对你 App 的性能和响应速度的体验更佳。
-
降低电池电量消耗并减少对高能耗设备功能的使用，可以让你的 App 变得更加可靠，也有助于确保用户在需要时，能够使用设备的其他功能。
即使你的测量和观察没有显露出紧迫的性能问题，最好也要完成性能改进循环，并采取预防措施来确保 App 性能不会下降。
收集有关 App 当前性能的数据
要详尽地了解 App 的性能，请结合使用多个来源的信息：
-
使用 Xcode 中的 Metrics Organizer (指标报告) 可以查看启动时间、挂起率、存储写入次数、内存使用量和能耗等指标。通过该 Organizer，你可以按照设备机型和 App 版本来查看测量结果。
-
使用 MetricKit (英文) 可以在你自己的工具中收集和记录各项指标。这些指标以直方图的形式显示，用于记录一天中观察值的出现频率。MetricKit 不仅包含 Metrics Organizer 中显示的那些指标，而且还包括平均像素亮度、蜂窝网络状况，以及与 App 中自定
OSSignpost事件相关的持续时间。 -
向 TestFlight 测试员征集反馈，了解他们对你 App 的 Beta 版本的使用体验。填写 App Beta 版本的“Test Information”(测试信息) 页面，并请测试员就 App 的性能提供反馈。附上电子邮件地址，以便测试员能够报告他们发现的问题。
-
调查用户对你 App 的发行版本的使用体验反馈。邀请用户通过电子邮件或 App 中的专用界面发送他们的反馈。询问他们的 App 使用体验，包括表现良好的地方和遇到的任何问题。
确定需要改进的最重要方面
利用你在观察中获得的信息，以及你对 App 用途和预期使用模式的了解，找到最重要的改进机会。一些性能问题与所调查的 App 类型无关。如果 App 需要很长时间才能启动或不响应用户操控界面的动作，会让用户感觉 App 难以控制。
另一方面，你在 Metrics Organizer 或 MetricKit 中看到某项指标具有最大的值，并不一定表示这是要解决的最重大问题，因为该值也可能表示你 App 的使用情况与预期相符。例如，与后台音频播放相关的能耗对播客播放器而言或许不是问题，因为用户期望它在后台播放。但是，如果你的 App 是游戏，且在设定中没有后台组件，那么这项指标数据突出就属于异常现象。
在指标报告中看到该数据引人注目，也许表明能效可被提高，但影响最大的更改或许在于使用不影响 App 主要功能的辅助服务。播客播放器可能偶尔需要使用粗略定位服务来向听众推荐当地人感兴趣的播客，但如果高能耗与频繁追踪用户的精确位置相关，则可能表明需要做出改变。
对 App 进行性能分析
你可以选择与你所考虑的指标相关的性能分析模板，使用 Instruments (英文) 对你的 App 进行性能分析：
-
不响应和挂起：使用 Time Profiler (英文) 模板。
-
内存问题：使用 Allocations (英文) 和 Leaks (英文) 模板。
-
能耗问题：使用 Energy Log (英文) 模板。
-
I/O 问题：使用 File Activity (英文) 模板。
-
网络相关问题：使用 Network 模板 (英文)。
与模拟器相比，在设备上进行性能分析可以获得保真度更高的测量结果。如果你收集的信息显示 App 在特定类别或机型的设备上性能不佳，请在该设备上进行性能分析。
寻找导致性能问题的代码，然后制定改进计划。请记住，你的更改可能并不局限于某行代码或某个函数，你也可能需要对 App 进行重大的架构变更。例如，要消除因同步下载网络资源而导致的挂起，需要引入后台操作来处理联网 (请参阅“在后台下载文件 (英文))”，并在下载完成时对主线程执行 UI 更新。
进行后续更改
实施你在调查后规划的更改。在 Instruments 中创建一个“事后”性能分析，并与“事前”性能分析进行比较，确保你的更改带来了改进。你可以考虑在 XCTest (英文) 中编写性能测试，以防止未来出现性能下降并作为这个问题曾经存在并已修复的记录。
将更改后的行为与原始数据进行比较
在更改 App 来解决你观察到的最重大性能问题后，应确认更改达到了预期效果，并且改进的程度已经足够。利用 Xcode Metrics Organizer 中你 App 的各个版本的性能指标图表，查看更改带来了性能改进还是性能下降。
最后，确定你所处理的指标是否仍是最需要关注的指标，又或数据是否指出性能改进循环的下一迭代中需要关注另一个指标。
其他资源
以下文章、Xcode 帮助主题和 WWDC 演讲视频包含有关使用 Xcode 和 Instruments 衡量和改进 App 性能的更多信息。