應用性能：規劃成本遠小于重構

　　開發人員常說，他們的目標之一是使應用程序“快”。然而，當他們發布應用時，客戶還是抱怨速度太慢并且反應遲鈍。根據微軟內部的研究結果，這種問題最常見的根源是缺乏對性能的規劃。讓應用程序運行得“快”，是個不切實際的目標，因為它無法測量。因此，當應用性能開始下滑時，開發人員往往注意不到。如果性能測試是在特定的硬件或環境條件下進行的，那么會更糟。

　　快速、流暢、高效能是性能的支柱。但與其看著這些抽象的概念，不如討論如何能夠讓現實的計劃擁有具體的目標，如“在主視圖中加載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

原文轉自：http://www.infoq.com/cn/news/2013/07/Performance-Terminology