[轉]優化Flash性能

時間 2019-11-08

標籤優化 flash 性能欄目 Flash 简体版

原文原文鏈接

原文：http://www.adobe.com/devnet/flash/articles/optimizing-flash-performance.htmlhtml

翻譯：http://bbs.9ria.com/thread-156860-1-1.html算法

在這篇文章中，你會學到優化Flash Professional應用性能的策略。優化過程包括編輯你的FLA工程文檔確保發佈的應用程序幀頻能夠知足動畫的播放流暢。數組

若是你曾運行過一個Flash工程，見過播放老是停頓的動畫，固然這種狀況你很是不想看到。若是你想來作測驗重現這種停頓的動畫，能夠建立一個有簡單動畫的工程，而後設置幀頻爲小於10的任意數字（例如5）。而後發佈，能夠看到這個動畫有多麼停頓了。瀏覽器

有兩個主要因素能夠決定Flash的性能：CPU或GPU[解釋：圖形處理器(Graphics Processing Unit) ]的使用和內存的使用。這些因素不是互相獨立的。一些優化方法也許在這個方面能夠提高性能，可是會對另外一個方面有反作用。在下面的單元裏，我會解釋他們的工做原理，提供一些讓你能夠明確的作決定的緣由，好比，爲了下降CPU或GPU的加載而增長內存的使用。緩存

若是你是爲移動設備開發Flash遊戲的，極可能你須要一些下面將要討論的技術手段來達到可接受的幀頻。若是你是開發桌面應用的（非遊戲），極可能用很小的幀頻就能夠達到可接受的效果，或者不熟悉這篇文章裏描述的技術也能夠。併發

判斷和衡量遊戲性能框架

在理想的世界裏，Flash的測試環境容許你模仿目標平臺，而後根據目標平臺的狀況判斷你的應用運行狀況。不幸的是，除非你的開發平臺和目標平臺類似，不然如今還不能評估出在測試環境中你的項目的運行狀況。函數

除非，你在開發環境中衡量你的應用性能，而後按期讓它在目標平臺中運行一下，確認它在目標平臺也運行良好。工具

如何你在目標平臺測試項目並發現問題，你能夠用MT類來調試你的應用來解決問題。（在提供的例子文件文件夾內，打開位於這個目錄的AS類：MT/com/kglad/MT.as。）oop

內存追蹤，內存使用，和性能測試

MT代碼改編自Damian Connolly，能夠訪問他的網站。這個MT類會打印出幀頻、內存消耗，列出內存中存在的對象。爲了更好使用MT類，遵循如下步驟：

1.導入MT類：

import com.kglad.MT;

2.在文檔類裏初始化它，或在項目的主時間軸上這樣寫：

MT.init(this,reportFrequency);

上面這行代碼，「this」表示引用影片的主時間軸，「reportFrequency」表示一個有符號整數（這個數字是本身填的）。主時間軸的引用是用來計算和實現幀頻的，reportFrequency是頻率（以秒計算），它會跟蹤一個Flash應用的幀頻輸出報告和內存數量的消耗。若是你不想定時輸出幀頻和內存報告數據，傳0（或比0更小的數字）。即便你選擇不輸出幀頻，你仍然運行了這個類的內存跟蹤。

3.爲了跟蹤應用裏你建立的對象，加上這句話：

MT.track(whatever_object,any_detail);

上面這行代碼的第一個參數是你想跟蹤的對象（看看它是否從內存中移除了），第二個參數是可選的字符串，它包含任何你想測試的東西。（有些開發人員會用這個參數獲得特定對象是什麼，在哪和或者存在的時間等細節。）

4.爲了建立報告，顯示你跟蹤的對象是否還在內存裏，加上這句話：

MT.report();

你不必瞭解MT的代碼，只管用就好了。可是，瞭解一些Dictionary類是如何存儲全部傳給MT.track()的弱引用也是好的。這個類裏包括如何使用它的註釋。

在這篇文章的開頭提供了許多使用MT類的示例文件測試。爲了更多的學習MT類，查看這些測試例子看看MT類是怎麼用的。

