1. AVM2 性能测试报告
★ 测试环境：
→硬件环境：Pentium(R) D CPU 3.00GHz 2.99GHz，2.00GB 内存。
→软件环境：FLASH CS3，Flash Player 9.0.115.0，AVM2，IE 浏览器。
→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 稳定在 15%左右。
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 与 MC 情况相同，
SPRITE，SPRITE 中无其他元件，只有一个 可以排除时间轴和鼠标事件
形状。鼠标在 FP 上快速移动，观察 CPU 占 存在联系的可能性。问题应该
用情况。 出现在 InteractiveObject 类
上。
5，多层嵌套 MC 测试 在 root 下 分 别 放 置 40 ， 80 ， 160 个 40 时 ， CPU 稳 定 在 8% 画面上同样数量的 MC，有嵌
MC，MC 中层层嵌套 4 个 MC，这样画面 左右；80 时，CPU 稳定 套比没嵌套的更占 CPU。
上呈现出来的还是 200，400，800 个 MC。 在 15% 左 右 ； 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 了啊？

2. ★疑点四：为什么多层嵌套 MC 的时候，屏幕上相同数量的 MC 比同级放置占用的 CPU 要高？我想，唯一的解释就是“事件冒泡
”。从测试可以看出来，当冒泡层次比较深的时候，将会额外多占用几乎一倍的 CPU。这等规模的资源占用，绝不可小觑。另外可以
看出的是，就算你不监听，事件冒泡依然占用 CPU，这和鼠标移动的情况是一样的。所以我猜，这两个疑点是不是因为一个原因导
致的呢？另外我还有个有力的证据来证明是事件冒泡在占用 CPU，就是如果我把每个最外层的 MC 的 mouseChildren 都设置为 false
的话，就不会额外占用那么多 CPU 了。
★由于我不了解 AVM2 的内部机制，所以我现在也没办法确认答案。不过总结出这些规律，就算不知道原理，也还是很有用的，以
下三条原则将对性能优化很有帮助：
1，做界面的时候，能用 G 就不用 MC，能用 MC 就不用 BTN。
2，尽量避免元件过多，能合并为一个元件的最好合并。
3，尽量避免元件深度嵌套，能放同级的放同级。
★ 第二部分，简单动画性能测试：
测试分类 测试描述 测试结果 结果分析
1，无背景 舞台上没有其它任何图形和元件，只有一 CPU 稳定在 8%左右。 当舞台上无任何内容的时候 ，
个矢量 MC 跟随鼠标快速移动，观察 CPU CPU 占用比较低。
占用情况。
2，单一纯色矢量背景 舞台上只有一个布满舞台的纯色矩形矢量 CPU 稳定在 10%左右。 比 舞 台 上 无 内 容 多 占 一 点 点
背景，然后同样的一个矢量 MC 在舞台上 CPU，不是很明显。
随鼠标快速移动，观察 CPU 占用情况。
3，单一杂色位图背景 舞台上只有一个大尺寸的杂色位图背景， CPU 稳定在 12%左右。 比 单 一 矢 量 背 景 多 占 一 点 点
然后同样的一个矢量 MC 在舞台上随鼠标 CPU，不是很明显。
快速移动，观察 CPU 占用情况。
4，单一杂色矢量背景 舞台上只有一个色彩丰富的矢量背景，然 CPU 稳定在 32%左右。 当矢量背景的色彩和构成比较
后同样的一个矢量 MC 在舞台上随鼠标快 复杂时，位于其上的动画占用
速移动，观察 CPU 占用情况。 CPU 非常高。
5，多元件背景 舞台上有 200 个矢量元件，然后同样的一 CPU 稳定在 45%左右。 当背景构成有很多元件的时候 ，
个矢量 MC 在舞台上随鼠标快速移动，观 将比单一矢量背景占用更多的
察 CPU 占用情况。 CPU。
5[1]，元件启用位图缓存 同上，但把 200 个矢量元件都启用位图缓 CPU 稳定在 17%左右。 当多矢量元件背景，并启用位
存。 图缓存时，比不启用位图缓存
有明显的性能提高，但没有单
一位图背景时性能高。
5[2]，拖动 MC 启用位图 同上，但把拖动的矢量 MC 也启用位图缓 CPU 稳定在 10%左右。 当画面上所有的矢量都启用位
缓存 存。 图缓存时，资源占用与无背景
或单一背景几乎接近。但本测试
结果目前仅建立在平移动画上。
5[3]，增加元件数量 同上，但把背景元件的数量增加至 800。 CPU 稳定在 23%左右。 当舞台上元件很多时，就算全
部启用位图缓存，资源占用依
然比较严重。
6，多嵌套元件背景 在舞台上放置 40 个 MC，MC 中层层嵌套 4 CPU 稳定在 58%左右。 对比情况 5，画面虽然都是 200
个 MC，这样画面上呈现出来的还是 200 个 个 MC，但 MC 有嵌套比没嵌套
MC。鼠标在 FP 上快速移动，观察 CPU 占 会多占 10%以上的 CPU。
用情况。
6[1]，拖动 MC 启用位图 同上，但把拖动的矢量 MC 启用位图缓存。 CPU 稳定在 85%左右。 当仅把动画 MC 启用位图缓存
缓存 时，CPU 非但没有下降，反而
狂飙，原因不明。
6[2]，背景 MC 启用位图 40 个 MC 都启用位图缓存，但拖动 MC 关 CPU 稳定在 15%左右。 背景 MC 位图缓存，而动画不
缓 存， 但 拖 动 MC 不启 闭位图缓存。 位图缓存，性能比 6[1]反而好
用 很多。

