存档

文章标签 ‘性能’

ActionScript 3.0 性能优化小知识

2010年7月21日 评论已被关闭

最近做的很多的事情都是和Flash开发有关,尤其是在性能优化上总结到不少经验,在这里分享给大家。
和其他平台开发一样,Flash程序的运行效率非常重要,为什么总有人觉得Flash程序很卡?甚至有人觉得Flash程序的运行效率还不如IE执行JavaScript 快,原因就在于写Flash程序的人,算法、代码写得太烂,最后连Flash Player的名声都被这些人写坏掉了。
高性能的程序源自高性能的算法、代码、和结构,下面就围绕着这个主题开始展开介绍。

1、改进算法
无论对于那一种程序,好的算法总是非常重要的,而且能够极大地提高程序性能,所以任何性能的优化第一步就是从算法或者说程序逻辑的优化开始,检查自己的程序是否有多余的运算,是否在没有必要的时候做了无用功,往往从这些方面就能找到那些导致性能低下的地方。

2、优化细节代码
针对细节总是好的,有一些小技巧比如:
用 var obj:Object = {}; 要比 var obj:Object = new Object();要好;
var arr:Array = []; 要比 var arr:Array = new Array(); 要好;
for (var i:int=0, len=arr.length; i
如果不是为了保存颜色值请不要适用uint这个类型,他的速度比起 int要慢多了;
Array的遍历要比Object或者Dictionary的枚举要快得多。
if (myObj != null) 要比 if (myObj) 的速度要慢(更正, 之前把结果看反了,对不起大家~), for (var i:* in myObj) 比 for (var i:String in myObj) 要快;
Dictionary当 weak key设置为 true 的时候要比 false 慢;
var myText:String = “a” + “b” + “c”;
var myText2:String = [ "a", "b", "c" ].join(“”);
在JavaScript里面在IE下后者要更快,但是在AS里面,前者更快!
在循环体内声明变量和在循环体外声明变量其实速度上不会有太大的区别。

3、权衡程序的结构
程序的架构也非常重要,良好的结构会带来性能和程序健壮性的提升,但是有的时候又是相互矛盾的,例如代码写得过于健壮,反而会影响性能,这个地方需要开发者自己去权衡。

4、小心Flash的重绘
如果你使用的是Flash Player 的Debugger版本,那么请在检查性能瓶颈的时候不要忘记打开显示重绘区域的功能,这将帮你迅速定位到舞台上有那些地方被重绘了,找出没有显示任何东西却不断重绘的地方,这些地方肯定是有问题的。Flash Player很笨,不会说你把一个DisplayObject的visible设置成false就放弃重绘那个显示对象。所以请保证你的 MovieClip在visible=false的时候为停止状态。有一点很有意思,假设两个现实物体存在 hitTest = true 这样的关系,那么重绘的区域的面积很有可能 > 两者的面积总和!

5、以空间换时间
听起来挺虚,实则很简单,说白了就是以内存换CPU,例如将不变动的值进行保存,免去下次需要此数据的时候进行再次计算,虽然原理很简单,但是有的时候却很容易疏忽掉,而这个往往就造成你的算法效率低下的问题。

6、记得销毁你的对象
对于非常驻的对象使用完之后记得消除其引用,防止出现内存溢出的问题,往往要做到这一点需要有一个良好的编程习惯。

7、清除冗余的代码
有些代码可能你的程序一辈子也不会执行到,请把这些没有用的代码或者对象清理掉,否则内存会被偷偷的蚕食掉。

8、小心使用useBitmapCache = true
一般情况下除非你确定这个显示对象不可能发生变化那么用用也无妨,不过我更推荐自己手动的用BitmapData将该对象Draw一遍,然后让这个对象彻底消失。否则每次的变动都是巨大的性能消耗。

分类: Flash Platform 标签: ,

(转)Flash代码优化

2008年1月5日 评论已被关闭

Actionscript 优化指南
原著 Marco Lapi, aw译

在这篇文章中,我们将讨论多种优化 Actionscript 代码的方法.
此外我们也针对一些典型的游戏代码进行了系列测试,来最大限度的发掘、提高Flash播放器的性能。

代码优化简介

在本文中,我们将向您展示一些通过技术手段得到了优化的flash小游戏。代码优化之所以重要是因为它能帮您节约 flash播放器的资源,还能让您的游戏在不同的硬件环境下运行得更加稳定。本文主要讨论基于flashplayer6.0的一些问题,以及如何通过可行的技术手段去解决它们!

随着flashplayer7.0的发布,一些技术问题已经得到解决了,而且性能大体地有所提高,然而在写本文之时,flashplayer6.0仍然有着广泛的应用。所以我们还是主要集中在6.0这个版本上。-aw猜测:国外买盗版的很少,所以很多人可能都来不及使用7.0,尤其是那些非职业的flash设计者。

何时进行优化

对现有程序进行优化的过程,有时十分的冗长与困难,这与原始代码的非优化程度有关,所以在投入大量时间进行代码优化之前,最重要的是要估计出要在什么地方对代码做出修改或替换。

一个游戏代码的最重要的部分就是主循环体,通常情况下该循环体要在flash的每一帧上执行,并控制游戏中的角色属性和重要的数据参数。而对于主循环体以外的部分,也可能是次要循环部分,同样要注意是给其否分配了过多的资源,而没有分配给那些更需要资源的核心部分。

通过积累在各处节约出来的时间(可能每处仅仅是几个毫秒),您会明显发现自己的swf运行得更加稳定,并且游戏感也大大加强。

简洁与高效的代码

书写出十分简洁、可以再次调用的代码(有时可能是面向对象的)是一项精细的工作,但这需要多年的编程经验。对于OOP(object oriented programming, 面向对象的程序设计),有些场合根本利用不到它的优势,这使得它显得十分奢侈。 在有限的资源条件下(可能是flash播放器的原因),通过更先进的方法,像刚刚提到的OOP,就可能反而导致令人不满意的结果。

我们并不是说OOP对游戏编程不好,只是在某些场合它显得过于奢侈和多余。毕竟有时候“传统的方法”却能得到更好的结果。

大体而言,用OOP是比较好的,因为它让代码维护更加简单。但在后文中,你会看到有时为了充分发挥flashplayer性能,而不采用OOP技术。例如:处理快速滚动或者计算十分复杂的数学问题。

基本的优化

一提及代码优化,我们马上会联想到执行速度的改进,而很少去考虑系统资源的分配。这是因为当今,即使是将被淘汰的计算机,都有足够的内存来运行我们大部分的flash游戏(128M的内存足以满足大多数情况的需要,况且,512M的内存是当今新电脑的基本配置)

变量

在各种重要的代码优化手段中,有这么一条:在定义局部变量的时候,一定要用关键字var来定义,因为在Flash播放器中,局部变量的运行速度更快,而且在他们的作用域外是不耗占系统资源的。

aw附:var变量仅仅在花括号对中才有“生命”,个人认为没有系统学过编程的人容易出错的一个地方:

awMC.onLoad = function(){
  var aw = 1;
}
awMC.onEnterFrame = function(){
//不存在aw这个变量
}

一段非优化代码:

function doSomething()
{
       mx = 100
       my = 100
       ar = new Array()
       for (y=0; y < my; y++)
       {
              for (x=0; x < mx; x++)
              {
                     i = (y * mx) + x
                     arr[i] = i                    
              }
       }

       return arr
}

这段代码中,并未声明函数体内的那些变量(那些仅仅在函数内使用的变量)为局部变量,这使得这些变量被播放器调用的速度更慢,并且在函数执行完毕的时候仍然耗占系统资源。

下面列出的是经过改进的同样功能的代码:

function doSomething()
{
       var mx = 100
       var my = 100
       var ar = new Array()
       for (var y=0; y < my; y++)
       {
              for (var x=0; x < mx; x++)
              {
                     var i = (y * mx) + x
                     arr[i] = i                    
              }
       }

       return arr
}

这样一来所有的变量均被定义为了局部变量,他们能够更快地被播放器调用。这一点在函数大量(10,000次)循环运行时显得尤为重要!当一个函数调用结束的时候,相应的局部变量都会被销毁,并且释放出他们占有的系统资源。

onEnterFrame 事件

onEnterFrame事件对于游戏开发者而言是非常有用的,它使得我们能够快速、反复地按照预设帧频(fps) 运行一段程序。回想在Flash5的时代,这(onEnterFrame实时监控)是一种非常流行的技术,用这样的事件来控制机器游戏对手的逻辑,又或者我们可以在每一个子弹上设置这样的事件来监测子弹的碰撞。

实际上,我们并不推荐给过多的MoveClip添加这样的事件,因为这样做会导致“无头绪码(spaghetti code)”的出现,并且容易导致程序效率明显降低。

大多数情况下,用单独一个onEnterFrame事件就可以解决问题了:用这一个主循环来执行你所需要的操作。

另一个简单的办法是设置一个合适的帧频:要知道帧频越高,CPU资源就越紧张。

在帧频为25-35(fps)之间时,onEnterFrame足以很好地执行较复杂代码,哪怕你的计算机配置较低。因此,在没有特殊要求的场合,我们不推荐使用高于60(fps)的帧频。

矢量图与位图

在处理图形前,我们一定要做出正确的选择。Flash能对矢量图和位图进行完美的兼容,然而矢量图和位图在播放器中的表现实质却完全不同。

在用到矢量图的时候,我们要尽可能简化它们的形状,去除多余的端点。这样做将大大降低播放器用于呈现矢量图所要进行的计算量。另一个重要方面在于线条的运用,尽量减少和避免冗陈的线条结构,因为它们会直接影响到flash的播放效率。

当某个实例透明度小于100时,也会对播放速率造成影响,所以如果你发现自己的Flash播放速率过慢,就去挑出这些透明的实例来吧!

那么,如果真的需要呈现比较复杂的场景时,你就最好考虑使用位图实现。虽然Flash在对位图的渲染效率上并不是最优越的(比如和Flash的“兄长”Director比起来),但丰富的视觉内容呈现只能靠位图(与位图同复杂度的矢量图形渲染速率非常低)了,这也是很多基于区块的游戏中广泛采用像素图作为背景的原因。顺便要提到的是,Flash虽然对GIF,JPG和PNG都有所支持,但是渲染速度上PNG还是占有绝对优势,所以我们建议flash中的位图都尽可能采用PNG格式。

影片剪辑(MovieClip)的可视性[下面将MovieClip简称为mc]

您可能会经常碰到这样一种情况:有大量不可见/屏幕外的mc等待出场(比如游戏中屏幕外的地图、人物等等)。
要知道,播放器仍然要消耗一定的资源来处理这些不可见/屏幕外的mc,哪怕他们是单帧,非播放的状态。

最好的解决办法之一是给这些mc一个空白帧,当他们不出现在屏幕上时,你能用gotoAndStop()语句跳转到这一帧,从而减少播放器对资源的需求。

请务必记住,这种情况下,简单的设置可见度属性为不可见( _visible = false )是无效的,播放器将继续按照这些mc所停留或播放的帧的复杂度来分配资源 。

数组

数组在各种需要记录数据的应用程序和游戏中都被广泛的使用。

一个典型的例子就是基于区块的Flash游戏,在这样一类的游戏中,地图有时被存放成形如arr[y][x]的二维数组。虽然这是一种很常见的方法,但是如果用一维数组的话,却能提高程序的运行效率。另一个重要的方法来提高数组效率是在数组遍历的时候使用for in 循环来代替传统的 for 或者while循环语法。
例如:

一段代码如下

for (var i in arr)
{
       if (arr[i] > 50)
       {
              // 进行某些操作
       }
}

它的执行速度明显高于这一段代码:

for (var i=0; i<10000; i++)
{
       if (arr[i] > 50)
       {
              // 进行某些操作
       }
}

前者的效率比后者提高了30%,这个数字在你的游戏要逐帧执行这一段代码的时候显得更加宝贵!

高级优化:

这里我们对一些游戏中的常用代码进行了效率测试,并给出了结果。其中有一些思路借鉴了本文最后所提到的一些个人或者团体。

我们在两个不同型号的电脑上进行了测试。

AthlonXP 2.6Ghz 台式机 512M内存,Windows2000Pro

P4 2.0Ghz 笔记本 ,WindowsXP家庭版

每一项测试都分为三组,取平均值得到最后结果。

测试的结果单位为“毫秒”,反映了代码执行时间。显然,数值越小,反映代码的性能越好。

所有的代码均由MX2004编译生成的Flash6.0版本。有趣的是,我们可以看到由MX和MX2004编译的差距。

所有的测试细节可以看这个PDF文件(aw注:未翻译,很简单的PDF文档,都能看懂的)

我把测试的结果如下归纳出来,同大家分享:

1) for循环 和 while循环

