Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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,229 views

Published on

  • Be the first to comment

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

  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 的实例时。

×