在flash技術(shù)圈內(nèi)，經(jīng)常會(huì)討論一些API的效率問題。之前也曾一度陷入一些問題的討論，但到頭來發(fā)現(xiàn)很多問題比較莫名其妙。因?yàn)閍s本身的封閉性，和flash社區(qū)的整體水平問題，很多問題很難從理論上深入的分析，從而都沒有一致的定論。本來技術(shù)這種問題，即使沒有絕對(duì)一致的定論，至少應(yīng)該有相對(duì)一致的定論，但時(shí)常有時(shí)候有些人講這些相對(duì)的結(jié)論推廣到普遍的情況之下。
比如具體的一個(gè)問題：for和for each的快慢問題，因?yàn)槲覀儫o法進(jìn)行深入的理論分析——即根據(jù)底層代碼的拆解，來分析每一步的消耗——那么我們只有通過經(jīng)驗(yàn)方法來證明。不過要注意，分析的本意是單獨(dú)的考察某種因素對(duì)結(jié)果的影響，所以我們要確保影響問題的因素足夠單一，并且更重要的是，在比較兩種方法的時(shí)候要保證在一致的因素下。
經(jīng)常看到有人在分析這個(gè)問題的時(shí)候，夾雜一些不必要的因素，甚至兩種方法夾雜的因素都不一樣。
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ù)組的下標(biāo)訪問，而后者則直接是對(duì)象的操作，所以嚴(yán)格來說影響這兩種情況的因素并不一致，但考慮到實(shí)際情況中我們不可能脫離這兩種特征而獨(dú)立的去使用循環(huán)，所以這種不一致也是合情合理的。當(dāng)然，在純粹理論意義上我們也可以去掉累加操作而直接跑一邊空的循環(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
另外在追加一個(gè)小的測試：在for循環(huán)中采用+=和++兩種運(yùn)算符的快慢，
var i:uint=0
for(i=0;i<1000000;i++)
{
arr0[i]++;
}
trace(getTimer()-t);//114
盡管每次測試結(jié)果不會(huì)太一樣，但是總體看來，++的效率并不比+=低。但是經(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)化。