就像物理裏的觀察者效應，咱們觀察幀頻和（或者）內存，和（或者）跟蹤內存，改變應用的幀頻和內存使用狀況。可是，若是觀察輸出結果比較少極可能觀察的效果也會下降。此外，沒有絕對的觀察數字。每過一段時間調試和優化，改變幀頻和/內存使用的狀況纔是最重要的。MT類很好的作到了承擔追蹤這些變化的責任。

爲了下降由於頻繁調用trace方法，而出現虛假的低幀頻狀況，MT類不容許每秒輸出結果。（trace方法自己會下降幀頻。）要十分注意這點，若是能夠的話，你能夠用textfield代替trace方法，來儘量的消除調用trace方法給幀頻帶來的混淆影響。

在範例文件測試工程裏，MT類是惟一的工具來檢查內存使用和精確的內存問題。你也能夠直接檢查CPU或GPU的使用狀況（查看執行應用程序時幀頻的實際使用狀況【就是看資源管理器】）。

實現優化算法

在這個單元，我會開始作一些內存管理的指導，下面單元標題的順序是按照首字母排序的。而後爲了這個目的，我會提供有關CPU/GPU管理信息的子標題來探討。

也許咱們會以爲提供兩個單元的技術是合理的。可是，若是你通讀完這篇文章，知道了用內存管理影響CPU/GPU的方法，那麼列出的內存管理的建議，能夠和CPU/GPU單元裏列出的方法一塊兒使用，這樣效果會更好。

在爲你提供特定的最佳實現方法以前，我認爲技術問題一樣重要，知道的多了你就學的輕鬆，反之就會很累。我一樣會列第二個清單，它會按技術獲益的優先級次序從高到低排列。

記住這些清單是主觀的。它的順序是依據我的開發經驗和能力來定的，還有測試情形和測試環境。

應用的優化技術從易到難排列

1.不要使用濾鏡

2.儘量使用倒序for循環，避免使用do循環和while循環

3.明確的中止使用Timer，以便垃圾回收

4.使用弱引用時間偵聽器，當不用的時候移除

5.儘量在任什麼時候候嚴格定義變量類型

6.當不須要鼠標交互的時候明確的禁用鼠標交互

7.儘量在任什麼時候候使用回調函數來取代dispatchEvent（繼承的）類

8.不須要聲音時中止Sound類，以便垃圾回收Sound（繼承的）類和SoundChannel（繼承的）類

9.儘可能讓每個所需的元素使用最基本的DisplayObject類

10.Air應用（移動設備）老是使用cacheAsBitmap 和cacheAsBitmapMatrix （前一個是位圖緩存，後一個是位圖矩陣緩存？我沒用過）

11.儘量在任什麼時候候從新使用Object

12.Event.ENTER_FRAME循環：使用不一樣的偵聽器和不一樣的偵聽函數應用在儘量少的DisplayObjects 上

13.用PoolObject（對象池）取代建立和垃圾回收Object

14.使用局部位圖傳輸（塊傳輸）

15.使用階段的塊傳輸

16.使用Stage3D

優化技術後好處由大到小排列

1.使用階段的塊傳輸（若是有足夠的系統內存）

2.使用Stage3D

3.使用局部位圖傳輸（塊傳輸)

4.在移動設備上使用cacheAsBitmap 和cacheAsBitmapMatrix

5.當鼠標交互不須要的時候明確的禁用鼠標交互

6.不要使用濾鏡

7.須要的時候使用最基本的DisplayObject類

8.儘可能在任什麼時候候從新利用對象

9.Event.ENTER_FRAME循環：使用不一樣的偵聽器和偵聽函數，他們最好應用在儘量少的DisplayObjects 上

10.儘量使用倒序for循環，避免使用do循環和while循環

11.用PoolObject（對象池）取代建立和垃圾回收Object

12.儘量在任什麼時候候嚴格定義變量類型

13.使用弱引用時間偵聽器，當不用的時候移除

14.儘量在任什麼時候候使用回調函數來取代dispatchEvent（繼承的）類

15.明確的中止使用Timer，以便垃圾回收

16.不須要聲音時中止Sound類，以便垃圾回收Sound（繼承的）類和SoundChannel（繼承的）類

記住這些優先級排序，而後前進到下個單元，學習如何更新你的Flash工程來更有效率的管理內存。

管理內存

下面列的建議不夠詳盡，但它包括了那些能夠大幅度提高Flash性能的策略內容。

使用回調函數 VS dispatEvent

