http://uh.9ria.com/space.php?uid=81273&do=blog&id=11216
如安在flash開發中提高性能，總是1個討論很強烈熱鬧的不懂的題目。記得每次參加flash技術交流會，性能相關的提問是至關多的。
六合會翻譯了1個預示列表與性能相關的帖子，我就想起來理事一下在flash中提高性能的方法。 垃圾收受接管的一些知識總結：
1、被刪除對象在外部的所有引用一定要被刪除乾淨才能被體系當成垃圾收受接管處理掉。
2、父對象內部的子對象被外部其它對象引用了，會導致此子對象不會被刪除，子對象不會被刪除又會導致了父對象不會被刪除。
3、如果1個對象中引用了外部對象，當本身被刪除或者不需要使用此引用對象時，一定要記得把此對象的引用設置爲null。
四、本對象刪除不了的原因不一定是本身被引用了，也可能是本身的孩子被外部引用了，孩子刪不掉導致父親也刪不掉。
5、除了引用需要刪除外，體系組件或者全局工具、管理類如果提供了卸載方法的就一定要調用刪除內部對象，否則可能會造成內存泄露和性能喪失。
6、父對象立刻被刪除了不代表子對象就會被刪除或立刻被刪除，可能會在後期被體系自動刪除或第二次移除操作時被刪除。
七、如果父對象remove了子對象後沒有清除對子對象的引用，子對象一樣是不能被刪除的，父對象也不能被刪除。
八、註冊的事件如果沒有被移除不影響自界說的強行收受接管機制，但可能會影響沒事了的收受接管機制，所以最好是做到註冊的事件***都要記得移除乾淨。
9、父對象被刪除了不代表其餘子對象都刪除了，找到一種狀態的泄露代碼不等於其它狀態就沒有泄露了，要各板塊各狀態逐個舉行測試分析，直到測試任何狀態下都能刪除整個對象爲止。
10、當觸發了某個event後，不再使用的話，請將其remove掉。
11、能不使用Effect就不要使用Effect。
內存泄露舉例：
1、引用泄露：對子對象的引用，外部對本對象或子對象的引用都需要置null。
2、體系類泄露：使用了體系類而健忘做刪除操作了，如BindingUtils.bindSetter()，ChangeWatcher.watch() 函數時辰完結後需要調用ChangeWatcher.unwatch()函數來清除引用 ，否則使用此函數的對象將不會被刪除； 類似的還有MUSIC，VIDEO，IMAGE，TIMER，EVENT，BINDING等。
3、效果泄露：當對組件應用效果Effect的時辰，當本對象本刪除時需要把本對象和子對象上的Effect動畫停止掉，然後把Effect的target對象置null; 如果不停止掉動畫直接把 Effect置null將不能沒事了移除對象。
四、SWF泄露：要完全刪除1個SWF要調用它的unload()方法並且把對象置null。
5、圖片泄露：當Image對象使用完結後要把source置null。
6、聲音、視頻泄露: 當不需要1個音樂或視頻是需要停止音樂，刪除對象，引用置null。
內存泄露解決方法：
1. 在組件的REMOVED_FROM_STAGE事件回掉中做垃圾處理操作（移除所有對外引用（無論是VO還是組件的都需要刪除），刪除***，調用體系類 的清除方法） 先remove再置null, 確保被remove或者removeAll後的對象在外部的引用全部釋放乾淨。
2. 利用Flex的性能優化工具Profile來對項目進程項舉行監控，可知道歷史創建過哪些對象，目前有哪些對象沒有被刪除，創建的數量，佔用的內存比例和用量，創建過程等信息。
總結：要害還是要做好清除工作，本身設置的引用本身要記得刪除，本身用過的體系類要記得做好收受接管處理工作。 以上不懂的題目解決的好的話不需要自界說強制收受接管器也可能被體系沒事了的自動收受接管掉。
衆所周知，由於Flash Player的垃圾收受接管機制是自動舉行的，是以就算是上面所說的內容的內容都符合要求，那末還是會產生內存“高居不下於”的情況。
是以，我接下來介紹1個很是規的體式格局，讓Flash Player的垃圾收受接管機制在我的控制之中。（以下的內容也不是我創始的，但是就此總結說明一下） 一優化計算方法
1.用乘法來代替除法（當除數可轉化爲有限數的時辰）。好比var n:Number = value * 0.5;要比var n:Number = value / 2;快。但差別並不是很大。只有在需要大量計算情況下，好比3D引擎中差別才比較較着。
2.用位運算代替除2或乘2。好比10>>1要比10*2快，而10<<1要比10*2快。從測試來看位運算幾乎比乘除快 一倍，但是一般情況下，我們不能選擇位運算，好比我們就不能用13>>1來代替13/2，儘管前者比後者運算速度更快，但2者的運算結果卻不 一樣。所以還是要看具體情況。
3.用unit()或int()代替取整運算Math.floor()和Math.ceil()。好比var test:uint = uint(1.5);要比var test:Number = Math.floor(1.5);快；而var test:uint = uint(1.5)+1;要比var test:Number = Math.ceil(1.5);也快。若是Math.floor()，還可以用位運算(>>0)來代替。好比var test:uint =1.5>>0，比unit()或int()更快。
4.用乘-1來代替Math.abs()方法。好比var nn:Number = -23;var test:Number= nn < 0 ? nn * -1 : nn;要比var nn:Number = -23;var test:Number = Math.abs(nn);快。
當然還有更多的優化計算的方法。一般來講，低級運算要比高級運算速度；內部方法比調用其它方法速度快。另外要注意的是，這些方法有的時辰可能並一定合用.
二 Actionscript 優化指南
什麼時候舉行優化
對現有程序舉行優化的過程，有時十分的冗長與困難，這與原始代碼的非優化程度有關，所以在投入大量時間舉行代碼優化之前，最重要的是要估計出要在啥子處所對代碼做出修改或替代。
1個遊戲代碼的最重要的部門就是主輪迴體，通常理況下該輪迴體要在flash的每一幀上執行，並控制遊戲中的角色屬性和重要的數值參數。而對主輪迴體以外的部門，也可能是非主要輪迴部門，同樣要注意是給其否分配了過多的資源，而沒有分配售那一些更需要資源的核心部門。
通過積累在遍地省電出來的時間(可能每處僅僅是幾個毫秒)，您會較着發現本身的swf運行得越發穩定，並且遊戲感也大大加強。
簡潔與高效的代碼
書寫出十分簡潔、可以再次調用的代碼(有時可能是面向對象的)是一項精緻的工作，但這需要多年的編程經驗。對OOP(object oriented programming，面向對象的程序設計)，有些場合根本利用不到它的優勢，這要得它顯得十分奢侈。在有限的資源條件下(可能是flash播放器的原因)，通過更先進的方法，像方纔提到的OOP，就可能反而導致使人不稱心的結果。
我們並不是說OOP對遊戲編程不好，只是在某些場合它顯得過於奢侈和駢枝。畢竟有時辰“傳統的方法”卻能得到更好的結果。
大體而言，用OOP是比較好的，因爲它讓代碼維護越發簡略。但在後文中，你會看見有時爲了充分闡揚flashplayer性能，而不接納OOP技術。例如：處理快速骨碌或者計算十分複雜的數學不懂的題目。
基本的優化
一提及代碼優化，我們頓特殊情況遐想到執行速度的改進，而很少去考慮體系資源的分配。這是因爲當今，即使是將被淘汰的計算機，都有足夠的內存來運行我們大部門的flash遊戲(128M的內存完全可以饜足大大都情況的需要，何況，512M的內存是當今新電腦的基本配置)
變量
在各種重要的代碼優化手段中，有這麼一條：在界說局部變量的時辰，一定要用要害字var來界說，因爲在Flash播放器中，局部變量的運行速度更快，並且在她們的作用域外是不耗佔體系資源的。
aw附：var變量僅僅在花括號對中才有“生命”，個人以爲沒有體系學過編程的人容易出錯的1個處所： 一段非優化代碼: 最近代碼中，並未聲明函數體內的那一些變量(那一些僅僅在函數內使用的變量)爲局部變量，這要得這些變量被播放器調用的速度更慢，並且在函數執行完結的時辰仍然耗佔體系資源。
底下面所開列出的是經過改進的同樣功能的代碼： 這樣一來所有的變量均被界說爲了局部變量，她們能夠更快地被播放器調用。這一點在函數大量(10，000次)輪迴運行時顯得尤爲重要！當1個函數調用竣事的時辰，相應的局部變量城市被銷燬，並且釋放出她們佔有的體系資源。
onEnterFrame 事件
onEnterFrame事件對遊戲開發者而言是很是有效的，它要得我們能夠快速、反覆地按照設計幀頻(fps)運行一段程序。回想在 Flash5的時代，這(onEnterFrame及時監控)是一種很是流行的技術，用這樣的事件來控制機器遊戲對手的思維規律，又或者我們可以在每1個子彈 上設置這樣的事件來監測子彈的碰撞。
實際上，我們並不推薦給過多的MoveClip添加這樣的事件，因爲這樣做會導致“無頭緒碼(spaghetti code)”的出現，並且容易導致程序效率較着減低。
大大都情況下，用單唯1個onEnterFrame事件就能夠解決不懂的題目了：用這1個主輪迴來執行你所需要的操作。
另1個簡略的辦法是設置1個合適的幀頻：要知道幀頻越高，CPU資源就越緊張。
在幀頻爲25-35(fps)之間時，onEnterFrame完全可以很好地執行較複雜代碼，哪怕你的計算機配置較低。是以，在沒有特殊要求的場合，我們不推薦使用高於60(fps)的幀頻。
矢量圖與位圖
在處理圖形前，我們一定要做出正確的選擇。Flash能對矢量圖和位圖舉行完美的兼容，然而矢量圖和位圖在播放器中的體現實質卻完全不同。
在用到矢量圖的時辰，我們要儘可能簡化它們的外形，去除駢枝的端點。這樣做將大大減低播放器用於出現矢量圖所要舉行的計算量。另1個重要方面在於線條的運用，儘量減少和避免冗陳的線條結構，因爲它們會直接影響到flash的播放效率。
當某個實例透明度小於100時，也會對播放速率造成影響，所以如果你發現本身的Flash播放速率過慢，就去挑出這些透明的實例來吧！
那末，如果真的需要出現比較複雜的場景時，你就最好考慮使用位圖實現。雖然Flash在對位圖的渲染效率上並不是最優越的(好比和Flash的“兄 長”Director比起來)，但富厚的視覺內容出現只能靠位圖(與位圖同複雜度的矢量圖形渲染速率很是低)了，這也是很多基於區塊的遊戲中廣泛接納像素 圖作爲配景的原因。順便要提到的是，Flash雖然對GIF,JPG和PNG都有所支持，但是渲染速度上PNG還是佔有絕對優勢，所以我們建議flash 中的位圖都儘可能接納PNG格局。
影片剪接(MovieClip)的可視性[底下將MovieClip簡稱爲mc]
您可能會時常遇到這樣一種情況：有大量不可見/熒幕外的mc等候出場(好比遊戲中熒幕外的地圖、人物等等)。
要知道，播放器仍然要耗損一定的資源來處理這些不可見/熒幕外的mc，哪怕她們是單幀，非播放的狀態。
最好的解決辦法之一是給這些mc1個空白幀，當她們不出現在熒幕上時，你能用gotoAndStop()語句跳轉到這一幀，從而減少播放器對資源的需求。
請務必記住，這種情況下，簡略的設置可見度屬性爲不可見( _visible = false )是無效的，播放器將接續按照這些mc所停留或播放的幀的複雜度來分配資源。
數組
數組在各種需要記錄數值的應用程序和遊戲中都被廣泛的使用。
1個典型的例子就是基於區塊的Flash遊戲，在這樣一類的遊戲中，地圖有時被存放成形如arr[y][x]的二維數組。雖然這是一種很常見的方 法，但是如果用一維數組的話，卻能提高程序的運行效率。另1個重要的方法來提高數組效率是在數組遍歷的時辰使用for in 輪迴來代替傳統的 for 或者whellole輪迴語法。
例如：
一段代碼如下 它的執行速度較着高於這一段代碼： 前者的效率比後者提高了30%，這個數字在你的遊戲要逐幀執行這一段代碼的時辰顯得越發寶貴！
高級優化：
1) for輪迴和 whellole輪迴
用whellole輪迴將會得到比for輪迴更好的效率。然而，從數組中讀取數值，用for in輪迴式最好的選擇！
所以我們不推薦使用： 2) 從數組中讀取數值
我們通過測試發現，for in輪迴的效率大大高於其它的輪迴體式格局。參看： 3) 向數組中寫入數值(whellole , for)
可以看見whellole輪迴稍佔優勢。
4) _global(全局)變量同Timeline(時間軸)變量
我們推測接納全局變量能提高變量調用速度，然而效果並不像估計的那樣較着。
5) 單行、多行變量賦值
我們發現單行變量賦值效率大大高於多行。好比：
a = 0
b = 0
c = 0
d = 100
e = 100
效率就不如：
a = b = c = 0
d = e = 100
6) 變量名尋址
這個測試反映了變量名的預尋址是很是重要的，尤其是在輪迴的時辰，一定要先給丁1個指向。這樣大大省電了尋址時間。
好比： 就不如： 7) 短變量名和長變量名
變量名越短，效率越高。考慮到長變量名也有它的好處（好比，易於維護等），是以建議在要害部位（好比大量輪迴出現的時辰）使用短變量名，最好就1-2個字符。
8)輪迴前、後聲明變量
在測試前，我們以爲輪迴前聲明變量會越發省電時間，不意測試結果並不較着，甚或還恰恰相反！ // 內部聲明
t = getTimer()
for (var i=0; i < MAX; i++)
{
var test1 = i
}
t1.text = “Inside:” + (getTimer() – t)
// 外部聲明
t = getTimer()
var test2
for (var i=0; i < MAX; i++)
{
test2 = i
}
9) 使用嵌套的if結構
當用到複雜的條件抒發型時。把她們打散成爲嵌套的自力判斷結構是最佳方案。底下的代碼我們舉行了測試，發現這種效果改進較着！ 10) 尋找局部變量(thellos方法同with方法比較)
局部變量的定位方法很多。我們發現用with比用thellos越發有優勢！ obj = {}
obj.a = 1
obj.b = 2
obj.c = 3
obj.d = 4
obj.e = 5
obj.f = 6
obj.g = 7
obj.h = 8
obj.test1 = useThellos
obj.test2 = useWith
MAX = 10000
function useThellos()
{
var i = MAX
whellole(–i > -1)
{
thellos.a = 1
thellos.b = 2
thellos.c = 3
thellos.d = 4
thellos.e = 5
thellos.f = 6
thellos.g = 7
thellos.h = 8
}
}
function useWith()
{
var i = MAX
whellole(–i > -1)
{
with(thellos)
{
a = 1
b = 2
c = 3
d = 4
e = 5
f = 6
g = 7
h = 8
}
}
}
11) 輪迴監聽鍵盤事件
同剛纔所提到的尋址一樣，我們實現給1個指向會得到更好的效率，好比：
keyDown = Key.isDown
keyLeft = Key.LEFT
//我們再用 if (keyDown(keyLeft))
附：我們測試了按鍵代碼和鍵值恆量的效率發現並無太大差別。
12) Math.floor()方法與int()
這個不懂的題目曾在Flashkit的論壇被提出討論過。測試表明，舊的int方法反而效率更高。我們的測試結果也反映了這一點。
13)eval抒發型與中括號語法
我們並沒有發現較着的差別，並不像剛纔所述那樣，舊的eval抒發型比起中括號方法並沒有太大的優勢
var mc = eval_r(“_root.myMc” + i)
var mc = _root["myMc" + i]
//二者效率差不多16) 有關MC的輪迴：ASBroadcaster 同歡同輪迴的差別
論斷
我們從這些測試結果中發現，對不同的需求，接納不同的代碼，我們可以大大提高腳本的執行效率。雖然我們在這裏羅布了許多的優化代碼的方法，需要各人本身測試、實驗的還有很多(考慮到每個人的需求不同).如果你想越發深入地討論這種不懂的題目。可以來我們的論壇。
aw附:
終於翻譯完了，本身也學到很多好東西，各人又啥子不懂的題目可以去gotoAndPlay的官方，也能夠來我的Blog提出！
三黑羽AS心得:淺釋ActionScript的代碼優化
來歷：Kingda blog
這篇文章既爲淺談代碼優化，那末就不深入到OOP設計層面。僅有關Flash8幫助裏面提到的一些代碼編寫優化原則，並加以解釋。
準則來歷於Flash8 幫助，我做了一些解釋：
1.避免從1個輪迴中多次調用1個函數。
在輪迴中包羅小函數的內容，可使效果更佳。小函數生命期短，利於資源釋放。尤其是在大的輪迴中時。
2.儘可能使用本機函數。
本機函數要比用戶界說的函數運行速度更快。本機函數即Flash中內有的一些函數(intrinsic)，好比hellotTest()，你沒須要本身寫1個類似的。
3.不要過多使用 Object 類型。
數值類型註釋應力求精確，這樣可以提高性能。只有在沒有適當的備選數值類型時，才使用 Object 類型。同時也易於代碼管理，時刻知道對象的類型和作用。
同時也有利於編譯器編譯時優化。
4.避免使用 eval_r() 函數或數值訪問運算符。
通常，較爲可取且更有效的做法是隻設置一次局部引用。無可奈什麼時候才用eval，好比轉換_droptarget爲MovieClip時。
5.在開始輪迴前將 Array.length 付與變量，尤其是大的輪迴。
在開始輪迴前將 Array.length 付與變量(好比var iLength:Number)，將其作爲條件使用，而不是使用 myArr.length 本身。
原因，在輪迴中，iLength是Number變量，會被放入寄存器使用，效率遠比訪問Array再得到length高。例如，應使用 來代替： } 6.注重優化輪迴及所有重複動作。
Flash Player 破費許多時間來處理輪迴(如使用 setInterval() 函數的輪迴)。
7.在局部變量夠歷時，不要使用全局變量。類靜態變量也要少用。
全局變量是開發者的惡夢。實在需要全局變量的話，我建議使用singleton設計模式來舉行管理。
8.聲明變量時，添加 var 要害字。
這是爲了編譯時讓編譯器知道你的變量類型，優化編譯。
黑羽增補一點：對要害字的使用要審慎。
不同意使用要害字作爲本身的method和屬性名，除非你明確承認後續開發不會用到不異的事件名和屬性名。
但你怎麼知道flash使用了多少隱藏要害字？太多了！好比說 className, invalidate, refresh, mouseOver等等不常用的要害詞。好的方法是使用SEPY編輯器來寫代碼，那裏面加亮了所有公佈的和沒有公佈的要害詞。
並且因爲很可能和start,load,等這些常用的事件名重複，帶來代碼不須要的修改和貧苦。
9.對有關到調用繪圖資源的函數時，儘量先多判斷再調用。
所有漸變，位置變化，創建刪除MC，組件等函數都有關到繪圖資源的調用。在很多情況下，儘量先用思維規律判斷變量或者對象的屬性，須要時再調用這些函數。這樣可以節省較多的計算資源。 減低預示列表上的複雜性來提高性能 資訊類型: 翻譯
來歷頁面: * lexity-from-the-displaylist-to-increase-performance /
資訊原標題: reduce complexity from the displaylist and increase performance
資訊原筆者: elad.ny
增加Flash應用程序性能的一種最簡略方法是，移除預示列表中所有的隱藏對象，同時使用最少量量的預示對象。 代碼將 通過遍歷整個預示列表來執行，即從預示列表最上層（舞臺），到主應用程序類。 Flash Player執行代碼，並從上到下重繪預示列表中的所有的孩子，直到到達預示對象。 容器可使任何繼承自DisplayObjectContainer的類，如UIComponent，Group或者Sprite。
尤其是在MXML中，很容易就嵌套了預示對象，但是每次嵌套對象時都是很是耗性能的，因爲每個添加到現實對象列表的對象都繼承了1個類，這個類又繼承另1個，如此等等。 爲了理解爲啥子嵌套是高耗損的， 讓我們看一下預示列表類的層次結構。
AS3
當談到預示列表，對AS3來講，所有的預示對象過去曾是MovieClip。 在Flash Pro中早期的Flash版本（AS1和AS2）中，MovieClip類都是動畫的核心類。 每1個MovieClip符號包羅了預示對象的行爲和功能，以及操作時間軸的附帶加上屬性。 許多時辰你並不需要駢枝的圖層以及時間軸的開銷，而究竟上AS3提供了一種能的對象叫做DisplayObject。 DisplayObject是低層的爲那一些能夠被添加到預示列表的所有對象的基類，它繼承了EventDispatcher（它是基於對象的）。
它包孕一些類來幫助管理對象（如cacheASBitmap） 和可視屬性。 預示對象容器是一種這樣的對象，在它們裏面可以包羅子對象（這些子對象是預示對象）。 DisplayObjectContainer包羅了一些方法，來管理它們的孩子對象，例如AddChellold（向容器中添加對 象），numChelloldren（容器所包羅的孩子對象的個數）和removeChellold（移除子對象）。
有些時辰，你需要預示圖形但又不需要時間軸。 這時你需要使用Sprite，它繼承自DisplayObjectContainer類。 一般原則，你最好使用Bitmap，Shape和Sprite類或者它們的子類，而不要選擇MovieClip。
Flex3
底下是最小化的Flex。 Flex對預示對象的核心類是FlexSprite，除了能夠返回1個字符串表示這個對象的位置外，和Sprite沒啥子兩樣。 接下來是UIComponent，它繼承了FlexSprite，也是Flex3中每個可視組件的基類。 UIComponent包孕了鍵盤和鼠標交互，同時也許可在不需要的時辰關閉這些交互，例如label。 它也包羅了許多特徵，例如accessibility（可訪問性），Style（樣式），State（狀態），Invalidation和 Validation（合法性），DataBinding（數值綁定），Effect（效果），嵌入字體等等。
Flex4
底下是Flex4. Flex4使用Group作爲Spark（至關於MX中的UIComponent）中可視元素的容器基類。然後你可使用一系列的組件，如Skin,Graphelloc,HGroup和VGroup。
除了Group以外，也能夠使用SkinnableComponent，它是所有Spark組件的超類，它爲skinnable組件界說了基類。 使用SkinnableComponent類的皮膚是Skin類的典型子類。
以Spark按鍵爲 例。 ButtonBase類是所有Spark按鍵組件的基類。 Button和ToggleButtonBase是ButtonBase的子類。 同樣，諸如CheckBox和RadioButton類是ToggleButtonBase的子類。 按鍵組件繼承了ButtonBase，同時使用了默認皮膚，包羅了1個文本label。 你可以自界說皮膚類來添加圖象到控制或其它任何你需要的東西。 默認按鍵皮膚是spark.skins.spark.ButtonSkin，它繼承自Skin。 最後提到的是Spark中的組件，它們很容易改變，但是也很是重要。
底下做一些測試。 關於預示對象的內存使用情況： Shape: 224 bytes
Sprite: 392 bytes
MovieClip: 428 bytes
UIComponent: 1036 bytes
Group: 1200 bytes
底下，看一下Flash Player代碼在幀上的執行時間。 建議使用“我”頭幾天開發的FrameStats工具。 所做的工作是創建1個快速測試，然後添加方法到
FrameStats 工具 它許可你查看在一幀或幾幀上代碼執行時間（毫秒單位）的信息。 我將把幀率設爲1秒（這樣測試的更清楚，也易於不雅察結果），然後調用1個將被添加到預示對象的方法，添加預示對象到預示列表。 然後可以在控制檯裏跟蹤幀的生命週期。 protected function creationCompleteHandler():void
frameStats = new FrameStats(FlexGlobals.topLevelApplication, false );
frameRateControl = new FrameRateControl( FlexGlobals.topLevelApplication, false, false, 1, 1);
var componenent:UIComponent = new UIComponent();
componenent.addChellold( frameStats );
frameStatsHolder.addElement( componenent );
trace( "Sprite: " + getSize(new Group()) );
uicom.addChellold( sprite );
frameStats.testingExecutionTimeOfMethod( methodToTest, 10000 );
private function methodToTest():void
sprite.addChellold( new Group() );
預示對象
當添加10000個預示對象是，對主要基類構造器的代碼執行以及子類情況如下： Shape
Constructor code of chelloldren executed: 276
Sprite
Constructor code of chelloldren executed: 399
UIComponent
Constructor code of chelloldren executed: 1078
Group
Constructor code of chelloldren executed: 1195
正如所料，構造器代碼和每個構造器的執行在擁有較多嵌套對象時，將破費更長時間。 如果你知道Flash Player時常將構造器方法放到自身代碼的概念，這是有益的，是以在構造器上的執行時間會比其它類更長，我們應該儘量減少構造函數中的代碼。
添加1000個預示對象
按鍵：
雖然我添加了10000個SimpleButton的預示對象，Player在幀率爲1fps時也只用了33毫秒，原因是SimpleButton在預示 對象樹的層次上比較靠上，所以是較少的嵌套結構。 SparkButton在構造器代碼上執行時間要比Halo更長，但有趣的是，SpariButton對預示列表的渲染時間要短一些。 SimpleButton
Constructor code of chelloldren executed: 33
Final user code executed: 730
Player renders changes display list: 304
mx.Button
Constructor code of chelloldren executed: 820
Player renders changes display list: 7075
s:Button
Constructor code of chelloldren executed: 2392
Player renders changes display list: 4539
Text 添加文本的結果也很是有趣。 Spark Label在渲染的時間上做的還不錯，但是在構造函數的執行時間上還是不如Halo組件。 TLF在渲染上做的很差，但是構造器時間上很是好。 TextField
Constructor code of chelloldren executed: 68
Player renders changes display list: 168
mx:Text
Constructor code of chelloldren executed: 743
Player renders changes display list: 685
S:Label
Constructor code of chelloldren executed: 1136
Player renders changes display list: 198
s:RichText
Constructor code of chelloldren executed: 416
Player renders changes display list: 3224
論斷 –使用低層次（即位於結構樹的接近根的位置）的類，例如TextField，SimpleButton（如果可能的話），而不是Halo和Spark 它可能需要更多的代碼，但是將提高性能。
–避免使用TLF
–使用Halo組件而不是Spark組件
–自界說組件時，Sprit > MovieClip & UIComponent > Group
–在創建矢量圖形是，建議使用Shape預示對象