|
|
作者：jacky-zh…
本文章描述了代码优化在为移动设备写运行起来速度快的游戏中扮演的角色。我会用例子说明如何、什么时候和为什么要优化你的代
码，来榨干兼容MIDP的手机的每一滴性能。我们将要讨论为什么优化是必要的和为什么有时候最好不要优化。我将解释高级优化和低
级优化的差别，然后我们会知道如何使用J2ME无线开发包（WTK）自带的Profile程序来发现到哪里去优化你的代码。这篇文章最后揭
示了很多让你的MIDlet运行的技术。
为什么优化?
计算机游戏可以分为两大类: 实时的和输入驱动的. 输入驱动的游戏显示游戏的当前运行状态,并在继续之前无限地等待用户的输入.
扑克牌游戏属于这一类，同样，大多数的猜谜游戏、过关游戏和文字冒险游戏都属于这一类。实时游戏，有时候被称为技能或动作游戏
，不等待用户，他们不停地运行直到游戏结束。
技能和动作游戏经常以大量的屏幕上运东为特征(想想Galaga游戏和Robotron游戏)。刷新率必须至少有10fps（每秒的帧数）并且要
有足够的动作来保持玩家的挑战性。它们需要玩家快速的反应和好的手眼配合，所以就强迫S&A（技能和动作）游戏必须对玩家的输入
有很强的响应能力。在快速响应玩家案件的同时提供高帧数的图形动作，这是实时游戏的代码必须运行起来快的原因。在用J2ME开发
的时候，挑战性就更大了。
Java 2 Micro Edition（J2ME）是java的一个分解版本。 适用于有限功能的小型设备，比如手机和PDA。J2ME设备有：
*有限的输入能力（没有键盘!）（译者注：这里键盘特指个人电脑的键盘）
*小的显示尺寸
*有限的内存容量和堆大小
*慢速的CPU
在J2ME平台上写出快的游戏-------写出在比桌面电脑里的慢得多的CPU上运行的代码更是挑战了开发者。
什么时候不优化
如果你不是在写一个技能或者动作游戏，那么可能不需要优化。如果玩家已经为自己的下一步考虑了几秒钟抑或几分钟，她可能不会
介意如果你的游戏响应花掉了几百微秒。这个规则的一个例外是，如果这个游戏在决定下一步如何运行的时候有大量的工作要处理，比
如搜索一百万个可能的象棋片组合。这种情况下，你可能想要优化你的代码，从而在几秒钟内计算出电脑的下一步，而不是几分钟。
就算你正在写这种类型的游戏，优化也可能是危险的。许多这样的技术伴随着一个代价--他们表示着好”的程序设计这个通常概念飞
过来的时候，同时使你的代码更难读懂。有些是一个权衡，需要开发者大大增加程序的大小来得到性能上一点点的改进。J2ME开发者
们对于保持他们的JAR尽可能的小这个挑战再熟悉不过了。这里是一些不优化的理由：
*优化是一个增加bug的好手
*有些技术会降低你的代码的移植性
*你可能要花费大量的努力来得到微小的或者没有改进
*优化是困难的
最后一点需要一些阐述。优化是一个活动目标，在Java平台上更是这样，而且在J2ME上就更加突出，因为其运行环境是那样的多变。
你优化后的代码可能在一个模拟器上运行得更快，但却在实际设备上更慢，或者相反。为一部手机优化可能会降低其在另一部上的性能
。
不过还是有希望。有两条路径你可以做优化，高层的和底层的。第一条基本上会在所有的平台上增加执行性能，甚至会改进你代码的
整个质量。第二条是可能会让你头疼的，但是那些底层技术是很容易创造的，而且更加容易消去如果你不想使用它们。最起码，他们看
起来很有趣。
我们将用系统的timer在实际设备上剖析你的代码，这可以帮助你测量出那些技术在你所开发的硬件上到底有多有效。
最后一点：
*优化是有趣的
一个反面例子：
让我们来看一看这个包含两个类的简单的应用程序，首先，是Midlet...
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class OptimizeMe extends MIDlet implements CommandListener {
private static final boolean debug = false;
private Display display;
private OCanvas oCanvas;
private Form form;
private StringItem timeItem = new StringItem( "Time: ", "Unknown" );
private StringItem resultItem =
new StringItem( "Result: ", "No results" );
private Command cmdStart = new Command( "Start", Command.SCREEN, 1 );
private Command cmdExit = new Command( "Exit", Command.EXIT, 2 );
public boolean running = true;
public OptimizeMe() {
display = Display.getDisplay(this);
form = new Form( "Optimize" );
form.append( timeItem );
form.append( resultItem );
form.addCommand( cmdStart );
form.addCommand( cmdExit );
form.setCommandListener( this );
oCanvas = new OCanvas( this );
}
public void startApp() throws MIDletStateChangeException {
running = true;
display.setCurrent( form );
}
public void pauseApp() {
running = false;
}
public void exitCanvas(int status) {
debug( "exitCanvas - status = " + status );
switch (status) {
case OCanvas.USER_EXIT:
timeItem.setText( "Aborted" );
resultItem.setText( "Unknown" );
break;
case OCanvas.EXIT_DONE:
timeItem.setText( oCanvas.elapsed+"ms" );
resultItem.setText( String.valueOf( oCanvas.result ) );
break;
}
display.setCurrent( form );
}
public void destroyApp(boolean unconditional)
throws MIDletStateChangeException {
oCanvas = null;
display.setCurrent ( null );
display = null;
}
public void commandAction(Command c, Displayable d) {
if ( c == cmdExit ) {
oCanvas = null;
display.setCurrent ( null );
display = null;
notifyDestroyed();
}
else {
running = true;
display.setCurrent( oCanvas );
oCanvas.start();
}
}
public static final void debug( String s ) {
if (debug) System.out.println( s );
}
}
Second, the OCanvas class that does most of the work in this example...
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import java.util.Random;
public class OCanvas extends Canvas implements Runnable {
public static final int USER_EXIT = 1;
public static final int EXIT_DONE = 2;
public static final int LOOP_COUNT = 100;
public static final int DRAW_COUNT = 16;
public static final int NUMBER_COUNT = 64;
public static final int DIVISOR_COUNT = 8;
public static final int WAIT_TIME = 50;
public static final int COLOR_BG = 0x00FFFFFF;
public static final int COLOR_FG = 0x00000000;
public long elapsed = 0l;
public int exitStatus;
public int result;
private Thread animationThread;
private OptimizeMe midlet;
private boolean finished;
private long started;
private long frameStarted;
private long frameTime;
private int[] numbers;
private int loopCounter;
private Random random = new Random( System.currentTimeMillis() );
public OCanvas( OptimizeMe _o ) {
midlet = _o;
numbers = new int[ NUMBER_COUNT ];
for ( int i = 0 ; i < numbers.length ; i++ ) {
numbers = i+1;
}
}
public synchronized void start() {
started = frameStarted = System.currentTimeMillis();
loopCounter = result = 0;
finished = false;
exitStatus = EXIT_DONE;
animationThread = new Thread( this );
animationThread.start();
}
public void run() {
Thread currentThread = Thread.currentThread();
try {
while ( animationThread == currentThread && midlet.running
&& !finished ) {
frameTime = System.currentTimeMillis() - frameStarted;
frameStarted = System.currentTimeMillis();
result += work( numbers );
repaint();
synchronized(this) {
wait( WAIT_TIME );
}
loopCounter++;
finished = ( loopCounter > LOOP_COUNT );
}
}
catch ( InterruptedException ie ) {
OptimizeMe.debug( "interrupted" );
}
elapsed = System.currentTimeMillis() - started;
midlet.exitCanvas( exitStatus );
}
public void paint(Graphics g) {
g.setColor( COLOR_BG );
g.fillRect( 0, 0, getWidth(), getHeight() );
g.setColor( COLOR_FG );
g.setFont( Font.getFont( Font.FACE_PROPORTIONAL,
Font.STYLE_BOLD | Font.STYLE_ITALIC, Font.SIZE_SMALL ) );
for ( int i = 0 ; i < DRAW_COUNT ; i ++ ) {
g.drawString( frameTime + " ms per frame",
getRandom( getWidth() ),
getRandom( getHeight() ),
Graphics.TOP | Graphics.HCENTER );
}
}
private int divisor;
private int r;
public synchronized int work( int[] n ) {
r = 0;
for ( int j = 0 ; j < DIVISOR_COUNT ; j++ ) {
for ( int i = 0 ; i < n.length ; i++ ) {
divisor = getDivisor(j);
r += workMore( n, i, divisor );
}
}
return r;
}
private int a;
public synchronized int getDivisor( int n ) {
if ( n == 0 ) return 1;
a = 1;
for ( int i = 0 ; i < n ; i++ ) {
a *= 2;
}
return a;
}
public synchronized int workMore( int[] n, int _i, int _d ) {
return n[_i] * n[_i] / _d + n[_i];
}
public void keyReleased(int keyCode) {
if ( System.currentTimeMillis() - started > 1000l ) {
exitStatus = USER_EXIT;
midlet.running = false;
}
}
private int getRandom( int bound )
{ // return a random, positive integer less than bound
return Math.abs( random.nextInt() % bound );
}
}
这个程序是一个模拟一个简单游戏循环的MIDlet：
*work 执行
*draw 绘制
*poll for user input 等待用户输入
*repeat 重复
对于快速游戏，这个循环一定要尽可能的紧凑和快速。我们的循环持续一个有限的次数（LOOP_COUNT=100）,并且用系统timer来计
算整个作业花费了多少毫秒，我们就可以测量并改善它的性能。时间和执行的结果会显示在一个简单的窗口上。用Start命令来开启测
试。按任意键会提前退出循环，退出按钮用来结束程序。-
在大多数游戏里面，主游戏循环中的作业会更新整个游戏状态-----移动所有的角色，检测并处理冲突，更新分数，等等。在这个例
子里面，我们并没有做什么特别有用的事。程序仅仅是在一个数组之间做一些算数运算，然后
把这些结果加起来。
run（）函数计算了每次循环所花费的时间。每一帧，OCanvas.paint（）方法都在屏幕上的16个随机的地方显示这个数。一般的，
你可以用这个方法在你的游戏里面画出你的图像元素，我们的代码在该过程中作了一些有用的摹写。
不管这些代码看起来有多么的无意义，它给了我们足够的机会去优化它的性能。
******************第二页
哪里去优化 -- 90/10规则
在苛求性能的游戏里面，有90%的时间是在执行其中%10的代码。我们的优化努力就应该针对这10%的代码。我们用一个Profier来定位
这 10%. 要运行J2ME无线开发包中的profier工具,选择edit菜单下的preferences选项. 这将会显示preferences窗口.选择
Monitoring这一栏,将"Enable Profiling"悬赏，然后点ok按钮。什么也没有出现。这是对的，在Profier窗口显示之前，我们需要
在模拟器中运行我们的程序然后退出。现在就做.
图1显示了如何打开Profiler工具。
我的模拟器（运行在Windows XP下，Inter P4 2.4GHz的CPU）报告我100次这个循环用了6,407毫秒，或者说6又1/2秒。这个程序报
告说62或者63毫秒每帧。在硬件(一个 motorola的i85s)上运行会慢得多。 一帧的时间大约是500毫秒，整个循环用了52460毫秒。
在本文这一课中，我们将试着改善这个数据。
当你退出这个程序时，profiler窗口就会出现，然后你会看见一个文件夹浏览器中有一些东西，在左边的面板上会有一个熟悉的树形
部件。方法间的联系会在这个结构列表中显示。每一个文件夹是一个方法，打开一个文件夹会显示它所调用过的方法。在该树中选择一
个方法会显示那个方法的profiling信息并在右边的面板显示所有被它调用过的方法。注意在每一个元素旁边显示了一个百分数。这就
是该方法在整个执行过程中所占的执行时间的百分比。我们必须翻遍这棵树，来寻找时间都到哪里去了，并对占用百分比最高的方法进
行优化，如果可能的话。
图2 -- Profiler程序调用的图
对这个profiler，有几点需要说明。首先你的百分比多半会和我的不一样，但是他们的比例会比较相似--总是在最大的数之后。我的
数据在被次运行的时候都会改变。为了保持情况一致，你可能希望关掉所有的后台程序，像Email客户端，并在你测试的时候保持你正
在进行的任务最少。还有，不要在用profiler之前混淆（obfuscate）你的代码，不然你的方法会被神秘的标示为b或者a或者ff。最
后profiler不会因为你运行模拟器的设备的差别而改变，它和硬件是完全独立的。
打开最高百分比的那个文件夹，我们看到有66.8%的时间在执行一个被称为
"com.sun.kvem.midp.lcdui.EmulEventHandler$EventLoop.run"的方法，这个对我们并没有什么帮助。用类似的方法，再往下寻
找更深层次的方法，持续下去，你就会找到一个大的百分比停留在serviceRepaints()上,最后到了我们的 OCanvas.paint()方法.另
外有30%的时间在OCanvas.run()方法里.这两个方法都在我们的主程序循环中,这并不奇怪.我们不会在我们的MIDlet类中花任何时间
做优化,同样地我们不会对游戏的主循环外的任何代码做优化.
在我们的例子程序中的百分比的划分在真实的游戏中并不是完全的没有特性. 你多半会在一个真实的视觉游戏中发现这个大的执行时
间的比例是在paint()方法中. 相比于非图形化程序,图形化程序总是要花很长的时间. 不幸的是,我们的图形程序已经被写在了J2ME
API这一层下,对于改善它们的性能,我们没有多少可以做的.我们可以做的是在用哪个和如何用它们之间做出聪明的决定.
高级vs低级优化
我们在该文章随后的地方会看到一些低级代码优化的技术.你会看见它们很容易被嵌入到现有代码中,并且在改善性能的同时相应的降
低其可读性. 在我们使用那些技术之前,最好还是继续在我们的代码和算法的设计上下功夫.这是高级优化.
Michael Abrash,"Quake"的一位开发者,一次写道,"the best optimizer is between your ears"(最好的游戏器就在你的两耳之
间).这有不只一种方法而且如果如果实现花更多的时间来思考正确的做事的方式,你会得到极大的回报. 使用正确的算法所带来的性能
提升,会比用低级优化技术在普通算法上作优化得到的提升大很多. 你用低级技术可能会得到几点百分比的提升,但是请首先从最上层
开始并且使用你的大脑(你可以在你的两耳之间找到它).
现在让我们来看一看我们在paint()方法中作了什么.每次在屏幕上打印消息"n ms per frame"时,我们调用了
Graphics.drawString() 16次. 我们不知道drawString的任何内部作业,但是我们知道它用掉了大量时间,所以让我们试试其它的方
式.让我们直接将这个字符串画到一个图片实例上, 然后再画16次这个图片.
public void paint(Graphics g) {
g.setColor( COLOR_BG );
g.fillRect( 0, 0, getWidth(), getHeight() );
Font font = Font.getFont( Font.FACE_PROPORTIONAL,
Font.STYLE_BOLD | Font.STYLE_ITALIC,
Font.SIZE_SMALL );
String msMessage = frameTime + "ms per frame";
Image stringImage =
Image.createImage( font.stringWidth( msMessage ),
font.getBaselinePosition() );
Graphics imageGraphics = stringImage.getGraphics();
imageGraphics.setColor( COLOR_BG );
imageGraphics.fillRect( 0, 0, stringImage.getWidth(),
stringImage.getHeight() );
imageGraphics.setColor( COLOR_FG );
imageGraphics.setFont( font );
imageGraphics.drawString( msMessage, 0, 0,
Graphics.TOP | Graphics.LEFT );
for ( int i = 0 ; i < DRAW_COUNT ; i ++ ) {
g.drawImage( stringImage, getRandom( getWidth() ),
getRandom( getHeight() ),
Graphics.VCENTER | Graphics.HCENTER );
}
}
当我们运行这个版本的软件时,我们看到我们的paint()方法占用的时间百分比减少了一点点.往里看,我们看到drawString()方法只被
调用了101次,而且现在是敌人啊我Image方法执的次数最多，被调用了1616次。虽然我们做了更多的工作，，但是程序运行得快了一点
，因为我们所用的graphics调用要快一点。
你或许发现了吧一个字符串画到一个图片上会影响显示，因为J2MEbing不支持图片的透明，所以大量的背景被重写了。这是一个
weruhe优化可能导致你重新审核程序需求的例子。如果你真的需要与文字重合，你可能被迫要用更少的时间来处理。
这个代码或许好了一点点，但是它仍然有很大的可改进空间。让我们来看一看我们的第一个低级优化技术。
第三页
循环之外？
循环多少次，在for()内部的代码就会执行多少次。要改善性能，那么，我们想要尽可能的把循环中的代码移动到循环外。我们可以在
profiler中看到paint()被调用了101次，并且在它之中的循环又循环了16次。在这两个循环中有哪些我们可以移出来呢？让我们从他
们的定义说明开始，每当调用paint()时,我们声明了一个字体，一个字符串，一个图片对象和一个图形对象.我们将要把它们移出到该
类的最前面.
public static final Font font =
Font.getFont( Font.FACE_PROPORTIONAL,
Font.STYLE_BOLD | Font.STYLE_ITALIC,
Font.SIZE_SMALL);
public static final int graphicAnchor =
Graphics.VCENTER | Graphics.HCENTER;
public static final int textAnchor =
Graphics.TOP | Graphics.LEFT;
private static final String MESSAGE = " ms per frame";
private String msMessage = "000" + MESSAGE;
private Image stringImage;
private Graphics imageGraphics;
private long oldFrameTime;
你会发现,我把Font对象变成了一个公共的常量.这一点在你的程序中通常是有用的,你可以把你所要用到的字体声明都集中到一个地方
.我发现anchor也一样,所以我也把文本和图像坐标放到了一起.对这些的预处理,保持了这些运算--虽然不怎么重要--在循环之外了.
我把MESSAGE也变成了一个常量.那是因为Java喜欢到处创建字符串对象.字符串如果没有被控制,它们可能导致大量的内存消耗.不要
把它们留给自动回收,否则你很可能会遇到内存泄露,那最终会影响你的程序性能,特别是当垃圾回收器被调用得过于频繁时.字符串创
造垃圾,而垃圾不好.用一个字符串常量减少了这类问题.稍后我们会看到如何运用一个StringBuffer来完全的阻止字符串滥用带来的
内存流失.
既然我们把那些变成了实例变量,我们需要在构造函数里面添加这些代码:
stringImage = Image.createImage( font.stringWidth( msMessage ),
font.getBaselinePosition() );
imageGraphics = stringImage.getGraphics();
imageGraphics.setFont( font );
另一个很酷的对于图形对象的大写字符的事是,我们可以设置一次字体然后就可以忘掉它了,不用每次在循环中都设置一次. 每次我们
还需要用fillRect()擦去图片对象. 热情的编码者可能会发现这里有一个机会从同一个图片创建两个图形对象,然后为fillRect()的
调用预设其中一个的颜色为COLOR_BG,并为 drawString()的调用预设另一个的颜色为COLOR_FG.不幸地,对同一个图片的多次调用
getGraphics()没有被定义,在不同的平台上不一样,于是你的技巧可能在Motorola上有效但在NOKIA上不行.如果不确定,就不做.
还有另一种改进我们的paint()的方法.再次使用我们的大脑我们认识到,如果从上次调用以来frameTime的值改变了,那么我们只需要
重画这个字符串.那是我们的新变量oldFrameTime到来的地方,下面是新的方法:
public void paint(Graphics g) {
g.setColor( COLOR_BG );
g.fillRect( 0, 0, getWidth(), getHeight() );
if ( frameTime != oldFrameTime ) {
msMessage = frameTime + MESSAGE;
imageGraphics.setColor( COLOR_BG );
imageGraphics.fillRect( 0, 0, stringImage.getWidth(),
stringImage.getHeight() );
imageGraphics.setColor( COLOR_FG );
imageGraphics.drawString( msMessage, 0, 0, textAnchor );
}
for ( int i = 0 ; i < DRAW_COUNT ; i ++ ) {
g.drawImage( stringImage, getRandom( getWidth() ),
getRandom( getHeight() ), graphicAnchor );
}
oldFrameTime = frameTime;
}
现在Profiler显示OCanvas的paint总共所花费的时间百分比已经降低为42.01%了.对比结果frameTime在 paint()中的调用,对
drawString()和fillRect()的调用次数已经从101变为69了.那时一个不错的节约,没有多少可以做的了,现在是该认真的时候了.你优
化得越多,它就变得越困难.现在我们要去挖掉最后几块循环中的代码.我们现在正在剃去非常小的百分比或者说百分比的碎片了,但是
我们比较幸运,他们加起来还是比较可观的.
让我们从一些简单的开始.让我们调用那些函数一次并且把结果暂存在循环之外,而不是每次都调用getHeight()和getWidth(). 下一
步,我们将停止使用字符串并手动使用StringBuffer来做所有事.依靠在Graphics.setClip()的调用中限制绘画区域,我们将剃掉一些
对drawImage()的调用.最后,我们将避免在循环中对java.util.Random.nextInt()的调用.
这是些新的变量...
private static final String MESSAGE = "ms per frame:";
private int iw, ih, dw, dh;
private StringBuffer stringBuffer;
private int messageLength;
private int stringLength;
private char[] stringChars;
private static final int RANDOMCOUNT = 256;
private int[] randomNumbersX = new int[RANDOMCOUNT];
private int[] randomNumbersY = new int[RANDOMCOUNT];
private int ri;
...这里是我们构造函数里的新代码:
iw = stringImage.getWidth();
ih = stringImage.getHeight();
dw = getWidth();
dh = getHeight();
for ( int i = 0 ; i < RANDOMCOUNT ; i++ ) {
randomNumbersX = getRandom( dw );
randomNumbersY = getRandom( dh );
}
ri = 0;
stringBuffer = new StringBuffer( MESSAGE+"000" );
messageLength = MESSAGE.length();
stringLength = stringBuffer.length();
stringChars = new char[stringLength];
stringBuffer.getChars( 0, stringLength, stringChars, 0 );
你现在可以看到我们在预处理显示(Display)和图片(Image).我们也在暂存512次getRandom()的调用的结果,有了StringBuffer也不
再需要msMessage这个字符串.当然,肉依然在paint()方法中:
public void paint(Graphics g) {
g.setColor( COLOR_BG );
g.fillRect( 0, 0, dw, dh );
if ( frameTime != oldFrameTime ) {
stringBuffer.delete( messageLength, stringLength );
stringBuffer.append( (int)frameTime );
stringLength = stringBuffer.length();
stringBuffer.getChars( messageLength,
stringLength,
stringChars,
messageLength );
iw = font.charsWidth( stringChars, 0, stringLength );
imageGraphics.setColor( COLOR_BG );
imageGraphics.fillRect( 0, 0, iw, ih );
imageGraphics.setColor( COLOR_FG );
imageGraphics.drawChars( stringChars, 0,
stringLength, 0, 0, textAnchor );
}
for ( int i = 0 ; i < DRAW_COUNT ; i ++ ) {
g.setClip( randomNumbersX[ri], randomNumbersY[ri], iw, ih );
g.drawImage( stringImage, randomNumbersX[ri],
randomNumbersY[ri], textAnchor );
ri = (ri+1) % RANDOMCOUNT;
}
oldFrameTime = frameTime;
} |
|
发表于 2007-10-21 18:49:00