性能相關(guān)問題往往表明作者無法理解問題鏈中最薄弱的環(huán)節(jié)。以下是我最喜歡提到的一些有關(guān)性能和 AIR 應(yīng)用程序的糟糕提問：

• 我的 AIR 應(yīng)用程序會運行如飛嗎？
• AIR 是否可以達到執(zhí)行 X 的速度？
• AIR 執(zhí)行 Y 是否太慢？

（以下內(nèi)容還證明了一點，無論幼稚園老師教了您什么，總會出現(xiàn)糟糕提問這類事物。）

AIR 幾乎總可以通過應(yīng)用程序?qū)崿F(xiàn)良好性能。而另一方面，AIR 無法為您這樣做。正如我所說的，這是問題的本性。

幸運的是，標準調(diào)試技術(shù)像適用于編寫桌面軟件一樣適用于 AIR。

合適的提問

實現(xiàn)良好性能的***步，就如同大多數(shù)設(shè)計問題，在于理解您嘗試解決的問題。以下是一些針對您的應(yīng)用程序的合適的提問：

• 我的應(yīng)用程序中哪些操作對于性能比較敏感？
• 我可以使用什么衡量標準來測量這一敏感度？
• 如何優(yōu)化應(yīng)用程序以達到這一衡量標準？

大多數(shù)應(yīng)用程序包含大量可以穩(wěn)定運行的代碼。不要在這方面浪費時間，尤其是當益處低于用戶可以察覺的閾值時。務(wù)必將注意力集中在重要方面。

值得優(yōu)化的常見操作示例包括：

• 圖像、聲音和視頻處理
• 渲染大型數(shù)據(jù)集或 3D 模型
• 搜索
• 響應(yīng)用戶輸入

定義衡量標準

人們往往將性能和速度劃上等號，但千萬不要誤以為這是唯一重要的衡量標準。您可能發(fā)現(xiàn)需要針對內(nèi)存使用或電池壽命進行調(diào)試。將這些降至***的應(yīng)用程序也可以被認為比那些不降低的應(yīng)用程序性能更高。有時優(yōu)化其他衡量標準也可以提高速度，但其他時候需要做出折衷。

無論測量什么，您必須測量一些對象。如果不測量任何對象，您就無法得知更改是有利于還是有害于性能。良好的衡量標準有以下三個特性：

• 它們可以量化。可以測量它們并記錄為數(shù)字。
• 它們是一致的。您可以反復(fù)測量它們，并有效地比較測量結(jié)果。
• 它們有意義。測量值中的變化對應(yīng)于您正在優(yōu)化的對象。

為了使它更形象，假設(shè)您正在編寫一個應(yīng)用程序，它將對一個大型圖像集執(zhí)行一些圖像處理任務(wù)。在處理過程中，應(yīng)用程序需要向用戶顯示進度反饋。它還必須允許用戶能取消操作，而不是等待操作完成。這是一個十分簡單的應(yīng)用程序，但即便如此，它至少仍有三個重要的衡量標準可供審視。

示例：吞吐量

***個、最顯而易見的衡量標準是吞吐量。它在這個示例中是有意義的，因為我們知道自己必須處理大量圖像。吞吐量越高，處理完成得越快。

吞吐量可以輕松量化為每單位時間的處理量。盡管可以測量已處理圖像的數(shù)量，但當圖像大小不一時，測量字節(jié)數(shù)可以產(chǎn)生一致性更高的值。在這個示例中，直接測量每毫秒字節(jié)數(shù)作為吞吐量。

示例：內(nèi)存使用

對于這個應(yīng)用程序，一個不太顯眼的衡量標準是內(nèi)存使用。對于最終用戶，內(nèi)存使用不像吞吐量那樣顯而易見。為了監(jiān)視內(nèi)存使用，用戶必須運行另一個應(yīng)用程序，如 Activity Monitor。但內(nèi)存使用可能成為一個限制因素：內(nèi)存不足，此時應(yīng)用程序?qū)o法正常運行。

內(nèi)存使用對于我們的圖像處理示例是重要的，因為這些圖像本身很大。我們希望能處理大型圖像－即便是那些超出可用 RAM 的圖像－前提是不出現(xiàn)內(nèi)存不足的情況。內(nèi)存使用按字節(jié)測量很簡單。

示例：響應(yīng)時間

我們的范例應(yīng)用程序的***一個衡量標準往往被忽略：用戶輸入的響應(yīng)時間。這個衡量標準對于您的所有用戶而言都是顯而易見的，雖然他們很少停下來測量它。它也十分普遍。用戶希望所有操作都能得到快速響應(yīng)－無論是調(diào)整窗口大小、取消某個操作還是鍵入文本。