當派發事件的時候會增長內存的使用，由於每一個事件必須被建立而且分配內存給它。這種行爲是這樣解釋的：事件也是對象，所以也須要內存。

我試着發送少許事件，發現每一個消耗40到128字節。我也發現使用回調函數會使用更少的內存，比使用事件效率更高。（查看在實例文檔裏的測試文件callback_v_dispatchEvent。）

應用濾鏡

當你大量應用濾鏡時也很消耗內存。根據Adobe幫助文檔，使用一個濾鏡會消耗雙倍內存。在真實Flash Professional CS6的測試環境中，我曾發現使用濾鏡的確會增長內存消耗，可是這種消耗不接近雙倍內存。（回顧測試範例，在filters文件夾下）

爲每一個元素使用正確類型的現實對象

Shape,Sprite,和MovieClip對象每一個都使用不一樣的內存數量。一個Shape對象須要236字節，Sprite須要412字節，MovieClip須要448字節。

若是你在一個工程裏使用上千的顯示對象，若是不須要交互的話，你也許須要大量Shape類來拯救你的內存。或者，當不須要時間軸時使用Sprite類。

對象池

當你打開你的應用時，要建立各類你會一直使用的對象引用，對象池能夠將這些引用保存在數組裏。任什麼時候候一個對象須要時，就能夠從這個數組裏取出使用。

不管什麼時候當一個對象再也不須要時，把它再從新放回數組裏。

有種常規作法是用Vector來代替Array來存儲相同類型的對象。使用Vector也許能夠比使用Array快兩倍，可是！除非你要作成百上千次的操做，不然你不會注意到二者的差異，由於小於上千次的操做它們同樣快。（能夠看看array_v_vector 文件夾下的範例文件。）

使用對象池能夠得到性能上的好處，同時更主要的收益是讓管理內存變得簡單。若是你在內存利用方面有無限制增加的問題，用對象池能夠很好的解決，它是提升性能、下降內存使用的通用技術。

我看到當測試一個每幀包含許多要垃圾回收和再利用的SWF文件裏，使用對象池後幀頻快了10%，而內存使用則減小了10%。（能夠查看pooling_v_gc 文件夾裏的範例。）

重用對象

當你要在一個循環裏建立許多對象時，最好在循環外先建立一個對象，而後再循環裏重複利用它。固然這個方法也不是對全部工程都有效的，但在不少狀況下這個技術仍是有用的。

在描述位圖傳輸的單元包括一個重用大量對象的例子。你能夠在測試文檔裏看這是怎麼實現的。

處理聲音

有關聲音的問題在內存使用方面是很是小兒科的。當播放一段聲音時，它不可能被垃圾回收的（可使用Flash Professional CS6來測試文件）。當聲音播放完或一個SoundChannel實例執行中止聲音時，Sound類就準備垃圾回收了。（想學更多的話能夠看看名爲sound_test 文件夾下的範例。）

使用Timer

使用Timer時要格外當心。若是沒有中止Timer（有兩種狀況：1.currentCount 屬性小於它的循環次數；2.沒有調用stop()方法），Timer就不會被垃圾回收，即便你已經移除了偵聽器，而後將全部引用設爲null。一旦你移除了偵聽器，Timer的偵聽函數就不被再次調用，可是Timer卻仍然消耗內存。

Timer類僅僅使用72字節的內存，因此極可能在一個基於桌面/瀏覽器的Flash遊戲裏成爲一個很不起眼的問題。可是，當你在移動設備裏反覆的打開、播放、關閉遊戲，而後不斷重複啓動遊戲，你也許就看到這個難以忽略的問題了。

看看這個代碼，打開命名爲gc_timer_test文件夾下的文件。

弱引用偵聽器 VS 強引用偵聽器

另外一種沒法預料的測試結果是，你使用MT類沒有辦法看出使用弱引用偵聽器和強引用偵聽器的差異。在Flash Professional CS6環境下個人測試裏它們都被當作弱引用偵聽器來對待。（查看strong_v_weak_listeners 文件夾下的範例。）

管理CPU/GPU使用狀況

當前，我惟一知道如何直接查看的工具就是使用操做系統自帶的。Windows裏有一個任務管理（性能選項卡）和Mac OS提供的活動監視器。這兩個工具均可以讓你看CPU的使用狀況，可是通常來講，它們對測試Flash性能不是特別有用。