用while循环将会得到比for循环更好的效率。然而,从数组中读取数据,用for in循环式最好的选择!

所以我们不推荐使用:

for (var i=0; i<1000; i++)
{
       //进行某些操作
}

而推荐使用

var i=-1
while (++i < 1000)
{
       //进行某些操作
}

2) 从数组中读取数据

我们通过测试发现,for in循环的效率大大高于其他的循环方式。参看:

arr = []
MAX = 5000

// Fill an array
for (i=0; i < MAX; i++)
{
       arr[i] = i
}

var item = null

// For Loop
for (var i=0; i < MAX; i++)
{
       item = arr[i]
}

// For In Loop
for (var i in arr)
{
       item = arr[i]
}

// While Loop
i = -1
while(++i < MAX)
{
       item = arr[i]
}

3) 向数组中写入数据(while , for)

可以看到while循环稍占优势。

4) _global(全局)变量同Timeline(时间轴)变量

我们猜测采用全局变量能提高变量调用速度,然而效果并不像预计的那样明显。

5) 单行、多行变量赋值

我们发现单行变量赋值效率大大高于多行。比如:

a = 0
b = 0
c = 0
d = 100
e = 100

的效率就不如:

a = b = c = 0
d = e = 100

6) 变量名寻址

这个测试反映了变量名的预寻址是非常重要的,尤其是在循环的时候,一定要先给丁一个指向。这样大大节约了寻址时间。

