FLASH PLAYER 多元件性能测试报告
★ 测试环境:
   →硬件环境:Intel (R) Core (TM)2 Duo CPU T5850 @2.16GHz,2.00GB 内存。
   →软件环境:FLASH CS3,Adobe Fl...
”。从测试可以看出来,当冒泡层次比较深的时候,将会额外多占用几乎一倍的 CPU。这等规模的资源占用,绝不可小觑。另外可以
看出的是,就算你不监听,事件冒泡依然占用 CPU,这和鼠标移动的情况是一样的。所以我猜,这两个疑点是不是因为一个原因导
致...
Upcoming SlideShare
Loading in …5
×

多元件鼠标性能测试 鞠海深

1,187 views
1,148 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,187
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
30
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

多元件鼠标性能测试 鞠海深

  1. 1. FLASH PLAYER 多元件性能测试报告 ★ 测试环境: →硬件环境: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 个 200 时,CPU 稳定在 5% 当鼠标在 FP 上快速移动的时 MC,MC 中无其他元件,只有一个形状。 鼠 左 右 ; 400 时 , CPU 稳 候 , CPU 的占 用情 况随 MC 标在 FP 上快速移动,观察 CPU 占用情况。 定在 10%左右 ;800 时, 的数量呈线性增长的趋势。 CPU 稳定在 20%左右。 2,同级多 BTN 测试 在 root 下 分 别 放 置 200 , 400 , 800 个 200 时 , CPU 稳 定 在 当鼠标在 FP 上快速移动的时 BTN,BTN 中无其他元件,只有一个形状。 30%左右;400 时,CPU 候,CPU 占用情况随 BTN 的 鼠标在 FP 上快速移动,观察 CPU 占用情况。 稳定在 50% 左右 ;800 数量呈线性增长的趋势,但 时,CPU 稳定在 70%左 CPU 基数比 MC 大,增长势 右。 头也比 MC 猛。 3,同级多 G 测试 在 root 下分别放置 200,400,800 个 G,G CPU 在三种情况下稳定 G 与鼠标事件无关系。 中无其他元件,只有一个形状。鼠标在 FP 在 1%-2%。 上快速移动,观察 CPU 占用情况。 4,同级多 SPRITE 测试 在 root 下 分 别 放 置 200 , 400 , 800 个 结果与 MC 基本一致。 SPRITE,SPRITE 中无其他元件,只有一个 形状。鼠标在 FP 上快速移动,观察 CPU 占 用情况。 5,多层嵌套 MC 测试 在 root 下 分 别 放 置 40 , 80 , 160 个 40 时,CPU 稳定在 10% 画面上同样数量的 MC,有嵌 MC,MC 中层层嵌套 4 个 MC,这样画面 左右;80 时,CPU 稳定 套比没嵌套的更占 CPU。 上呈现出来的还是 200,400,800 个 MC。 在 20% 左 右 ; 160 时 , 鼠标在 FP 上快速移动,观察 CPU 占用情况。 CPU 稳定在 30%左右。 综合分析与推测 ★疑点一:同级的时候,为什么 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 要高?我想,唯一的解释就是“事件冒泡
  2. 2. ”。从测试可以看出来,当冒泡层次比较深的时候,将会额外多占用几乎一倍的 CPU。这等规模的资源占用,绝不可小觑。另外可以 看出的是,就算你不监听,事件冒泡依然占用 CPU,这和鼠标移动的情况是一样的。所以我猜,这两个疑点是不是因为一个原因导 致的呢?另外我还有个有力的证据来证明是事件冒泡在占用 CPU,就是如果我把每个最外层的 MC 的 mouseChildren 都设置为 false 的话,就不会额外占用那么多 CPU 了。 ★以下三条原则将对性能优化很有帮助: 1,做界面的时候,能用 G 就不用 MC,能用 MC 就不用 BTN。 2,尽量避免元件过多,能合并为一个元件的最好合并。 3,尽量避免元件深度嵌套,能放同级的放同级。 以下三中情况会导致内部绘制: ★ 把鼠标移动到或者移开继承自 sprite 的实例。 ★ 当鼠标在一个继承自 sprite 的实例上点击或者释放时。 ★ 当用空格键或者 Enter 键激活一个继承自 sprite 的实例时。

×