用戶認為某些衡量標準是線性的，而響應(yīng)時間卻有一個重要的閾值。輸入響應(yīng)只要超過 100 毫秒左右，用戶就會有慢的感覺。如果您的應(yīng)用程序響應(yīng)速度始終低于這個閾值，就沒有進一步優(yōu)化的必要了。顯然，這個衡量標準可以按毫秒輕松量化。

響應(yīng)時間對于圖像處理應(yīng)用程序是一個重要挑戰(zhàn)，因為處理任何一張圖像的時間都遠遠超出 100 毫秒。在某些編程環(huán)境中，通過在連續(xù)計算線程以外的線程上處理用戶輸入來解決這個問題。而在內(nèi)部，這種解決方法需要操作系統(tǒng)快速切換線程環(huán)境，確保用戶輸入線程可以及時響應(yīng)。但 AIR 不提供明確的線程模型，所以必須直接完成這一切換操作。下一部分將說明這一操作。以下范例說明了設(shè)置圖像處理的三種不同方式，它們針對不同的衡量標準而優(yōu)化：

<?xml version="1.0" encoding="utf-8"?> 
            <mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="horizontal" frameRate='45'> 
  <mx:Script> 
  <![CDATA[ 
            private static const DATASET_SIZE_MB:int = 100; 
   
            private function doThroughput():void { 
            var start:Number = new Date().time; 
            var data:ByteArray = new ByteArray(); 
            data.length = DATASET_SIZE_MB * 1024 * 1024; 
            filter( data ); 
            var end:Number = new Date().time; 
            _throughputLabel.text = ( data.length / ( end - start )) + " bytes/msec"; 
            } 
   
            private function doMemory():void { 
            var start:Number = new Date().time; 
            var data:ByteArray = new ByteArray(); 
            data.length = 1024 * 1024; 
            for( var chunk:int = 0; chunk < DATASET_SIZE_MB; chunk++ ) { 
            filter( data ); 
            } 
            var end:Number = new Date().time; 
            _memoryLabel.text = ( DATASET_SIZE_MB * data.length / ( end - start )) + " bytes/msec"; 
            } 
   
            private function doResponse():void { 
            _chunkStart = new Date().time; 
            _chunkData = new ByteArray(); 
            _chunkData.length = 100 * 1024; 
            _chunksRemaining = DATASET_SIZE_MB * 1024 / 100;  
            _chunkTimer = new Timer( 1, 1 ); 
            _chunkTimer.addEventListener( TimerEvent.TIMER_COMPLETE, doChunk ); 
            _chunkTimer.start(); 
            } 
   
            private function doChunk( event:TimerEvent ):void { 
            var iterStart:Number = new Date().time; 
            while( _chunksRemaining > 0 ) { 
            filter( _chunkData ); 
            _chunksRemaining--; 
 
            var now:Number = new Date().time; 
            if( now - iterStart > 90 ) break; 
            } 
   
            if( _chunksRemaining > 0 ) { 
            _chunkTimer.start(); 
            } else { 
            var end:Number = new Date().time; 
            _responseLabel.text = ( DATASET_SIZE_MB * 1024 * 1024 / ( end - _chunkStart )) + " bytes/msec";  
            } 
            } 
   
            private var _chunkStart:Number; 
            private var _chunkData:ByteArray; 
            private var _chunksRemaining:int; 
            private var _chunkTimer:Timer; 
   
            private function filter( data:ByteArray ):void { 
            for( var i:int = 0; i < data.length; i++ ) { 
            data[i] = data[i] * data[i] + 2; 
            } 
            } 
            private function onMouseMove( event:MouseEvent ):void { 
            var global:Point = new Point( event.stageX, event.stageY ); 
            var local:Point = _canvas.globalToLocal( global ); 
            _button.x = local.x; 
            _button.y = local.y; 
            } 
   
            ]]> 
  </mx:Script> 
   
  <mx:HBox width='100%' height='100%'> 
  <mx:VBox width='50%' height='100%'> 
  <mx:Button label='Measure throughput' click='doThroughput();' /> 
  <mx:Label  id='_throughputLabel' /> 
  <mx:Button label='Reduce memory use' click='doMemory();' /> 
  <mx:Label  id='_memoryLabel' /> 
  <mx:Button label='Maintain responsiveness' click='doResponse();' /> 
  <mx:Label  id='_responseLabel' /> 
  </mx:VBox> 
  <mx:Canvas  
            width='50%' height='100%' 
            id="_canvas"  
            horizontalScrollPolicy="off" 
            verticalScrollPolicy="off" 
            backgroundColor="white" 
            mouseMove='onMouseMove( event );' 
  > 
  <mx:Label text="Move Me" id="_button" /> 
  </mx:Canvas> 
  </mx:HBox> 
  </mx:WindowedApplication> 

