如安在flash开发中提高性能，总是1个讨论很强烈热闹的不懂的题目。记得每次参加flash技术交流会，性能相关的提问是至关多的。
六合会翻译了1个预示列表与性能相关的帖子，我就想起来理事一下在flash中提高性能的方法。 垃圾收受接管的一些知识总结：
1、被删除对象在外部的所有引用一定要被删除干净才能被体系当成垃圾收受接管处理掉。
2、父对象内部的子对象被外部其它对象引用了，会导致此子对象不会被删除，子对象不会被删除又会导致了父对象不会被删除。
3、如果1个对象中引用了外部对象，当本身被删除或者不需要使用此引用对象时，一定要记得把此对象的引用设置为null。
四、本对象删除不了的原因不一定是本身被引用了，也可能是本身的孩子被外部引用了，孩子删不掉导致父亲也删不掉。
5、除了引用需要删除外，体系组件或者全局工具、管理类如果提供了卸载方法的就一定要调用删除内部对象，否则可能会造成内存泄露和性能丧失。
6、父对象立刻被删除了不代表子对象就会被删除或立刻被删除，可能会在后期被体系自动删除或第二次移除操作时被删除。
七、如果父对象remove了子对象后没有清除对子对象的引用，子对象一样是不能被删除的，父对象也不能被删除。
八、注册的事件如果没有被移除不影响自界说的强行收受接管机制，但可能会影响没事了的收受接管机制，所以最好是做到注册的事件***都要记得移除干净。
9、父对象被删除了不代表其余子对象都删除了，找到一种状态的泄露代码不等于其它状态就没有泄露了，要各板块各状态逐个举行测试分析，直到测试任何状态下都能删除整个对象为止。
10、当触发了某个event后，不再使用的话，请将其remove掉。
11、能不使用Effect就不要使用Effect。
内存泄露举例：
1、引用泄露：对子对象的引用，外部对本对象或子对象的引用都需要置null。
2、体系类泄露：使用了体系类而健忘做删除操作了，如BindingUtils.bindSetter()，ChangeWatcher.watch() 函数时辰完结后需要调用ChangeWatcher.unwatch()函数来清除引用 ，否则使用此函数的对象将不会被删除； 类似的还有MUSIC，VIDEO，IMAGE，TIMER，EVENT，BINDING等。
3、效果泄露：当对组件应用效果Effect的时辰，当本对象本删除时需要把本对象和子对象上的Effect动画停止掉，然后把Effect的target对象置null; 如果不停止掉动画直接把 Effect置null将不能没事了移除对象。
四、SWF泄露：要完全删除1个SWF要调用它的unload()方法并且把对象置null。
5、图片泄露：当Image对象使用完结后要把source置null。
6、声音、视频泄露: 当不需要1个音乐或视频是需要停止音乐，删除对象，引用置null。
内存泄露解决方法：
1. 在组件的REMOVED_FROM_STAGE事件回掉中做垃圾处理操作（移除所有对外引用（无论是VO还是组件的都需要删除），删除***，调用体系类 的清除方法） 先remove再置null, 确保被remove或者removeAll后的对象在外部的引用全部释放干净。
2. 利用Flex的性能优化工具Profile来对项目进程项举行监控，可知道历史创建过哪些对象，目前有哪些对象没有被删除，创建的数量，占用的内存比例和用量，创建过程等信息。
总结：要害还是要做好清除工作，本身设置的引用本身要记得删除，本身用过的体系类要记得做好收受接管处理工作。 以上不懂的题目解决的好的话不需要自界说强制收受接管器也可能被体系没事了的自动收受接管掉。
众所周知，由于Flash Player的垃圾收受接管机制是自动举行的，是以就算是上面所说的内容的内容都符合要求，那末还是会产生内存“高居不下于”的情况。
是以，我接下来介绍1个很是规的体式格局，让Flash Player的垃圾收受接管机制在我的控制之中。（以下的内容也不是我创始的，但是就此总结说明一下） 一优化计算方法
1.用乘法来代替除法（当除数可转化为有限数的时辰）。好比var n:Number = value * 0.5;要比var n:Number = value / 2;快。但差别并不是很大。只有在需要大量计算情况下，好比3D引擎中差别才比较较着。
2.用位运算代替除2或乘2。好比10>>1要比10*2快，而10<<1要比10*2快。从测试来看位运算几乎比乘除快 一倍，但是一般情况下，我们不能选择位运算，好比我们就不能用13>>1来代替13/2，尽管前者比后者运算速度更快，但2者的运算结果却不 一样。所以还是要看具体情况。
3.用unit()或int()代替取整运算Math.floor()和Math.ceil()。好比var test:uint = uint(1.5);要比var test:Number = Math.floor(1.5);快；而var test:uint = uint(1.5)+1;要比var test:Number = Math.ceil(1.5);也快。若是Math.floor()，还可以用位运算(>>0)来代替。好比var test:uint =1.5>>0，比unit()或int()更快。
4.用乘-1来代替Math.abs()方法。好比var nn:Number = -23;var test:Number= nn < 0 ? nn * -1 : nn;要比var nn:Number = -23;var test:Number = Math.abs(nn);快。
当然还有更多的优化计算的方法。一般来讲，低级运算要比高级运算速度；内部方法比调用其它方法速度快。另外要注意的是，这些方法有的时辰可能并一定合用.
二 Actionscript 优化指南
什么时候举行优化
对现有程序举行优化的过程，有时十分的冗长与困难，这与原始代码的非优化程度有关，所以在投入大量时间举行代码优化之前，最重要的是要估计出要在啥子处所对代码做出修改或替代。
1个游戏代码的最重要的部门就是主轮回体，通常理况下该轮回体要在flash的每一帧上执行，并控制游戏中的角色属性和重要的数值参数。而对主轮回体以外的部门，也可能是非主要轮回部门，同样要注意是给其否分配了过多的资源，而没有分配售那一些更需要资源的核心部门。
通过积累在遍地省电出来的时间(可能每处仅仅是几个毫秒)，您会较着发现本身的swf运行得越发稳定，并且游戏感也大大加强。
简洁与高效的代码
书写出十分简洁、可以再次调用的代码(有时可能是面向对象的)是一项精致的工作，但这需要多年的编程经验。对OOP(object oriented programming，面向对象的程序设计)，有些场合根本利用不到它的优势，这要得它显得十分奢侈。在有限的资源条件下(可能是flash播放器的原因)，通过更先进的方法，像方才提到的OOP，就可能反而导致使人不称心的结果。
我们并不是说OOP对游戏编程不好，只是在某些场合它显得过于奢侈和骈枝。毕竟有时辰“传统的方法”却能得到更好的结果。
大体而言，用OOP是比较好的，因为它让代码维护越发简略。但在后文中，你会看见有时为了充分阐扬flashplayer性能，而不接纳OOP技术。例如：处理快速骨碌或者计算十分复杂的数学不懂的题目。
基本的优化
一提及代码优化，我们顿特殊情况遐想到执行速度的改进，而很少去考虑体系资源的分配。这是因为当今，即使是将被淘汰的计算机，都有足够的内存来运行我们大部门的flash游戏(128M的内存完全可以餍足大大都情况的需要，何况，512M的内存是当今新电脑的基本配置)
变量
在各种重要的代码优化手段中，有这么一条：在界说局部变量的时辰，一定要用要害字var来界说，因为在Flash播放器中，局部变量的运行速度更快，并且在她们的作用域外是不耗占体系资源的。
aw附：var变量仅仅在花括号对中才有“生命”，个人以为没有体系学过编程的人容易出错的1个处所： 一段非优化代码: 最近代码中，并未声明函数体内的那一些变量(那一些仅仅在函数内使用的变量)为局部变量，这要得这些变量被播放器调用的速度更慢，并且在函数执行完结的时辰仍然耗占体系资源。
底下面所开列出的是经过改进的同样功能的代码： 这样一来所有的变量均被界说为了局部变量，她们能够更快地被播放器调用。这一点在函数大量(10，000次)轮回运行时显得尤为重要！当1个函数调用竣事的时辰，相应的局部变量城市被销毁，并且释放出她们占有的体系资源。
onEnterFrame 事件
onEnterFrame事件对游戏开发者而言是很是有效的，它要得我们能够快速、反复地按照设计帧频(fps)运行一段程序。回想在 Flash5的时代，这(onEnterFrame及时监控)是一种很是流行的技术，用这样的事件来控制机器游戏对手的思维规律，又或者我们可以在每1个子弹 上设置这样的事件来监测子弹的碰撞。
实际上，我们并不推荐给过多的MoveClip添加这样的事件，因为这样做会导致“无头绪码(spaghetti code)”的出现，并且容易导致程序效率较着减低。
大大都情况下，用单唯1个onEnterFrame事件就能够解决不懂的题目了：用这1个主轮回来执行你所需要的操作。
另1个简略的办法是设置1个合适的帧频：要知道帧频越高，CPU资源就越紧张。
在帧频为25-35(fps)之间时，onEnterFrame完全可以很好地执行较复杂代码，哪怕你的计算机配置较低。是以，在没有特殊要求的场合，我们不推荐使用高于60(fps)的帧频。
矢量图与位图
在处理图形前，我们一定要做出正确的选择。Flash能对矢量图和位图举行完美的兼容，然而矢量图和位图在播放器中的体现实质却完全不同。
在用到矢量图的时辰，我们要尽可能简化它们的外形，去除骈枝的端点。这样做将大大减低播放器用于出现矢量图所要举行的计算量。另1个重要方面在于线条的运用，尽量减少和避免冗陈的线条结构，因为它们会直接影响到flash的播放效率。
当某个实例透明度小于100时，也会对播放速率造成影响，所以如果你发现本身的Flash播放速率过慢，就去挑出这些透明的实例来吧！
那末，如果真的需要出现比较复杂的场景时，你就最好考虑使用位图实现。虽然Flash在对位图的渲染效率上并不是最优越的(好比和Flash的“兄 长”Director比起来)，但富厚的视觉内容出现只能靠位图(与位图同复杂度的矢量图形渲染速率很是低)了，这也是很多基于区块的游戏中广泛接纳像素 图作为配景的原因。顺便要提到的是，Flash虽然对GIF,JPG和PNG都有所支持，但是渲染速度上PNG还是占有绝对优势，所以我们建议flash 中的位图都尽可能接纳PNG格局。
影片剪接(MovieClip)的可视性[底下将MovieClip简称为mc]
您可能会时常遇到这样一种情况：有大量不可见/荧幕外的mc等候出场(好比游戏中荧幕外的地图、人物等等)。
要知道，播放器仍然要耗损一定的资源来处理这些不可见/荧幕外的mc，哪怕她们是单帧，非播放的状态。
最好的解决办法之一是给这些mc1个空白帧，当她们不出现在荧幕上时，你能用gotoAndStop()语句跳转到这一帧，从而减少播放器对资源的需求。
请务必记住，这种情况下，简略的设置可见度属性为不可见( _visible = false )是无效的，播放器将接续按照这些mc所停留或播放的帧的复杂度来分配资源。
数组
数组在各种需要记录数值的应用程序和游戏中都被广泛的使用。
1个典型的例子就是基于区块的Flash游戏，在这样一类的游戏中，地图有时被存放成形如arr[y][x]的二维数组。虽然这是一种很常见的方 法，但是如果用一维数组的话，却能提高程序的运行效率。另1个重要的方法来提高数组效率是在数组遍历的时辰使用for in 轮回来代替传统的 for 或者whellole轮回语法。
例如：
一段代码如下 它的执行速度较着高于这一段代码： 前者的效率比后者提高了30%，这个数字在你的游戏要逐帧执行这一段代码的时辰显得越发宝贵！
高级优化：
1) for轮回和 whellole轮回
用whellole轮回将会得到比for轮回更好的效率。然而，从数组中读取数值，用for in轮回式最好的选择！
所以我们不推荐使用： 2) 从数组中读取数值
我们通过测试发现，for in轮回的效率大大高于其它的轮回体式格局。参看： 3) 向数组中写入数值(whellole , for)
可以看见whellole轮回稍占优势。
4) _global(全局)变量同Timeline(时间轴)变量
我们推测接纳全局变量能提高变量调用速度，然而效果并不像估计的那样较着。
5) 单行、多行变量赋值
我们发现单行变量赋值效率大大高于多行。好比：
a = 0
b = 0
c = 0
d = 100
e = 100
效率就不如：
a = b = c = 0
d = e = 100
6) 变量名寻址
这个测试反映了变量名的预寻址是很是重要的，尤其是在轮回的时辰，一定要先给丁1个指向。这样大大省电了寻址时间。
好比： 就不如： 7) 短变量名和长变量名
变量名越短，效率越高。考虑到长变量名也有它的好处（好比，易于维护等），是以建议在要害部位（好比大量轮回出现的时辰）使用短变量名，最好就1-2个字符。
8)轮回前、后声明变量
在测试前，我们以为轮回前声明变量会越发省电时间，不意测试结果并不较着，甚或还恰恰相反！ // 内部声明
t = getTimer()
for (var i=0; i < MAX; i++)
{
var test1 = i
}
t1.text = “Inside:” + (getTimer() – t)
// 外部声明
t = getTimer()
var test2
for (var i=0; i < MAX; i++)
{
test2 = i
}
9) 使用嵌套的if结构
当用到复杂的条件抒发型时。把她们打散成为嵌套的自力判断结构是最佳方案。底下的代码我们举行了测试，发现这种效果改进较着！ 10) 寻找局部变量(thellos方法同with方法比较)
局部变量的定位方法很多。我们发现用with比用thellos越发有优势！ obj = {}
obj.a = 1
obj.b = 2
obj.c = 3
obj.d = 4
obj.e = 5
obj.f = 6
obj.g = 7
obj.h = 8
obj.test1 = useThellos
obj.test2 = useWith
MAX = 10000
function useThellos()
{
var i = MAX
whellole(–i > -1)
{
thellos.a = 1
thellos.b = 2
thellos.c = 3
thellos.d = 4
thellos.e = 5
thellos.f = 6
thellos.g = 7
thellos.h = 8
}
}
function useWith()
{
var i = MAX
whellole(–i > -1)
{
with(thellos)
{
a = 1
b = 2
c = 3
d = 4
e = 5
f = 6
g = 7
h = 8
}
}
}
11) 轮回监听键盘事件
同刚才所提到的寻址一样，我们实现给1个指向会得到更好的效率，好比：
keyDown = Key.isDown
keyLeft = Key.LEFT
//我们再用 if (keyDown(keyLeft))
附：我们测试了按键代码和键值恒量的效率发现并无太大差别。
12) Math.floor()方法与int()
这个不懂的题目曾在Flashkit的论坛被提出讨论过。测试表明，旧的int方法反而效率更高。我们的测试结果也反映了这一点。
13)eval抒发型与中括号语法
我们并没有发现较着的差别，并不像刚才所述那样，旧的eval抒发型比起中括号方法并没有太大的优势
var mc = eval_r(“_root.myMc” + i)
var mc = _root["myMc" + i]
//二者效率差不多16) 有关MC的轮回：ASBroadcaster 同欢同轮回的差别
论断
我们从这些测试结果中发现，对不同的需求，接纳不同的代码，我们可以大大提高脚本的执行效率。虽然我们在这里罗布了许多的优化代码的方法，需要各人本身测试、实验的还有很多(考虑到每个人的需求不同).如果你想越发深入地讨论这种不懂的题目。可以来我们的论坛。
aw附:
终于翻译完了，本身也学到很多好东西，各人又啥子不懂的题目可以去gotoAndPlay的官方，也能够来我的Blog提出！
三黑羽AS心得:浅释ActionScript的代码优化
来历：Kingda blog
这篇文章既为浅谈代码优化，那末就不深入到OOP设计层面。仅有关Flash8帮助里面提到的一些代码编写优化原则，并加以解释。
准则来历于Flash8 帮助，我做了一些解释：
1.避免从1个轮回中多次调用1个函数。
在轮回中包罗小函数的内容，可使效果更佳。小函数生命期短，利于资源释放。尤其是在大的轮回中时。
2.尽可能使用本机函数。
本机函数要比用户界说的函数运行速度更快。本机函数即Flash中内有的一些函数(intrinsic)，好比hellotTest()，你没须要本身写1个类似的。
3.不要过多使用 Object 类型。
数值类型注释应力求精确，这样可以提高性能。只有在没有适当的备选数值类型时，才使用 Object 类型。同时也易于代码管理，时刻知道对象的类型和作用。
同时也有利于编译器编译时优化。
4.避免使用 eval_r() 函数或数值访问运算符。
通常，较为可取且更有效的做法是只设置一次局部引用。无可奈什么时候才用eval，好比转换_droptarget为MovieClip时。
5.在开始轮回前将 Array.length 付与变量，尤其是大的轮回。
在开始轮回前将 Array.length 付与变量(好比var iLength:Number)，将其作为条件使用，而不是使用 myArr.length 本身。
原因，在轮回中，iLength是Number变量，会被放入寄存器使用，效率远比访问Array再得到length高。例如，应使用 来代替： } 6.注重优化轮回及所有重复动作。
Flash Player 破费许多时间来处理轮回(如使用 setInterval() 函数的轮回)。
7.在局部变量够历时，不要使用全局变量。类静态变量也要少用。
全局变量是开发者的恶梦。实在需要全局变量的话，我建议使用singleton设计模式来举行管理。
8.声明变量时，添加 var 要害字。
这是为了编译时让编译器知道你的变量类型，优化编译。
黑羽增补一点：对要害字的使用要审慎。
不同意使用要害字作为本身的method和属性名，除非你明确承认后续开发不会用到不异的事件名和属性名。
但你怎么知道flash使用了多少隐藏要害字？太多了！好比说 className, invalidate, refresh, mouseOver等等不常用的要害词。好的方法是使用SEPY编辑器来写代码，那里面加亮了所有公布的和没有公布的要害词。
并且因为很可能和start,load,等这些常用的事件名重复，带来代码不须要的修改和贫苦。
9.对有关到调用绘图资源的函数时，尽量先多判断再调用。
所有渐变，位置变化，创建删除MC，组件等函数都有关到绘图资源的调用。在很多情况下，尽量先用思维规律判断变量或者对象的属性，须要时再调用这些函数。这样可以节省较多的计算资源。 减低预示列表上的复杂性来提高性能 资讯类型: 翻译
来历页面: * lexity-from-the-displaylist-to-increase-performance /
资讯原标题: reduce complexity from the displaylist and increase performance
资讯原笔者: elad.ny
增加Flash应用程序性能的一种最简略方法是，移除预示列表中所有的隐藏对象，同时使用最少量量的预示对象。 代码将 通过遍历整个预示列表来执行，即从预示列表最上层（舞台），到主应用程序类。 Flash Player执行代码，并从上到下重绘预示列表中的所有的孩子，直到到达预示对象。 容器可使任何继承自DisplayObjectContainer的类，如UIComponent，Group或者Sprite。
尤其是在MXML中，很容易就嵌套了预示对象，但是每次嵌套对象时都是很是耗性能的，因为每个添加到现实对象列表的对象都继承了1个类，这个类又继承另1个，如此等等。 为了理解为啥子嵌套是高耗损的， 让我们看一下预示列表类的层次结构。
AS3
当谈到预示列表，对AS3来讲，所有的预示对象过去曾是MovieClip。 在Flash Pro中早期的Flash版本（AS1和AS2）中，MovieClip类都是动画的核心类。 每1个MovieClip符号包罗了预示对象的行为和功能，以及操作时间轴的附带加上属性。 许多时辰你并不需要骈枝的图层以及时间轴的开销，而究竟上AS3提供了一种能的对象叫做DisplayObject。 DisplayObject是低层的为那一些能够被添加到预示列表的所有对象的基类，它继承了EventDispatcher（它是基于对象的）。 它包孕一些类来帮助管理对象（如cacheASBitmap） 和可视属性。 预示对象容器是一种这样的对象，在它们里面可以包罗子对象（这些子对象是预示对象）。 DisplayObjectContainer包罗了一些方法，来管理它们的孩子对象，例如AddChellold（向容器中添加对 象），numChelloldren（容器所包罗的孩子对象的个数）和removeChellold（移除子对象）。
有些时辰，你需要预示图形但又不需要时间轴。 这时你需要使用Sprite，它继承自DisplayObjectContainer类。 一般原则，你最好使用Bitmap，Shape和Sprite类或者它们的子类，而不要选择MovieClip。
Flex3
底下是最小化的Flex。 Flex对预示对象的核心类是FlexSprite，除了能够返回1个字符串表示这个对象的位置外，和Sprite没啥子两样。 接下来是UIComponent，它继承了FlexSprite，也是Flex3中每个可视组件的基类。 UIComponent包孕了键盘和鼠标交互，同时也许可在不需要的时辰关闭这些交互，例如label。 它也包罗了许多特征，例如accessibility（可访问性），Style（样式），State（状态），Invalidation和 Validation（合法性），DataBinding（数值绑定），Effect（效果），嵌入字体等等。
Flex4
底下是Flex4. Flex4使用Group作为Spark（至关于MX中的UIComponent）中可视元素的容器基类。然后你可使用一系列的组件，如Skin,Graphelloc,HGroup和VGroup。
除了Group以外，也能够使用SkinnableComponent，它是所有Spark组件的超类，它为skinnable组件界说了基类。 使用SkinnableComponent类的皮肤是Skin类的典型子类。
以Spark按键为 例。 ButtonBase类是所有Spark按键组件的基类。 Button和ToggleButtonBase是ButtonBase的子类。 同样，诸如CheckBox和RadioButton类是ToggleButtonBase的子类。 按键组件继承了ButtonBase，同时使用了默认皮肤，包罗了1个文本label。 你可以自界说皮肤类来添加图象到控制或其它任何你需要的东西。 默认按键皮肤是spark.skins.spark.ButtonSkin，它继承自Skin。 最后提到的是Spark中的组件，它们很容易改变，但是也很是重要。
底下做一些测试。 关于预示对象的内存使用情况： Shape: 224 bytes
Sprite: 392 bytes
MovieClip: 428 bytes
UIComponent: 1036 bytes
Group: 1200 bytes
底下，看一下Flash Player代码在帧上的执行时间。 建议使用“我”头几天开发的FrameStats工具。 所做的工作是创建1个快速测试，然后添加方法到
FrameStats 工具 它许可你查看在一帧或几帧上代码执行时间（毫秒单位）的信息。 我将把帧率设为1秒（这样测试的更清楚，也易于不雅察结果），然后调用1个将被添加到预示对象的方法，添加预示对象到预示列表。 然后可以在控制台里跟踪帧的生命周期。 protected function creationCompleteHandler():void
frameStats = new FrameStats(FlexGlobals.topLevelApplication, false );
frameRateControl = new FrameRateControl( FlexGlobals.topLevelApplication, false, false, 1, 1);
var componenent:UIComponent = new UIComponent();
componenent.addChellold( frameStats );
frameStatsHolder.addElement( componenent );
trace( "Sprite: " + getSize(new Group()) );
uicom.addChellold( sprite );
frameStats.testingExecutionTimeOfMethod( methodToTest, 10000 );
private function methodToTest():void
sprite.addChellold( new Group() );
预示对象
当添加10000个预示对象是，对主要基类构造器的代码执行以及子类情况如下： Shape
Constructor code of chelloldren executed: 276
Sprite
Constructor code of chelloldren executed: 399
UIComponent
Constructor code of chelloldren executed: 1078
Group
Constructor code of chelloldren executed: 1195
正如所料，构造器代码和每个构造器的执行在拥有较多嵌套对象时，将破费更长时间。 如果你知道Flash Player时常将构造器方法放到自身代码的概念，这是有益的，是以在构造器上的执行时间会比其它类更长，我们应该尽量减少构造函数中的代码。
添加1000个预示对象
按键：
虽然我添加了10000个SimpleButton的预示对象，Player在帧率为1fps时也只用了33毫秒，原因是SimpleButton在预示 对象树的层次上比较靠上，所以是较少的嵌套结构。 SparkButton在构造器代码上执行时间要比Halo更长，但有趣的是，SpariButton对预示列表的渲染时间要短一些。 SimpleButton
Constructor code of chelloldren executed: 33
Final user code executed: 730
Player renders changes display list: 304
mx.Button
Constructor code of chelloldren executed: 820
Player renders changes display list: 7075
s:Button
Constructor code of chelloldren executed: 2392
Player renders changes display list: 4539
Text 添加文本的结果也很是有趣。 Spark Label在渲染的时间上做的还不错，但是在构造函数的执行时间上还是不如Halo组件。 TLF在渲染上做的很差，但是构造器时间上很是好。 TextField
Constructor code of chelloldren executed: 68
Player renders changes display list: 168
mx:Text
Constructor code of chelloldren executed: 743
Player renders changes display list: 685
S:Label
Constructor code of chelloldren executed: 1136
Player renders changes display list: 198
s:RichText
Constructor code of chelloldren executed: 416
Player renders changes display list: 3224
论断 –使用低层次（即位于结构树的接近根的位置）的类，例如TextField，SimpleButton（如果可能的话），而不是Halo和Spark 它可能需要更多的代码，但是将提高性能。
–避免使用TLF
–使用Halo组件而不是Spark组件
–自界说组件时，Sprit > MovieClip & UIComponent > Group
–在创建矢量图形是，建议使用Shape预示对象