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

　　快速、流畅、高效能是性能的支柱。但与其看着这些抽象的概念，不如讨论如何能够让现实的计划拥有具体的目标，如“在主视图中加载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秒——运行更长时间的操作。等待时，用户可能会切换到另一个应用。

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

　　首次应答(快速)：用户已经看到开始搜索了，所以他们不用持续的点击搜索按钮;

　　响应：用户已经可以看到搜索结果的文本信息，并且可以使用UI;

　　完整的展现(持续)：继续加载所有内容，包括图片。

　　流畅

　　流畅性可以通过帧每秒(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