《Flash Player 多元件性能测试报告》作者：寂寞火山

1，同级多MC测试

在root下分别放置200，400，800个MC，MC中无其他元件，只有一个形状。鼠标在FP上快速移动，观察CPU占用情况。

200时：CPU稳定在5%左右；
400时：CPU稳定在10%左右；
800时：CPU稳定在20%左右。

当鼠标在FP上快速移动的时候，CPU的占用情况随MC的数量呈线性增长的趋势。

2，同级多BTN测试

在root下分别放置200，400，800个BTN，BTN中无其他元件，只有一个形状。鼠标在FP上快速移动，观察CPU占用情况。

200时：CPU稳定在30%左右；
400时：CPU稳定在50%左右；
800时：CPU稳定在70%左右。

当鼠标在FP上快速移动的时候，CPU占用情况随BTN的数量呈线性增长的趋势，但CPU基数比MC大，增长势头也比MC猛。

3，同级多G测试

在root下分别放置200，400，800个G，G中无其他元件，只有一个形状。鼠标在FP上快速移动，观察CPU占用情况。

CPU在三种情况下稳定在1%-2%。

G与鼠标事件无关系。

4，同级多SPRITE测试

在root下分别放置200， 400，800个SPRITE，SPRITE中无其他元件，只有一个形状。鼠标在FP上快速移动，观察CPU占用情况。

结果与MC基本一致。

?

5，多层嵌套MC测试

在root下分别放置40，80，160个MC，MC中层层嵌套4个MC，这样画面上呈现出来的还是200，400，800个MC。鼠标在FP上快速移动，观察CPU占用情况。

40时：CPU稳定在10%左右；
80时：CPU稳定在20%左右；
160时：CPU稳定在30%左右。

画面上同样数量的MC，有嵌套比没嵌套的更占CPU。

★疑点一：同级的时候，为什么BTN比MC占用CPU明显多很多？我们知道，SimpleButton类直接继承自InteractiveObject，而MC则继承自Sprite，Sprite又继承自DisplayObjectContainer，DisplayObjectContainer才继承自InteractiveObject。直观上感觉应该是MC应该比按钮更复杂，更占CPU的，但事实却正好相反，为什么呢？

★疑点二：当鼠标在屏幕上移动的时候，FP都做了些什么呢？重绘屏幕了么？打开“显示重绘区域”，可以很明显的看到并没有重绘。那到底是什么在占用CPU，我猜测很可能是鼠标事件的缘故。那么当鼠标移动的时候，会触发什么事件呢？观察InteractiveObject，无非是mouseMove、mouSEOver、mouSEOut、rollOver、rollOut。而MC和BTN的这些事件都是继承自InteractiveObject的，为什么对CPU的占用情况却大不相同？BTN为什么比MC高那么多？难道是BTN的某些属性造成的这个差异？比如：overState、useHandCursor等？

★疑点三：如果真的是事件造成的CPU占用？那么我明明没监听任何事件却还在占用CPU呢？如果不是因为监听，那只能推测是dispatchEvent造成的，因为不管你监听不监听，事件总是要dispatch的，可问题又来了，为什么当我的鼠标放在屏幕上不动的时候，却又不会占用CPU？不动的时候，明明也dispatch了啊？

★疑点四：为什么多层嵌套MC的时候，屏幕上相同数量的MC比同级放置占用的CPU要高？我想，唯一的解释就是“事件冒泡”。从测试可以看出来，当冒泡层次比较深的时候，将会额外多占用几乎一倍的CPU。这等规模的资源占用，绝不可小觑。另外可以看出的是，就算你不监听，事件冒泡依然占用CPU，这和鼠标移动的情况是一样的。所以我猜，这两个疑点是不是因为一个原因导致的呢？另外我还有个有力的证据来证明是事件冒泡在占用CPU，就是如果我把每个最外层的MC的mouseChildren都设置为false的话，就不会额外占用那么多CPU了。

★以下几条将对性能优化很有帮助：
1，做界面的时候，能用G就不用MC，能用MC就不用BTN。
2，尽量避免元件过多，能合并为一个元件的最好合并。
3，尽量避免元件深度嵌套，能放同级的放同级。
4，不需要鼠标操作的对象，请将mouseChildren和mouseEnabled设置为false。
5，美工做的素材，最好亲自看一下，并指出注意的地方。

1. 把鼠标移动到或者移开继承自InteractiveObject的实例。
2. 当鼠标在一个继承自InteractiveObject的实例上点击或者释放时。
3. 当用空格键或者Enter，TAB键激活一个继承自InteractiveObject的实例时。