Flash Player 多元件性能测试报告
2010-06-01 11:20
357 查看
转自: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:图形元件。
★鼠标事件性能测试:
本文是寂寞火山在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的实例时。 [align=right]报告人:寂寞火山 整理:sunbright[/align] |
相关文章推荐
- 《Flash Player 多元件性能测试报告》作者:寂寞火山
- 画动画圆之使用 QT4.6/C#/MFC/DELPHI/VB 开发的程序性能测试报告
- boost::asio学习 - HTTP Server性能测试报告
- Hubbledotnet V0.8.3.6 版本性能测试报告
- Flume性能测试报告
- HBase基准性能测试报告
- Android性能专项测试测试点指导(三)--IT之家性能分析报告实战
- Oracle Pro*C/C++游标和存储过程性能测试报告
- 性能测试报告(实例)
- 达尔文流媒体服务器(Darwin Streaming Server)(DSS)并发性能测试报告
- TokuDB性能测试报告
- [置顶] 测试报告参考规范之测试目标(功能和性能)、功能测试方法和性能测试框架、性能瓶颈定位模式
- TokuDB性能测试报告
- NSF性能测试报告
- 网站前端性能测试报告
- 对性能测试工具JMeter 聚合报告中90% Line的解释说明
- SQL数据库与Lucene数据库性能测试报告
- Firefly 性能测试报告
- 性能测试报告(实例)