比如:

var num = null
t = getTimer()
for (var i=0; i < MAX; i++)
{
       num = Math.floor(MAX) – Math.ceil(MAX)
}
t1.text = "Always lookup: " + (getTimer() – t)

就不如:

t = getTimer()
var floor = Math.floor
var ceil  = Math.ceil
for (var i=0; i < MAX; i++)
{
       num = floor(MAX) – ceil(MAX)
}

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结构

当用到复杂的条件表达式时。把他们打散成为嵌套的独立判断结构是最佳方案。下面的代码我们进行了测试,发现这种效果改进明显!

MAX = 20000
a = 1
b = 2
c = -3
d = 4

var i=MAX
while(–i > -1)
{
       if (a == 1 && b == 2 && c == 3 && d == 4)
       {
              var k = d * c * b * a
       }
}

//下面的判断更加节省时间
var i=MAX
while(–i > -1)
{
       if (a == 1)
       {
              if (b == 2)
              {
                     if (c == 3)
                     {
                            if (d == 4)
                            {
                                   var k = d * c * b * a
                            }
                     }
              }
       }
}

11) TellTarget语法同“点”语法比较

如果你从Flash5.0开始接触Flash代码,那么你一定会记得那时,我们用“tellTarget”来控制MC。

这里测试表明,用tellTarget比点语法效率更高。所以必要的时候,可以考虑采用这种官方公开否认的语法(aw注:个人觉得有点恍惚,不明白为什么会这样。不过既然测试结果如此,那么也有可行性了……)