進行測量

當確定并定義衡量標準后，您首先必須能測量它們，隨后才能處理它們。只有通過前后兩次的測量和跟蹤，您才能確定那些變化的影響。盡可能同時跟蹤所有衡量標準，這樣可以了解為優(yōu)化一個衡量標準所做的更改對其他衡量標準產(chǎn)生的影響。

測量吞吐量

可以通過程序輕松測量吞吐量。測量吞吐量的基本模式為：

start_msec = new Date().time 
do_work() 
end_msec = new Date().time 
rate = bytes_processed / ( end_msec - start_msec )  

測量內(nèi)存

內(nèi)存更復(fù)雜一些。包括 AIR 在內(nèi)的大多數(shù)運行時環(huán)境不提供可以確定應(yīng)用程序內(nèi)存使用的適當 API。***使用外部工具監(jiān)視內(nèi)存使用，如 Activity Monitor (Mac OS X)、任務(wù)管理器 (Windows)、BigTop (Mac OS X) 等。選擇一個監(jiān)視工具后，您需要決定要跟蹤哪個內(nèi)存衡量標準。

虛擬內(nèi)存是跟蹤工具的頭號報告對象。 人如其名，它不會測量進程使用的物理 RAM 量。可以將它想象為進程使用的內(nèi)存地址空間量。在某個時刻，分配給進程的一部分內(nèi)存通常會存儲在磁盤而不是 RAM 中。人們通常認為 RAM 量以及占用的磁盤空間之和就是進程的虛擬內(nèi)存，但地址空間的某些部分可能不在這兩個地方。具體情況取決于操作系統(tǒng)以及它根據(jù)不同目的分配虛擬內(nèi)存部分的方式。

根據(jù)虛擬內(nèi)存包含的內(nèi)容，應(yīng)用程序虛擬內(nèi)存的絕對大小可能不是一個重要的衡量標準。您的應(yīng)用程序相對于其他類似應(yīng)用程序的虛擬內(nèi)存可能是重要的，但依然很難進行有效比較。虛擬內(nèi)存最重要的一個方面是它隨著時間流逝產(chǎn)生的行為：無限增長表明存在內(nèi)存泄漏。其他內(nèi)存衡量標準中可能不顯示內(nèi)存泄漏，因為如果未引用泄漏的內(nèi)存，它們會調(diào)入磁盤并駐留在那里。

可供監(jiān)視的***內(nèi)存衡量標準是專用字節(jié)，它測量進程單獨使用的 RAM 量。這個衡量標準直接表明您的應(yīng)用程序?qū)φ麄€系統(tǒng)產(chǎn)生的影響，它使用的是共享資源。

專用字節(jié)會隨著應(yīng)用程序分配和取消分配內(nèi)存而波動。它也會隨著應(yīng)用程序活動或空閑而波動，空閑時部分頁面會調(diào)入磁盤。要跟蹤專用字節(jié)，我建議在您優(yōu)化的操作過程中使用監(jiān)視工具進行定期采樣，即每秒一次。

監(jiān)視工具包含的其他內(nèi)存衡量標準包括駐留大小和共享字節(jié)。駐留大小是您的進程所使用的 RAM 總量，它由專用字節(jié)和共享字節(jié)組成。共享字節(jié)是與其他進程共享的 RAM 部分。這些部分通常包含只讀資源，如共享庫或系統(tǒng)框架中的代碼。雖然您可以跟蹤這些衡量指標，應(yīng)用程序目前對專用字節(jié)值的控制度***，問題也最多。

響應(yīng)時間

響應(yīng)時間***用秒表測量。當用戶執(zhí)行操作時開始計時，如單擊按鈕時。當應(yīng)用程序響應(yīng)時停止計時，通常更改顯示的用戶界面即可。將兩個計時相減就可以得出測量值。

優(yōu)化流程

有了目標和衡量標準，就可以進行優(yōu)化了。流程本身很簡單，并且應(yīng)當很常見。重復(fù)以下三個步驟，直至完成：

1. 測量
2. 分析
3. 修改

大致而言，分析可能產(chǎn)生兩種更改中的一種：設(shè)計或代碼。

設(shè)計更改

設(shè)計更改通常影響***。但是，在游戲后期進行設(shè)計更改難度可能更大，所以定義并測量性能目標之前不要耽擱太久。

例如，我們回到圖像處理應(yīng)用程序。一種單純的實施方法是：將每個圖像完整加載到內(nèi)存中，處理它，然后將結(jié)果寫回磁盤。這個應(yīng)用程序的內(nèi)存使用峰值（專用字節(jié)）主要就是已加載圖像大小的函數(shù)。如果圖像超出可用 RAM，應(yīng)用程序?qū)⑹　?/p>

