Flash Player 多元件性能测试报告

转自：http://www.xiaos8.com/article.asp?id=552

 

本文是寂寞火山在3月28号的上海Flash开发者交流会演讲的内容。
此文讲的东西非常棒，对于如何优化Flash程序有非常好的帮助，做为一名同是Flash程序员的我郑重推荐此文，如果你觉得这个测试报告对你有用，请支持寂寞火山奉献的这份报告，并且在转载时请写上版权：
作者：寂寞火山；整理：sunbright；原文地址。

★测试环境：
→硬件环境：Intel (R)  Core (TM)2  Duo  CPU  T5850 @2.16GHz，2.00GB内存。
→软件环境：FLASH CS3，Adobe Flash Player 9.0  r45，AVM2。
→FLASH IDE环境：舞台尺寸：750×500像素，帧频：24 fps。
→测试报告源文件：点击进入火山门户相关帖

★本文所用到的简称：
→FP：FLASH PLAYER。
→MC：影片剪辑元件。
→BTN：按钮元件。
→G：图形元件。

★鼠标事件性能测试：

测试分类	测试描述	测试结果	结果分析
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，美工做的素材，最好亲自看一下，并指出注意的地方。
结论
★导致内部绘制的情况： 把鼠标移动到或者移开继承自InteractiveObject的实例。 当鼠标在一个继承自InteractiveObject的实例上点击或者释放时。 当用空格键或者Enter，TAB键激活一个继承自InteractiveObject的实例时。 报告人：寂寞火山 整理：sunbright