MAX = 10000
mc = _root.createEmptyMovieClip("test", 1000)

function test_dot()
{
       var i=MAX
       while(–i > -1)
       {
              mc._x = 10
              mc._y = 10
       }

}

function test_tellTarget()
{
       var i=MAX
       while(–i > -1)
       {
              tellTarget(mc)
              {
                     _x = 10
                     _y = 10
              }
       }
}

12) 寻找局部变量(this方法同with方法比较)

局部变量的定位方法很多。我们发现用with比用this更加有优势!

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 = useThis

obj.test2 = useWith

MAX = 10000

function useThis()
{
       var i = MAX
       while(–i > -1)
       {
              this.a = 1
              this.b = 2
              this.c = 3
              this.d = 4
              this.e = 5
              this.f = 6
              this.g = 7
              this.h = 8
       }
}

function useWith()
{
       var i = MAX
       while(–i > -1)
       {
              with(this)
              {
                     a = 1
                     b = 2
                     c = 3
                     d = 4
                     e = 5
                     f = 6
                     g = 7
                     h = 8
              }
       }
}

13) 循环监听键盘事件

同刚才所提到的寻址一样,我们实现给一个指向会得到更好的效率,比如:

keyDown = Key.isDown
keyLeft = Key.LEFT

//我们再用 if (keyDown(keyLeft))

