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

  • Jonathan Allen
  • 康锦龙

2013 年 7 月 5 日

话题:架构

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

快速、流畅、高效能是性能的支柱。但与其看着这些抽象的概念,不如讨论如何能够让现实的计划拥有具体的目标,如“在主视图中加载 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

架构