3. 6[3]，增加 MC 量 把背景 MC 增至 160 个，160 个 MC 和拖动 CPU 稳定在 25%左右。 由此可见，如果将每个 MC 都
MC 都启用位图缓存。 启用位图缓存，性能有很大提
高。
6[4]，全部启用位图缓存 同上，但把每个 MC 里的嵌套 MC 也都启 CPU 稳定在 25%左右。 对比上一种情况，性能无明显
用位图缓存。 变化。
6[5] ， 只 有 最 上 层 背 景 把 160 个 MC 统一放到一个 MC 里，只对 鼠标移动时，CPU 稳 只对最上层 MC 启用位图缓存，
MC 启用位图缓存 这个最上层 MC 启用位图缓存，拖动 MC 定在 35%左右。 不动时， 而子 MC 都不启用位图缓存，
也启用位图缓存。 也有 5%的占用。 这样会占用较高的 CPU。 而且虽
然只多了一层嵌套，但 CPU 却
多了 10%，最奇怪的是鼠标不
动，也有 5%的占用。
6[6]，全部启用位图缓存 同上，但把嵌套 MC 也都全部启用位图缓 鼠标移动时，CPU 稳 如果把所有的嵌套 MC 和拖动
存。 定 在 10% ； 不动 时， MC 也 都 启 用 位 图 缓 存 ， CPU
不占用 CPU。 占用率和情况 5[2]近似。说明全
部启用位图缓存对 CPU 优化有
很大帮助。
7，位图测试 在舞台上放 100 个位图图片做背景，拖动 CPU 稳定在 60%左右。 对比情况 5，背景为位图图片
MC 为矢量。 CPU 占用反而偏高，原因不解。
7[1]，拖动 MC 启用位图 同上，但把拖动 MC 启用位图缓存。 CPU 稳定在 75%左右。 拖动 MC 也启用位图缓存 CPU
缓存 占用反而更高，原因不解。
7[2]，拖动 MC 也用位图 舞台上还是 100 个 MC，但拖动 MC 也变成 CPU 稳定在 65%左右。 就算舞台上的所有因素都是原
一个位图。 版位图图片，但只要图片多 ，
CPU 占用率依然非常高，而且
画面会显得异常卡。
7[3]，背景位图转换成一 把舞台上的所有背景图片转换成一个 MC， 如 果 拖 动 MC 也 启 用 对位图元件启用位图缓存会得
个 MC 然后对这个 MC 启用位图缓存。 位图缓存，那 CPU 只 到比对矢量元件启用位图缓存
在 5%左右；如果拖动 更好的效果，甚至比单一杂色
MC 不启启用位图缓存 位图背景效果还好，原因不明 ，
CPU 也只有 12%左右。 也需是这个位图色彩没之前单
一位图的色彩丰富？
综合分析与推测
★本测试可以得出以下几点结论：
1，测试第一部分的三条结论依然适用。
2，在复杂色彩矢量背景上做动画比在位图和单一纯色矢量背景上做动画占用更多的 CPU。
3，当多矢量元件做背景时，如果矢量元件没有全部启用位图缓存，一定要避免动画单独启用位图缓存。
4，多位图图片做背景时，也一定要避免动画单独启用位图缓存。
5，将多位图转成 MC 并启用位图缓存将得到更好的性能，但如同把矢量图进行位图缓存一样，会占用更多的内存。
6，任何情况下，一旦启用遮罩层，CPU 都将成倍飙升。