应用性能：规划成本远小于重构

开发人员常说，他们的目标之一是使应用程序“快”。然而，当他们发布应用时，客户还是抱怨速度太慢并且反应迟钝。根据微软内部的研究结果，这种问题最常见的根源是缺乏对性能的规划。让应用程序运行得“快”，是个不切实际的目标，因为它无法测量。因此，当应用性能开始下滑时，开发人员往往注意不到。如果性能测试是在特定的硬件或环境条件下进行的，那么会更糟。

快速、流畅、高效能是性能的支柱。但与其看着这些抽象的概念，不如讨论如何能够让现实的计划拥有具体的目标，如“在主视图中加载 30 张图片的时间应当小于 1 秒”。这类性能规划考虑到了有目的的测试和对性能问题的早期发现。

快速

确定应用程序是否“快”的一种方法，是依据“交互分类（Interaction Classes）”对它进行观察。交互分类是用于描述交互类型及其可接受的交互完成时间。下面是微软在项目中使用的一些样例：

• 快速（Fast）：100 至 200 毫秒——比如​​点击按钮、打开菜单、打开应用栏（App Bar）等；
• 典型（Typical）：300 至 500 毫秒——调整大小、语义式缩放（Semantic Zoom）等；
• 响应（Responsive）：500 毫秒到 1 秒——导航到其它页面；
• 启动（Launch）：1 到 3 秒——冷启动；
• 持续（Continuous）：500 毫秒到 5 秒——下载文件；
• 受控（Captive）：500 毫秒到 10 秒——运行更长时间的操作。等待时，用户可能会切换到另一个应用。

复杂的交互过程可能需要分解成为多个时间点。比如，导航到搜索结果页，可以分解为三个时间点：

1. 首次应答（快速）：用户已经看到开始搜索了，所以他们不用持续的点击搜索按钮；
2. 响应：用户已经可以看到搜索结果的文本信息，并且可以使用 UI；
3. 完整的展现（持续）：继续加载所有内容，包括图片。

流畅

流畅性可以通过帧每秒（fps）的单位测量。对于大多数应用程序，建议目标是被称为“平滑流畅（Buttery Smooth）”的标准，每秒 60 帧。如果应用程序不能保持这个水平的流畅性，那么应当考虑简化显示内容。

高效能

开发人员考虑高效能时应当从用户的角度出发。当用户运行应用程序进行某些工作时，他们通常不会在意 CPU 或网络是不是正在发热。但当用户空闲的时候，应用程序也应当处于闲置状态。因此，所有应用程序的目标是环境资源的零消耗。

如果应用程序会消耗更多的内存，就更容易被钝化（Swapped Out）到磁盘或是被逻辑删除（Tombstoned），所以另一个目标应该是降低内存占用。因为根据应用程序的类型不同，内存占用方面的差异很大，所以在这里无法给出具体的建议。

最终用户会非常关注电池的寿命，而对于移动设备来说，流量使用情况也是用户关注的一个方面。根据微软曾委托进行的一项研究来看，50％的用户将耗电量大作为他们卸载应用程序的原因。幸运的是，通过现代化的性能工具，不仅能测量 I/O 传输，还能够估算应用程序运行所消耗的电量。流量的问题也是如此。

检测

为了完全了解应用程序的性能行为，我们必须规划并嵌入大量的检测内容。读者可以考虑使用更高级的日志框架，比如语义日志记录（Semantic Logging），通过它可以对特定操作的开始和结束进行关联。

测试

空闲的（Quiet，译者注：原意为安静，是相对于测试结果中的干扰而言）系统对测试来说是关键，如果系统后台进行着任何工作，那么可能会直接影响测试结果。为避免这些问题，微软的 Will Sergeant 建议各位读者：

• 关闭后台应用程序。如果读者使用的是 Windows 8，那么要关闭“锁屏应用”。
• 对于托管代码，生成本机代码映像（Native Code Image）。也可以这么解决：运行该应用程序 30 秒以上，然后运行 Windows 8 的系统维护任务。
• 总是运行多个进程，并捕捉这些进程的信息。

硬件

要对在各种硬件和网络拓扑进行测试。因为较慢的网络会对应用程序性能的表现产生灾难性的影响，特别是当它在 UI 线程上试图下载数据的时候。另外，屏幕尺寸也会对性能有显着的影响，因为大屏幕需要同时显示更多的数据。

本文内容出自微软Build 2013 开发者大会上的同名演讲。

查看英文原文： Performance: Planning Costs Less than Rearchitecting