圖像處理操作很少是全局的；大多數(shù)操作每次可以在圖像的某個部分上執(zhí)行。通過將圖像分為固定大小的多個塊并且逐個處理這些塊，您可以將應(yīng)用程序的內(nèi)存使用峰值限制為選定的數(shù)值。這樣，處理超出可用 RAM 的圖像也成為可能。

修改設(shè)計后，請務(wù)必重新評估所有衡量標準。它們之間始終會出現(xiàn)一些相互作用，因為設(shè)計發(fā)生了變化。那些更改有時可能會出乎想象。當我構(gòu)建這個范例應(yīng)用程序的原型時，按固定大小的塊處理圖像并未大幅改變應(yīng)用程序的吞吐量，我預(yù)計它可能變慢。

代碼更改

當不再需要增強設(shè)計時，可轉(zhuǎn)向代碼調(diào)試。這個方面可以嘗試許多技術(shù)。其中有些是 ActionScript 特有的；有些則不然。

切記不要過早應(yīng)用代碼更改。它們可能會犧牲可讀性和性能結(jié)構(gòu)。雖然不一定每次都會很糟，但是如果過早應(yīng)用代碼更改，它們會降低您改進和維護應(yīng)用程序的能力。正如 Donald Knuth 所說，“過早的優(yōu)化是一切罪惡的源頭。”

特制的測試應(yīng)用程序

真實的應(yīng)用程序往往較大、較復(fù)雜并且滿是快速運行的代碼。為了幫助您既愛那個優(yōu)化精力集中在主要操作上，可考慮創(chuàng)建一個專用測試應(yīng)用程序。

除了其他優(yōu)勢，測試應(yīng)用程序提供了一個包含測試的空間（即，用于測量吞吐量），您無需將這個代碼包含在最終的應(yīng)用程序中。

當然，將您的改進移回應(yīng)用程序時，您需要驗證優(yōu)化結(jié)果是否依然有效。

分塊

如前所述，AIR 運行時不提供在后臺線程上執(zhí)行應(yīng)用程序代碼的機制。在計算密集型任務(wù)過程中嘗試保持響應(yīng)度時，這個問題尤為棘手。

與空間分塊可用于優(yōu)化內(nèi)存使用一樣，時間分塊可以將計算分為多個短時運行部分。通過響應(yīng)各部分之間的用戶輸入，您可以保持應(yīng)用程序的響應(yīng)度。

以下偽代碼每次可以執(zhí)行約 90 毫秒的工作，然后把控制權(quán)交給主事件循環(huán)。主事件循環(huán)確保已處理鼠標單擊等操作。根據(jù)這一時間安排，可以在 100 毫秒內(nèi)處理大多數(shù)用戶輸入，從用戶角度而言，應(yīng)用程序的響應(yīng)速度已足夠。

var timer:Timer = new Timer( 1, 1 ) 
  timer.addEventListener( TimerEvent.TIMER, doChunk )  
  function doChunk( event:Event ):void { 
    var start:Number = new Date().time 
    while( workRemaining ) { 
      doWork() 
        var now:Number = new Date().time 
        if( now - start > 90 ) { 
          // reschedule more work to occur after input 
        if( workRemaining )  
           timer.start() 
        break 
      }  
    } 
  }  

在此例中，為了保持響應(yīng)度，doWork() 的運行時間必須遠遠小于塊持續(xù)時間。為了保持在 100 毫秒的最糟情況下，運行時間不能超出 10 毫秒。

再次強調(diào)，采用這類方法后，請重新測量所有衡量標準。在我的圖像處理應(yīng)用程序中，采用這種分塊方法后吞吐量下降了約 10%。另一方面，我的應(yīng)用程序在所有用戶輸入的 100 毫秒內(nèi)可以做出響應(yīng)，而不僅僅是在圖像之間。我認為這是一個合理的折衷。

包裝

創(chuàng)建高性能的應(yīng)用程序并非易事，但要回應(yīng)嚴格的測量、分析和不斷改進會遇到問題。AIR 應(yīng)用程序在這個問題上沒有很大區(qū)別。

性能同時也是一個不斷變化的目標。不僅每一組改進可能影響到其他衡量標準，底層硬件、操作系統(tǒng)和其他更改也會改變快與慢之間的平衡。即便是您在優(yōu)化的對象也可能隨時間發(fā)生變化。

憑借充分的實戰(zhàn)經(jīng)驗，您可以創(chuàng)建出高性能的 AIR 應(yīng)用程序并使它們持之以恒。切記不要放松警惕。只要有一個功能變慢，用戶就會發(fā)問，“您的應(yīng)用程序是否可以達到執(zhí)行 X 的速度？”

關(guān)于作者