結果，你直接查看CPU/GPU的使用只能經過檢查你應用的幀頻了。MT類可讓你檢查項目的幀頻，還有內存使用報告和內存跟蹤。

處理cacheAsBitmap 和cacheAsBitmapMatrix

使用DisplayObject的cacheAsBitmap屬性能夠大幅度提升性能（和內存），只要DisplayObject不經受須要頻繁更新位圖的改動。換句話說，DisplayObject在某種程度上不改變外觀只是改變它在舞臺上的位置。若是頻繁更新位圖，性能會下降。

你能夠常常改變位圖緩存，仍然能夠看到性能上的收益，這取決於幾個因素，但不要太驚訝，最重要的因素是，你是如何常常改變位圖的。

不管如何，用MT類測試一個指定的工程，而後看看用位圖緩存和不用有什麼差異。（當決定是否對那些不須要位圖改變的顯示對象使用位圖緩存時要不加思考的就使用！）

若是你有一個顯示對象（如影片剪輯），你想使用位圖緩存屬性，加上這句：

mc.cacheAsBitmap = true;

即便你改變顯示對象的大小、傾斜、透明度和或者旋轉（但不改變影片剪輯的幀數），而後發佈到移動設備，使用位圖緩存也是能提高性能的。

尤爲是，當把一個工程發佈到移動設備時，你能夠啓用cacheAsBitmap並分配catheAsBitmapMatrix屬性，完成後可大幅提高性能，像這樣：

mc.cacheAsBitmap = true;
mc.cacheAsBitmapMatrix = new Matrix();

不要使用默認單位矩陣。之後你就會知道有幾個緣由促使你使用這個屬性而不是用默認矩陣。

Stage blitting（我不知道把它翻譯爲「階段塊傳輸」仍是「舞臺塊傳輸」）

這是一個描述數據傳輸的術語，包括了將使用的位圖最終渲染到顯示屏幕上。不是將顯示對象加到顯示列表裏，而是把像素「放在」舞臺大小的位圖裏，而後把位圖「加到」舞臺上。爲了更新動畫，位圖的像素要在一個循環裏更新。尤爲是在Event.ENTER_FRAME循環裏，使用BitmapData類裏的copyPixel（）方法，將舞臺大小的位圖裏的BitmapData屬性，在動畫的循環以外替換其餘的bitmapData對象。

這個方法比直接把對象放到顯示列表裏複雜，但它更有效率——若是你有個無法容忍的幀頻和須要高幀頻的Flash應用，這個方法會很是有用。誠然，除非你想增長幀頻，不然你絕對沒有理由使用這個方法。

我比較了一個SWF文件，它有10,000個正方形影片剪輯，執行運動和旋轉動做，還要穿過通過舞臺（能夠看blit_test/blit_test_mc.fla範例）。而後我把這個文件作了一些基本的優化（能夠看blit_test/blit_test_basic_optimizations.fla文件）和stage blitting（看blit_test/blit_test2文件）。

第一個SWF文件大概爲15fps，這是不能容忍的。可是，在應用最難的技術優化好比塊傳輸以前，幾個基本的調整就能夠輕鬆提升性能。

首先，我將循環倒序，這樣有了一點的性能提高（看下面循環的單元），而後，更重要的是，我使用一些常量取代了一些相同的但要重複計算的變量。這些調整時性能有了稍微大點的提高（約40%），讓幀頻能夠稍微讓人接受點了，約21fps。

使用stage blitting編碼一樣的顯示區域，結果幀頻變成了54fps，整整提高了350%。

可是，正如我以前說的，這個技術的過程很複雜，包括下面幾個方面：

1.初始化須要在每一個Event.ENTER_FRAME事件裏循環的，要在舞臺上顯示的位圖資源（Bitmap實例，BitmapData實例和Rectangle實例）。

2.建立一個全部要顯示更新數據的數組。（這步不是必須的。）

3.建立一個BitmapData對象的數組。若是你的動畫在一個影片剪輯的時間軸上，這是你要每幀都存儲BitmapData對象的地方（例如，使用一個sprite列表，在範例文件夾裏我爲每一個角度的矩形都建立了BitmapData實例，這個實例能夠用AS旋轉。）

