Flash8播放器模型：彈性跑道

　　自從FutureSplash以來，就一直從事Flash方面的工作，對於Flash’">播放器的開發，我也有了自己的一些看法。

　　歡迎加入這個彈性極大的跑道模型的討論。

　　我將Flash 播放器看作如一條跑道。跑道上有兩個截然不同的部分，一個是處理ActionScript（它包括事件處理），一個是將內容表現到螢幕上。運行時，Flash播放器圍繞著跑道按照SWF檔案裡指定的幀速前進。不管播放器被賦予什麼樣的指令，播放器都會嘗試按預定的速度播放檔案。指定的幀速即是跑道的最大速度，播放速度只能在此之下而不能超過這個限制值。
播放器跑道模型

　　SWF檔案告訴播放器在規定的時間做相應的事。播放器處理ActionScript或者顯現到螢幕或者兩者同時發出的指令的時候，跑道就會被伸展。如果有許多的資料或者影片剪輯要處理，或者在跑道的單一環線中處理你添加的一切內容或指令，播放器會跳過要求它執行的那些指令，並會在最短的時間裡完成一個迴圈，但不會比指定的幀速快。

　　ActionScript 繁重時

　　圖形繁重時

　　ActionScript and 圖形都繁重時

　　有混合這個模型的另外幾個方面。首先，播放器會將圖形元素構造到一個遞減的分類樹中。從基本的節點開始，有許多的以幀的內容和次級節點構成的分支。播放器每一個迴圈樹目錄上所有的元素都會被處理。當前的Flash 7播放器中，幀的內容按照需要從level0最進階開始依照從小到大的順序被掃描和處理。根據圖解表現關鍵是使樹的層級與元素的內在需要一樣的簡單分明。樹的菜單越少，層級越淺圖形元素將會被更快速的顯現到螢幕上。

　　樹的結構同樣也適用於對ActionScript 位元組碼的處理當中。在AS階段，樹的現狀被將以位元組代碼形式被掃描出來。每一個指定的事件將被逐級執行處理。ActionScript是基於棧的以棧為基礎的，這樣所有的位元組代碼被集中到堆棧上並被依照樹的結構被線性處理。根據給出的幀上的代碼和事件的容量，跑道上的AS部分將會被擴充。儘管沒有一種固定的方法延遲代碼的執行，播放器將會在每一個幀的迴圈中處理完被請求處理的所有內容。有趣的是，我們注意到那些使用功能和事件的代碼能被排列成一個成的序列，等待著處理。在某種意義上，播放器從不會消損的，它會一直的做你所要求的所有工作，不會順從於一個幀的迴圈。關鍵是不要在給出的幀上要求播放器處理太多的內容，並能對最新的幀依照邏輯和事件去處理。

　　至於Flash 8，從播放器的Beta版的外觀來看，cacheAsBitma允許圖形作為位元影像儲存為一個MC的分支。向量圖會以位元影像的形式儲存，但要等到圖片改變了才會渲染。很好的允許播放器集中的儲存於播放器的不同地區，專註於向量儲存怎樣被利用。在一個基於樹的表現模型裡，樹的一些分支被設定成branch.cacheAsBitmap=true， 儲存進程會在第一關建立一個位元影像並將重複利用這張位元影像直到本地區的向量表徵圖記為dirty。 同樣，如果每一幀位元影像儲存分支都被標記為dirty，你不得不強制播放器在每一個幀迴圈中產生一張位元影像（處理+儲存）。在我的測試當中，最佳化利用cacheAsBitmap並不像看起來那樣簡單。

　　總之，Flash8播放器清晰的表明了它是兩個不同元素的組合，圖形處理和ActionScript 位元組碼處理。如果你濫用兩者之中的一種或兩種播放器的運行效率將會降低，導致下一個迴圈之前就認定一切已被完成。在更大的項目開發中，彈性跑道有助於協助我們解釋Flex和Flash發展中所表現的良好效能最佳化背後的一些晦澀難懂的邏輯。就像以前說過的許多次一樣，“等那一幀”