在flash技術(shù)圈內(nèi)，經(jīng)常會討論一些API的效率問題。之前也曾一度陷入一些問題的討論，但到頭來發(fā)現(xiàn)很多問題比較莫名其妙。因為as本身的封閉性，和flash社區(qū)的整體水平問題，很多問題很難從理論上深入的分析，從而都沒有一致的定論。本來技術(shù)這種問題，即使沒有絕對一致的定論，至少應(yīng)該有相對一致的定論，但時常有時候有些人講這些相對的結(jié)論推廣到普遍的情況之下。
比如具體的一個問題：for和for each的快慢問題，因為我們無法進行深入的理論分析——即根據(jù)底層代碼的拆解，來分析每一步的消耗——那么我們只有通過經(jīng)驗方法來證明。不過要注意，分析的本意是單獨的考察某種因素對結(jié)果的影響，所以我們要確保影響問題的因素足夠單一，并且更重要的是，在比較兩種方法的時候要保證在一致的因素下。
經(jīng)常看到有人在分析這個問題的時候，夾雜一些不必要的因素，甚至兩種方法夾雜的因素都不一樣。
var t:uint = getTimer();
var arr0:Vector.<uint> = new Vector.<uint>(1000000,true);
var arr1:Vector.<uint> = new Vector.<uint>(1000000,true);
var i:uint=0
for(i=0;i<1000000;i+=1)
{
arr0[i]++;
}
trace(getTimer()-t);//116
t = getTimer();
var v:uint
for each(v in arr1)
{
v++;
}
trace(getTimer()-t);//125
以上是在Flex SDK 4.5下的測試結(jié)果，為了盡量將因素單一化，我們采用同樣的操作，即累加數(shù)組元素，這里可以看見for循環(huán)并不低。
應(yīng)該注意的是雖然同樣都是累加操作，但是前者帶有數(shù)組的下標訪問，而后者則直接是對象的操作，所以嚴格來說影響這兩種情況的因素并不一致，但考慮到實際情況中我們不可能脫離這兩種特征而獨立的去使用循環(huán)，所以這種不一致也是合情合理的。當然，在純粹理論意義上我們也可以去掉累加操作而直接跑一邊空的循環(huán)：
var t:uint = getTimer();
var arr0:Vector.<uint> = new Vector.<uint>(1000000,true);
var arr1:Vector.<uint> = new Vector.<uint>(1000000,true);
var i:uint=0
for(i=0;i<1000000;i+=1)
{
}
trace(getTimer()-t);//11
t = getTimer();
var v:uint
for each(v in arr1)
{
}
trace(getTimer()-t);//31
另外在追加一個小的測試：在for循環(huán)中采用+=和++兩種運算符的快慢，
var i:uint=0
for(i=0;i<1000000;i++)
{
arr0[i]++;
}
trace(getTimer()-t);//114
盡管每次測試結(jié)果不會太一樣，但是總體看來，++的效率并不比+=低。但是經(jīng)常聽到有人說+=的效率更高，具體原因不明。
最后附一份Flash Pro CS6環(huán)境下的測試結(jié)果：
var t:uint = getTimer();
var arr0:Vector.<uint> = new Vector.<uint>(1000000,true);
var arr1:Vector.<uint> = new Vector.<uint>(1000000,true);
var i:uint=0
for(i=0;i<1000000;i++)
{
arr0[i]++;
}
trace(getTimer()-t);//25
t = getTimer();
var v:uint
for each(v in arr1)
{
v++;
}
trace(getTimer()-t);//35
差別還是蠻大的，主要原因可能在于新版本的優(yōu)化。