4.建立Event.ENTER_FRAME事件循環。

5.更新循環裏的元素，將第3步裏建立數組裏相應的像素，複製到在第1步裏建立BitmapData實例對應的地方（第2步決定使用data數組）。

想看更多細節，請看blit_test/blit_test2，它還包括額外的註釋。

Stage blitting技術的負面，不是複雜的編碼，而是也許在建立須要的位圖是消耗大量的內存。當爲相似iPad之類有很高分辨率（第1、二代1024*768，第三代2048*1536），相對低的內存（RAM）和容量（1、2、三代分別爲256MB，512MB和1GB）的設備寫應用時，這是個要嚴肅考慮的問題。

通常來講，你的遊戲應消耗很少於一半的可用RAM。這指的是，不只包括位圖而是你遊戲裏的一切消耗。

Partial blitting

正如字面含義，局部複製結合了Flash顯示列表和把像素複製到BitmapData對象兩種方式。特別是，在舞臺的每個顯示對象是位圖時，把他們加入顯示列表，而後像通常的顯示對象好比影片剪輯那樣操控就好了。把每一個對象的動畫複製到一個BitmapData對象的數組裏。

例如，使用以前有正方形運動選擇穿過舞臺的文件例子，我把正方形和它們各類旋轉，將這些BitmapData對象存放在一個數組裏，放在bitmap里加入顯示列表，而後在Event.ENTER_FRAME循環裏操控這些bitmap就像操控任何顯示對象那樣（好比以前描述的影片剪輯）。最後，我將bitmap的bitmapData屬性分配給對應的數組元素。（看看這是如何實現的，能夠複習blit_test/partial_blitting_test.fla文件。）

在個人電腦上，Partial blitting測試（24-26fps）不會像stage blitting同樣快。可是這個方法爲你啓發了思路，由於也許在其餘方面partial blitting比stage blitting快。另外，partial blitting比stage blitting好編碼。因此呢，若是你用partial blitting技術能夠獲得效果好的幀頻，那麼它還能夠減小在stage blitting裏必需要作的額外工做。（就是若是能用局部複製就能夠不用stage blitting了。）

有關Event.ENTER_FRAME 循環

在一個實例上，建立多個Event.ENTER_FRAME偵聽器，回調多個函數，要比一個實例上建立一個偵聽器回調一個函數，這個函數再調用其餘函數，要稍微快那麼一點點。（好繞口啊~~~~~~）

可是，這有個不一樣的狀況：在多個對象上分別偵聽Event.ENTER_FRAME，和一個對象上偵聽一個相比較，使用一個對象偵聽一個是多個對象擁有各自偵聽器性能的大約兩倍。（能夠看enterframe_test_one_v_many_loops_with_different_movieclips 文件夾下的例子。）

理解For循環，while循環和do循環

在Flash裏，for的倒序循環是最快執行的循環。若是在循環裏須要存儲的都是相同類型的對象，一個保存全部對象引用的，使用Vector的倒序for循環是最快的。

若是你使用int而不是uint來迭代元素，那這三個循環都執行的都挺快。若是你遞減循環變量而不是增長，那麼三個循環也會同樣快。（注意：若是你遞減的循環變量i使用的停止條件是i>=0，而且i是uint的話，你可能會觸發一個沒有結束的循環。）

若是你使用的是變量或常量做爲循環結束的標誌而不是表達式或對象屬性，那麼三個循環同樣快。由於初始條件僅須要評估一次（而不是每次循環迭代都要判斷），在任何循環裏循環裏，使用判斷式或對象屬性做爲初始條件都沒有大的差異。

任何不會影響循環的內容都應該放到循環的外面。這包括在循環外定義對象（看重用對象的單元），有時在循環裏使用新的構造函數能夠放在循環外面，若是結束條件是個表達式，應該在循環外算出來。

我曾看過這種說法，對每個有個下個對象引用的對象循環（相似鏈表），要比一個數組存儲全部對象引用的循環快。在個人測試結果顯示，這是不對的。

使用數組比先初始化再使用要快和容易。使用Vector而不是數組，固然要更快了。（見for_loop_v_sequential_loop 文件夾下的例子。）

