规划成本远小于重构

开发人员常说，他们的目标之一是使应用程序

“快”。然而，当他们发布应用时，客户还

是抱怨速度太慢并且反应迟钝。根据微软内部的研究结果，这种问题最常见的根源是缺乏对
性能的规划。让应用程序运行得

“快”，是个不切实际的目标，因为它无法测量。因此，当应

用性能开始下滑时，开发人员往往注意不到。如果性能测试是在特定的硬件或环境条件下进
行的，那么会更糟。
　　快速、流畅、高效能是性能的支柱。但与其看着这些抽象的概念，不如讨论如何能够让现
实的计划拥有具体的目标，如

“在主视图中加载 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)，所以另一个目标应该是降低内存占用。因为根据应用程序的类型不同，内

存占用方面的差异很大，所以在这里无法给出具体的建议。
　　最终用户会非常关注电池的寿命，而对于移动设备来说，流量使用情况也是用户关注