点评：对于每一个和每一个速度，由于我们无法进行深入的理论分析，根据底层代码的分解，分析每一步的消费情况，所以我们只用实证的方法来证明，感兴趣的朋友可以看看啊，希望对你有所帮助。




在Flash技术圈，一些API的效率问题经常被讨论。在过去，曾有过一些问题的讨论，但最终，很多问题是难以形容的。因为这本身和Flash社区的整体水平接近，许多问题都很难在深入的理论分析，因此没有一致的结论。即使是没有绝对的一致，应该有比较一致的结论。有时，有些人说，这些相对的结论被概括为一般情况。

例如，一个具体的问题：和每个的快与慢的问题，因为我们无法进行深入的理论分析研究，mdash；即根据底层代码的拆解，分析每一步--消费；mdash；然后我们只能通过实证的方法证明的。但是，我们应该注意分析的目的是探讨某一因素单独影响的结果，所以我们必须确保影响问题的因素是单一的不足，更重要的是，我们必须确保我们以同样的方式时，我们比较了这两种方法。
人们常常看到，在分析这个问题时，有一些不必要的因素，甚至这两种方法是不同的。

复制代码代码如下所示：
VaR T：单位= getTimer（）；
无功arr0：向量。=新向量。（1000000，正确）；
VaR arr1：向量。=新向量。（1000000，正确）；
我：单位= 0 VaR
对于（i = 0；i < 1000000；i + = 1）
{
arr0 {我} + +；
}
微量（getTimer（）t）； / / 116
T = getTimer（）；
功五：单元
每个（在前）
{
++；
}
微量（getTimer（）t）； / / 125

以上是Flex SDK 4.5下的测试结果。为了简化这些因素，我们使用相同的操作，即累积数组元素。在这里我们可以看到for循环不低。
应该指出的是，虽然同样是积累的操作，但前者用下标访问数组，后者是操作的直接对象，所以严格来说这两种条件下的影响因素也不尽相同，但考虑到我们不可能从这两种特征和独立的循环使用的实际情况，所以这种不一致是合情合理的。当然，在纯理论的意义上，我们可以摆脱的累积操作，直接运行空循环。

复制代码代码如下所示：
VaR T：单位= getTimer（）；
无功arr0：向量。=新向量。（1000000，正确）；
VaR arr1：向量。=新向量。（1000000，正确）；
我：单位= 0 VaR
对于（i = 0；i < 1000000；i + = 1）
{
}
微量（getTimer（）t）； / / 11
T = getTimer（）；
功五：单元
每个（在前）
{
}
微量（getTimer（）t）； / / 31

除此之外，还有一个小测试，用于两个和++操作符的循环速度，

复制代码代码如下所示：
我：单位= 0 VaR
对于（i = 0；i < 1000000；i +）
{
arr0 {我} + +；
}
微量（getTimer（）t）； / / 114

虽然每个测试结果都不一样，但总的来说，效率并不低于++，但经常听到人们说=更有效和具体原因不明。
最后，一份Flash Pro CS6环境测试结果：

复制代码代码如下所示：
VaR T：单位= getTimer（）；
无功arr0：向量。=新向量。（1000000，正确）；
VaR arr1：向量。=新向量。（1000000，正确）；
我：单位= 0 VaR
对于（i = 0；i < 1000000；i +）
{
arr0 {我} + +；
}
微量（getTimer（）t）； / / 25
T = getTimer（）；
功五：单元
每个（在前）
{
++；
}
微量（getTimer（）t）； / / 35

差别很大，主要原因可能是新版本的优化。