全部的這些建議可能在不少狀況下沒什麼很大差異。可是，若是你的代碼要利用一切能夠利用的資源，或者你的工程裏有數量驚人的迭代，這些細節值得你參考。

禁用鼠標交互

影片剪輯和sprite能夠和鼠標交互。即便你沒有爲鼠標交互編任何代碼，當這些對象存在時Flash Player會檢查鼠標交互。因此你能夠禁用一些不須要的交互拯救一點CPU資源。

當你注意到性能問題，鼠標滑過舞臺時（或者你的電腦風扇加快轉速），這個策略很是有用。禁用鼠標交互能夠提高性能還可讓你的電腦風扇安靜點。

在測試時，我看到當禁用全部影片剪輯的鼠標事件後，幀頻增長了2 1/2倍，這個測試代碼在mouse_interactivity 文件夾下。

移除事件偵聽器

即便最新版本的Flash Player出現了兩個功能：當對象被垃圾回收後移除偵聽器，和強引用偵聽器再也不延遲垃圾回收。你仍然要儘量明確地移除全部的事件偵聽器。偵聽器越是迅速的移除掉，被佔用的CPU資源越少。另外，你可能不知道你裝了哪一個版本的Flash Player，老版本是沒有垃圾回收對象的——即那些對象是弱引用偵聽器。不要依賴最新的Flash Player功能，而要踏實優化本身的糟糕代碼。

有關Stage3D

Stage3D是基於GPU的顯示渲染模型，它是Flash Player11版本發佈的。這個模型對3D渲染特別有用，可是使用例如Starling的框架也能服務於2D顯示。

由於本來CPU承擔了所有的渲染顯示工做，（當運行一個程序時CPU也要作其餘工做），而如今GPU承擔了一部分渲染工做，就可讓CPU有更多的空閒作其餘工做。這樣的利用極大的提升了設備性能。

想看Stage3D內容，你必須使用Flash Player11或更高版本。想看Stage3D的API，你須要用Flash Player11或更高版本發佈SWF文件。若是你使用Flash Professional CS6工做，那它已經所有設置好了。若是你用的是Flash Professional CS5或CS5.5，你能夠更新Flash安裝文件使之能夠發佈Flash Player11。更多的細節，能夠看Rich Galvan寫的名爲Adding Flash Player 11 support to Flash Professional CS5 and CS5.5博客。

很不幸，使用Stage 3D的API很是困難。可是，有幾個免費開源的框架能夠生成使用Stage 3D所需的最基本的代碼。

其中之一就是Starling，被用來開發2D遊戲。它簡單易學而且高效簡化了Stage3D的複雜性。Starling 的API能夠在Starling框架參考網站裏尋找。

我測試了Starling來看它和blitting、partial blitting相比較如何。在某些狀況下，Starling表現的比這兩種blitting要很差。事實上，他表現的比沒有優化的10,000個正方形影片剪輯的測試還要糟糕。

可是，在Starling測試裏，若是你不選擇容許編譯選項，那麼這小小的改變可使幀頻快兩倍，輸出的SWF文件能夠比得上沒有優化的10,000個正方形測試。可是這個結果依然讓人失望，部分的問題在於，我使用編譯版本的Flash Player來測試時，在編譯和不編譯兩種狀況下，Starling在編譯狀況下表現的很差。

另外，10,000個正方形影片剪輯測試不能顯示出Starling最好的一面。若是你使用許多包含各自時間軸動畫的影片剪輯，Starling會比幾乎任何你使用的簡單優化技術要出色。

僅僅blitting優化的性能就要優於使用Stage3D和Starling所帶來的收益。可是blitting也許不是那麼實用，由於內存須要建立所需的位圖。

範例文件在starling_test 文件夾下。

使用Starling框架時，要遵循如下步驟：

1.下載Starling.swc文件。

2.使用如下步驟將它導入你的Flash工程連接庫：

1）選擇，文件>發佈設置>腳本設置。

2）點擊庫路徑選項卡，而後點擊瀏覽，選擇你下載好的swc文件的位置路徑。

3）在「打開文件」對話框，選擇你放swc文件的路徑。

4）點擊「打開」，添加starling.swc到你的連接庫路徑。

５）點擊OK關閉高級ActionScript 3.0設置面板，而後再次點擊ＯＫ關閉發佈設置。

６）保存Fla文件，你就可使用Starling了。