SlideShare ist ein Scribd-Unternehmen logo
1 von 2
Downloaden Sie, um offline zu lesen
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 要高?我想,唯一的解释就是“事件冒泡
”。从测试可以看出来,当冒泡层次比较深的时候,将会额外多占用几乎一倍的 CPU。这等规模的资源占用,绝不可小觑。另外可以
看出的是,就算你不监听,事件冒泡依然占用 CPU,这和鼠标移动的情况是一样的。所以我猜,这两个疑点是不是因为一个原因导
致的呢?另外我还有个有力的证据来证明是事件冒泡在占用 CPU,就是如果我把每个最外层的 MC 的 mouseChildren 都设置为 false
的话,就不会额外占用那么多 CPU 了。
★以下三条原则将对性能优化很有帮助:
1,做界面的时候,能用 G 就不用 MC,能用 MC 就不用 BTN。
2,尽量避免元件过多,能合并为一个元件的最好合并。
3,尽量避免元件深度嵌套,能放同级的放同级。




以下三中情况会导致内部绘制:
★ 把鼠标移动到或者移开继承自 sprite 的实例。
★ 当鼠标在一个继承自 sprite 的实例上点击或者释放时。
★ 当用空格键或者 Enter 键激活一个继承自 sprite 的实例时。

Weitere ähnliche Inhalte

Mehr von FLASH开发者交流会

Flash media server 开发经验谈 沈先彬
Flash media server 开发经验谈 沈先彬Flash media server 开发经验谈 沈先彬
Flash media server 开发经验谈 沈先彬FLASH开发者交流会
 
Flash 独立游戏开发之路 徐黎明
Flash 独立游戏开发之路 徐黎明Flash 独立游戏开发之路 徐黎明
Flash 独立游戏开发之路 徐黎明FLASH开发者交流会
 
程序接口的另类理解与使用 孙毅
程序接口的另类理解与使用 孙毅程序接口的另类理解与使用 孙毅
程序接口的另类理解与使用 孙毅FLASH开发者交流会
 
9月18技术交流会大赛作品介绍 廖湘宁
9月18技术交流会大赛作品介绍 廖湘宁9月18技术交流会大赛作品介绍 廖湘宁
9月18技术交流会大赛作品介绍 廖湘宁FLASH开发者交流会
 
Flash mmorpg游戏引擎及工具开发概述-张明光
Flash mmorpg游戏引擎及工具开发概述-张明光Flash mmorpg游戏引擎及工具开发概述-张明光
Flash mmorpg游戏引擎及工具开发概述-张明光FLASH开发者交流会
 
Flash 游戏应用框架和模块化开发 邱广钦
Flash 游戏应用框架和模块化开发 邱广钦Flash 游戏应用框架和模块化开发 邱广钦
Flash 游戏应用框架和模块化开发 邱广钦FLASH开发者交流会
 
7月24日交流会麻球演讲 廖湘宁
7月24日交流会麻球演讲 廖湘宁7月24日交流会麻球演讲 廖湘宁
7月24日交流会麻球演讲 廖湘宁FLASH开发者交流会
 
轻量级Flash服务器开发框架(刘恒)
轻量级Flash服务器开发框架(刘恒)轻量级Flash服务器开发框架(刘恒)
轻量级Flash服务器开发框架(刘恒)FLASH开发者交流会
 
Ghost cat 以皮肤为主体的ui框架(唐翎)
Ghost cat 以皮肤为主体的ui框架(唐翎)Ghost cat 以皮肤为主体的ui框架(唐翎)
Ghost cat 以皮肤为主体的ui框架(唐翎)FLASH开发者交流会
 
Avm2虚拟机浅析与as3性能优化(陈士凯)
Avm2虚拟机浅析与as3性能优化(陈士凯)Avm2虚拟机浅析与as3性能优化(陈士凯)
Avm2虚拟机浅析与as3性能优化(陈士凯)FLASH开发者交流会
 
Actionscript中的元编程和开发流程解耦(谈熠)
Actionscript中的元编程和开发流程解耦(谈熠)Actionscript中的元编程和开发流程解耦(谈熠)
Actionscript中的元编程和开发流程解耦(谈熠)FLASH开发者交流会
 
Flash独立游戏 现状分析与发展思考(陈静)
Flash独立游戏 现状分析与发展思考(陈静)Flash独立游戏 现状分析与发展思考(陈静)
Flash独立游戏 现状分析与发展思考(陈静)FLASH开发者交流会
 

Mehr von FLASH开发者交流会 (20)

Flash media server 开发经验谈 沈先彬
Flash media server 开发经验谈 沈先彬Flash media server 开发经验谈 沈先彬
Flash media server 开发经验谈 沈先彬
 
Flash 独立游戏开发之路 徐黎明
Flash 独立游戏开发之路 徐黎明Flash 独立游戏开发之路 徐黎明
Flash 独立游戏开发之路 徐黎明
 
