關于Timer還是EnterFrame的選擇，一直是很多AS3開發者討論的話題， 隨著10.1即將普及，我這次對10.1的Timer和EnterFrame進行了一次較詳細的測試，給大家在他們的選擇和使用上做些參考。

注，flashplayer10.1新增了一個當前窗口在非激活狀態下會自動降低fps到2fps來節省cpu消耗，這將直接影響靠fps驅動的enterframe的效率和準確性。

測試環境主要以網頁下的flash執行效率為主， 分為空運算和重運算，同時運行和分別運行。

?

FPS為25（大多數應用的默認值）， 即40ms間隔，發布統一選擇以10.1發布。

為了避免因為頻繁trace或頻繁寫入場景txt受到影響，我設定了間斷式的輸出結果來保證結果的純潔。

(測試代碼見樓底)

測試結果如下：

1，獨立Timer 運行，即40毫秒的timer，更新時無任何運算。

結論：從結果上看， Timer在網頁中難以穩定運行在40ms， 但貌似相對穩定的運行在65和70之間切換。
2，獨立Timer 運行 ， 在上面的基礎上增加最小化當前窗口和切換到其他tab頁中的操作。

結論：如圖所見，Timer同樣被10.1的新增自動降fps功能影響，會被限制到2fps。

3， EnterFrame獨立運行，25fps，更新時無任何運算。

結論： 比Timer更準確，但 除了剛開始的1秒鐘，之后的fps并不是穩定在40的， 而是在35和50之間切換。

但至少是圍繞著40ms。

4，EnterFrame的降fps和Timer的相同，都是500ms, 2fps。 這個就不貼圖了。

5，因為無運算時Timer比Enterframe時間效率要差一些，以至于獨立的Timer重運算普遍都比EnterFrame的耗時要偏長。

6，獨立Timer，改為 100ms 和 110ms的測試。

結論：Timer 在100毫秒跑的非常精確，經過測試，可以達到精確的值必須是100的倍數，即100,200,300... 右圖為110ms對比,可以看到非常的詭異。 這個在pc和mac測試結果都差不多，pc上更精確，mac略有偶爾的數值抖動。

7,Timer使用空運算，EnterFrame使用重運算，同時運行，順序是Timer在前。

結論： 我們發現，由于enterframe中使用了重運算，timer即便是在更新時，由于得不到cpu時間，并不會被執行，而是等enterframe執行結束后，timer再執行，并且由于是空操作，所以timer和enterframe返回的時間是同樣的。

8，為了進一步證實第七點結論，又做了兩組實驗：1）timer以40ms和enterframe的10fps（100ms）， 2）讓timer以100ms，enterframe是25fps。

結論：兩組實驗都完全輸出enterframe在前的順序，并且timer和enterframe的時間都一致，所以可以證實因為enterframe效率優于timer，timer總是在enterfame之后才會更新，在enterframe執行重運算時， ?timer會得不到cpu時間。

9，Timer重運算，EnterFrame空運算，fps一致。

結論：由于以上論證，再加上Timer內有重運算，enterframe依然會被先執行，并且Timer的速度會受到進一步影響，時間經常無法和EnterFrame同步，只能勉強跟上。

寫了這些實驗，對Timer和EnterFrame的使用上有一些建議：

1，EnterFrame是恒定的，穩定的，比較適合用來更新渲染畫面，如Tween。 但不適合做異步計算和處理， 如果能保證cpu每幀的計算效率在40ms以內，可以把計算放到enterframe時序中，這樣可以穩定25fps，當然，這不包括渲染損耗。

2，Timer在100ms的倍數是很穩定的，pc和mac都能穩定，非100的倍數的值會有兩個相差不大的值交替出現。

3，EnterFrame在12、20、30fps都比25fps更穩定，25fps會有兩個相差不到大的數值交替出現。

4，EnterFrame在計算時優于Timer。

5，Timer更適合使用異步的長周期來改變數據的狀態，并不適合短時間持續更新數據，或是渲染畫面。

6，EnterFrame和Timer同樣受到非活動創口的fps自動降低的影響。

7，當受到影響時，無法通過判斷frameRate＝＝2，使用一個延遲時間，判斷出正好500ms的延遲（2fps），并在相應的enterframe中做切換特殊處理，在2fps中要完成原正常fps的渲染結果才能避免渲染的延遲影響。

時間效率，Timer和EnterFrame在FP 10.1之后測試和建議