附:我们测试了按键代码和键值常量的效率发现并无太大差别。

14) Math.floor()方法与int()

这个问题曾在Flashkit的论坛被提出讨论过。测试表明,旧的int方法反而效率更高。我们的测试结果也反映了这一点。

15) eval表达式与中括号语法

我们并没有发现明显的差别,并不像刚才所述那样,旧的eval表达式比起中括号方法并没有太大的优势

var mc = eval("_root.myMc" + i)
var mc = _root["myMc" + i]
//两者效率差不多

16) 涉及MC的循环:ASBroadcaster 同欢同循环的差别

测试反映,用未公开的ASBroadcaster 方法能大大提高对MC的循环操作的效率。我们的测试中,建立了500个MC,然后测试把它们清楚所花费的时间。

传统的循环式:

MAX = 500
SX = 550
SY = 330

MovieClip.prototype.onCustomEvent = function()
{
       this.removeMovieClip()
}

function init()
{
       var i=MAX
       var rnd = Math.random
       while(–i > -1)
       {
              var m = _root.attachMovie("enemy","e"+i,i)
              m._x = rnd() * SX
              m._y = rnd() * SY
       }
}

init()

function bench()
{
       var t = getTimer()
       var i=MAX
       while(–i > -1)
       {
              _root["e"+i].onCustomEvent()
       }
       res.text = "time: " + (getTimer() – t)
}

同样的效果,用事件广播(ASBroadcaster)

MAX = 500
evtManager = {}
ASBroadcaster.initialize(evtManager)

SX = 550
SY = 330

MovieClip.prototype.onCustomEvent = function()
{
       this.removeMovieClip()
}

function init()
{
       var i=MAX
       var rnd = Math.random
       while(–i > -1)
       {
              var m = _root.attachMovie("enemy","e"+i,i)
              m._x = rnd() * SX
              m._y = rnd() * SY
              evtManager.addListener(m)
       }
}

init()

function bench()
{
       var t = getTimer()
       evtManager.broadcastMessage("onCustomEvent")
       res.text = "time: " + (getTimer() – t)
}

用MX04为6.0播放器编译、生成文件:

在MX04种,一件有趣的事是,脚本编译器的性能在各方面提高不少。新的编译器在局部、全局变量寻址效率方面有极大的提高,您还可以通过PDF文件发现很多有趣的结果:全局变量寻址比时间轴变量更快了,而嵌套循环也有所改进。几乎每一个用MX04编译的代码效率都高于 MX版本。

awflasher.com附:为什么要为6.0编译呢,国外还有相当一部分用户在使用MX6.0。虽然7.0Player是免费的,但是在国外升级软件似乎不像国内这么火,什么东西马上升到最高。我个人的一些猜测而已

结论:

我们从这些测试结果中发现,对于不同的需求,采用不同的代码,我们可以大大提高脚本的执行效率。虽然我们在这里罗列了许多的优化代码的方法,需要大家自己测试、实验的还有很多(考虑到每个人的需求不同).如果你想更加深入地讨论这类问题。可以来我们的论坛。

aw附:

终于翻译完了,自己也学到很多好东西,大家又什么问题可以去gotoAndPlay的官方,也可以来我的Blog提出!

这片HTML文档也可以直接保存(浏览器-文件-另存即可),不含有任何图片,下到本地亦可查看:)