程序接口的另类理解与使用 孙毅
程序接口的另类理解与使用 孙毅程序接口的另类理解与使用 孙毅
程序接口的另类理解与使用 孙毅
 
Flash游戏大会 商文烨
Flash游戏大会 商文烨Flash游戏大会 商文烨
Flash游戏大会 商文烨
 
Flash ria usability 刘轩飞
Flash ria usability 刘轩飞Flash ria usability 刘轩飞
Flash ria usability 刘轩飞
 
9月18技术交流会大赛作品介绍 廖湘宁
9月18技术交流会大赛作品介绍 廖湘宁9月18技术交流会大赛作品介绍 廖湘宁
9月18技术交流会大赛作品介绍 廖湘宁
 
简化复杂的Flash应用程序 谈熠
简化复杂的Flash应用程序 谈熠简化复杂的Flash应用程序 谈熠
简化复杂的Flash应用程序 谈熠
 
Flash mmorpg游戏引擎及工具开发概述-张明光
Flash mmorpg游戏引擎及工具开发概述-张明光Flash mmorpg游戏引擎及工具开发概述-张明光
Flash mmorpg游戏引擎及工具开发概述-张明光
 
Web base 吴志华
Web base 吴志华Web base 吴志华
Web base 吴志华
 
Flash 游戏应用框架和模块化开发 邱广钦
Flash 游戏应用框架和模块化开发 邱广钦Flash 游戏应用框架和模块化开发 邱广钦
Flash 游戏应用框架和模块化开发 邱广钦
 
7月24日交流会麻球演讲 廖湘宁
7月24日交流会麻球演讲 廖湘宁7月24日交流会麻球演讲 廖湘宁
7月24日交流会麻球演讲 廖湘宁
 
浅析Flash特效开发 陈勇
浅析Flash特效开发 陈勇浅析Flash特效开发 陈勇
浅析Flash特效开发 陈勇
 
Flash网络通讯处理 陈苏俊
Flash网络通讯处理 陈苏俊Flash网络通讯处理 陈苏俊
Flash网络通讯处理 陈苏俊
 
轻量级Flash服务器开发框架(刘恒)
轻量级Flash服务器开发框架(刘恒)轻量级Flash服务器开发框架(刘恒)
轻量级Flash服务器开发框架(刘恒)
 
Ghost cat 以皮肤为主体的ui框架(唐翎)
Ghost cat 以皮肤为主体的ui框架(唐翎)Ghost cat 以皮肤为主体的ui框架(唐翎)
Ghost cat 以皮肤为主体的ui框架(唐翎)
 
Flash 原型开发(刘磊)
Flash 原型开发(刘磊)Flash 原型开发(刘磊)
Flash 原型开发(刘磊)
 
Avm2虚拟机浅析与as3性能优化(陈士凯)
Avm2虚拟机浅析与as3性能优化(陈士凯)Avm2虚拟机浅析与as3性能优化(陈士凯)
Avm2虚拟机浅析与as3性能优化(陈士凯)
 
Actionscript中的元编程和开发流程解耦(谈熠)
Actionscript中的元编程和开发流程解耦(谈熠)Actionscript中的元编程和开发流程解耦(谈熠)
Actionscript中的元编程和开发流程解耦(谈熠)
 
Flex开发实践经验谈(谢敏)
Flex开发实践经验谈(谢敏)Flex开发实践经验谈(谢敏)
Flex开发实践经验谈(谢敏)
 
Flash独立游戏 现状分析与发展思考(陈静)
Flash独立游戏 现状分析与发展思考(陈静)Flash独立游戏 现状分析与发展思考(陈静)
Flash独立游戏 现状分析与发展思考(陈静)
 

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

  • 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. ”。从测试可以看出来,当冒泡层次比较深的时候,将会额外多占用几乎一倍的 CPU。这等规模的资源占用,绝不可小觑。另外可以 看出的是,就算你不监听,事件冒泡依然占用 CPU,这和鼠标移动的情况是一样的。所以我猜,这两个疑点是不是因为一个原因导 致的呢?另外我还有个有力的证据来证明是事件冒泡在占用 CPU,就是如果我把每个最外层的 MC 的 mouseChildren 都设置为 false 的话,就不会额外占用那么多 CPU 了。 ★以下三条原则将对性能优化很有帮助: 1,做界面的时候,能用 G 就不用 MC,能用 MC 就不用 BTN。 2,尽量避免元件过多,能合并为一个元件的最好合并。 3,尽量避免元件深度嵌套,能放同级的放同级。 以下三中情况会导致内部绘制: ★ 把鼠标移动到或者移开继承自 sprite 的实例。 ★ 当鼠标在一个继承自 sprite 的实例上点击或者释放时。 ★ 当用空格键或者 Enter 键激活一个继承自 sprite 的实例时。