J2ME游戏优化秘密

51testing

本文章描述了代码优化在为移动设备写运行起来速度快的游戏中扮演的角色。我会用例子说明如何、什么时候和为什么要优化你的代

码，来榨干兼容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;
}
我们现在正在用一个StringBuffer来写我们的消息中的字符.相比于在开头插入一个字符,在StringBuffer的后面添加要容易得多,所

以我把字符显示的顺序调换了,现在frameTime在消息的最后了,比如:"ms per frame:120".我们每次重写最后的几位frameTime字符

,保持消息的一部分不变. 像这样明白的运用StringBuffer会节约paint()方法内系统从创建到销毁字符串的时间.它是额外的工作,但

值得做.注意,我在把 frameTimer强制转换为一个整数.我发现用append(long) 导致了一个内存泄露.我不知道为什么,但这是一个为

什么你需要用软件注意事情的例子.
我们用font.charsWidth()来计算消息图片的宽度,以让我们可以画得最少.我们使用均衡字符,来使"ms per frame:1"的宽度比这绘

制它图片小,我们用Graphics.setClip(),所以我们就不需要画更多的. 这同样意味着我们只需要填充一个足够遮掩我们需要的区域那

么大的一个矩形.我们希望绘图省下的时间比调用font.charWidth()花去的时间多.
在这里这可能不会带来多大区别,但它确实是一个绘制玩家的分数到屏幕上的不错的技术.那种情况下,在绘制0分和150,000,000分之

间有着巨大的差别. 这多少是因为font.getBaselinePosition()的不正确的返回值,这个值好像和font.getHeight()的返回值一样,

啊! (叹气)
最后,我们刚刚搞定了我们的两个数组中预先计算的"随机"数,这节约了我们产生随机数的一些调用.注意用取模运算来实现一个循环数

组的用法.注意我们用同一个TextAnchor绘制图片和字符串,所以现在setClip()工作正常.
我们已经在一个灰色地带，怀着对这个版本的代码产生的数据。Profiler高速我们这个代码比没有这些改变的代码在paint()方法里

多花了大概7%多一点的时间。对font.charsWidth()的调用可能是个原因，它占了4.6%。（这并不多，但它可以被减少。注意我们每

次都会获取 MESSAGE字符串的宽度。我们可以简单的在循环体之间计算它，并简单的把它加到frameTime的宽度上。）同样，新的对

setClip()的调用被标识为0.85%，而且看起来大大的增加了drawImage所占用的时间百分比（从27.58%到33.94%）。
到这一点了，看起来所有额外的代码肯定会使执行慢下来，但是程序产生的书记和这个假设矛盾了。在模拟器上的数据上下波动，看起

来好像没有长时间的测试，是不能下决定了，但是我的i85s报告说额外的代码比不加要快一点点，在没有对setClip()或者

charsWidth()时数据是 37130毫秒，而两个都有的时候是36540。我做了我的耐心所能忍受的那么多次，结果都一致。这使执行环境

差异这一点的影响突出起来。一旦你到了一个你不能确定会不会有进展的地方，你可能会被迫继续所有在硬件上的测试，这需要大量的

对JAR文件的安装和卸载。
看起来我们已经从我们的图形程序段压榨出了大量的性能。现在是对我们的work()方法进行同样的高级和低级优化的时候了。让我们

来回顾一下那个方法：
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;
}
每次在run()中的循环，我们都传递一个数组参数。在work()中的循环外计算了我们的除数，然后调用workMore()来做这个除法。这

里所有事都错了，你可能也发现了。因为一开始，程序员已经把getDivisor()的调用放到了循环内。如果j的值在循环内部没有改变，

那么除数是不变的，真的属于内循环外面。
但是让我们多想一想，这个调用本身就是完全不必要的。下面的代码做了同样的事情...
public synchronized int work( int[] n ) {
r = 0;
divisor = 1;
for ( int j = 0 ; j < DIVISOR_COUNT ; j++ ) {
for ( int i = 0 ; i < n.length ; i++ ) {
r += workMore( n, i, divisor );
}
divisor *= 2;
}
return r;
}
...没有对getDivisor()的调用。现在我们的profiler告诉我们run()方法花了23.72%的时间，对应于我们做这些改进以前的38.78%

。请总是在使用低级优化技术之前首先使用你的大脑来优化。接下来，让我们看一看它们中的一些技术。

第四页
低级优化
所有的程序员都对子程序和函数---为了避免在多个地方重复，把程序中共用的代码从应用程序中提出来--的概念很熟悉。不幸地，这

个通常的 “好”变成习惯会影响性能，因为方法的调用会带来一定量的开销。最简单的减少对一个方法的调用所耗费的时间的方法是

，仔细地挑选他们的声明修饰语。我们的程序员已经很小心了，已经把他的work()和workMore()方法同步了，以防万一其它的线程同

时调用了它们。这很不错，但是如果我们对性能很看重，我们常常要做出一些牺牲，今天我们的牺牲是安全的。
好了，我们知道不会有其它人会调用这些方法，那么我们可以不怎么担心地把他们同步起来。还有什么其它的可以做？让我们来看一看

这个方法类型的列表：
*synchronized 该方法是最慢的，因为需要获取一个对象锁
*interface 该方法是次慢的
*instance 这个方法居中
*final 该方法比较快
*static 该方法是最快的
所以我们不应该让所有的都是synchronized，而且看起来我们甚至可以把work()和workMore标示为final static方法。这样做会减

少1%模拟器中run()方法所花的时间。
另一个影响方法调用性能的因素是，传递给该方法的参数的个数。我们调用了workMore()51712次，每次都传递一个整形数组和两个

整形变量给这个参数并返回一个整形变量。在这个有点微不足道的例子中，可以很容易地把workMore()方法拆散到work()的方法体中

来完全地避免这个调用。在真实世界中，这是个很难的决定，特别是当这意味着需要把代码复制到你程序周围的时候。在profiler上

测试一下来看和没做这一步之前到底有多大的差别。如果你不能把所有的方法去掉，试着减少你传递的参数的个数。参数越多，开销就

越大。
public final static int work( int[] n ) {
divisor = 1;
r = 0;
for ( int j = 0 ; j < DIVISOR_COUNT ; j++ ) {
for ( int i = 0 ; i < n.length ; i++ ) {
r += n * n / divisor + n;
}
divisor *= 2;
}
return r;
}
哇哦！去掉workMore()的调用把run中的时间开销砍到了9.96%。现在开始，一路上都会上升。让我们来看一看两个最基本的优化技术

---降低强度（strength reduction）和解开循环。
降低强度就是将一个慢一点的操作用一个相对快一点的完成同样的工作的去替换。最普通的就是使用位移运算符，它和对2的乘除运算

是相等的。比如说，x>>2和x/4是相等的（2的2次幂），x<<10和x*1024是相等的（2的10次幂）。一个令人惊讶的巧合，我们的除数

总是2的幂方（是不是很幸运！），所以我们可以用位移来替换那些除法。
解开循环减少了代码控制流的开销，但在循环中做更多的操作，少执行几次循环，或者完全把循环去掉。由于我们的DIVISOR——

COUNT只是8，解开我们的循环变得简单起来。
public final static int work( int[] n ) {
r = 0;
for ( int i = 0 ; i < n.length ; i++ ) { r += n * n + n; }
for ( int i = 0 ; i < n.length ; i++ ) { r += (n * n >> 1) + n; }
for ( int i = 0 ; i < n.length ; i++ ) { r += (n * n >> 2) + n; }
for ( int i = 0 ; i < n.length ; i++ ) { r += (n * n >> 3) + n; }
for ( int i = 0 ; i < n.length ; i++ ) { r += (n * n >> 4) + n; }
for ( int i = 0 ; i < n.length ; i++ ) { r += (n * n >> 5) + n; }
for ( int i = 0 ; i < n.length ; i++ ) { r += (n * n >> 6) + n; }
for ( int i = 0 ; i < n.length ; i++ ) { r += (n * n >> 7) + n; }
return r;
}
有两个重点，第一，你会发现解开我们的循环需要我们复制一些代码。这是你在J2ME中想要的最后一件事，程序员们总是在与JAR作战

，但要记得 JARing（打包）过程包括了压缩，而压缩工作对重复的代码最有效，所以上面的代码可能不会像你所想的那样对你的jar

文件大小产生大的影响。再者，这都是代价交换。你的代码可以很小，很快，易读，任意选择其中的两个。第二点是位移操作符合乘除

运算的优先级不一样，所以你常常需要在表达式周围放置括号，而乘除运算符则不需要。
解开循环和使用位移操作符提升了1%多一点，不算坏。现在让我们把注意力集中到数组访问上。数组在C中是快速的数据结构，但因为

那个原因他们也很危险---如果你的代码访问了超过数组尾部的地址，那么你就重写了你不应该访问的内存区域，而且结果通常都是可

怕的。
相比之下，java是一个很安全的语言---像那样执行到数组尾部以外会简单地抛出一个 ArrayIndexOutOfBoundsException(一个数组

地址越界异常)。每次访问数组的时候系统都检查数组的下标是否有效，这使得数组的访问比C中要慢。再者，对于java内部对于数组

的处理我们没有什么可以做的，但是我们可以在它周围作一些聪明的决定。在上面的代码中，举例来说，我们访问了n24次。我们

可以通过把n的值存储于一个变量来省略掉很多那样的数组访问。稍微高级一点的想法同样揭示了我们可以用聪明的多的方式重新

安排他们，像这样...
private static int divisor;
private static int r;
private static int ni;
public final static int work( int[] n ) {
r = 0;
for ( int i = 0 ; i < n.length ; i++ ) {
ni = n;
r += ni * ni + ni;
r += (ni * ni >> 1) + ni;
r += (ni * ni >> 2) + ni;
r += (ni * ni >> 3) + ni;
r += (ni * ni >> 4) + ni;
r += (ni * ni >> 5) + ni;
r += (ni * ni >> 6) + ni;
r += (ni * ni >> 7) + ni;
}
return r;
}
...把run()中耗费的时间减少到了6.18%，一点也不坏。在我们继续之前，让我多说一点关于数组的事。一个稍微高级的优化（也就是

“thought”）可能揭示了数组可能不是这里必要的正确的数据结构。想想一个链表或者一些其他的结构，如果他们将提升性能。第二

点，如果你将要使用一个数组而且也需要复制它的内容到另一个数组，请总是使用System.arraycopy()。完成同样的工作，它会比自

己写的函数要快一点。最后，数组的性能比java.util.Vector对象的性能要好一点。如果你需要一种Vectors提供的功能，想想自己

写代码并测试一下，确保你的代码要快一点。
好了，我们真的把优化的事情做完了。我们刚刚介绍了暂存数组变量和该变量的平房的另一对变量。你可能在想为什么那些变量在方法

体的声明之外就被声明了。他们在循环外是因为每次定义一个整形数都有一点开销，而且我们需要保持他们在循环外也有效，对么？错

！
什么都不假设，我们确实为整形变量的声明节约了时间，但是如果那些变量在方法内部的定义为局部的，代码实际上可能会更慢。这是

因为局部变量表现得更好，因为JVM解释一个在方法外声明的变量会花更长的时间。所以让我们把他们变为局部变量。
最后，我们可以微微改变一下for()循环。计算机处理和零比较比处理和其他的非零数比较要快。那意味着我们可以改变我们的循环的

顺序并像这样重写方法，我们就可以和零比较：
public final static int work( int[] n ) {
int r = 0;
int ni;
int nis;
int i;
for ( i = n.length ; --i >= 0 ; ) {
ni = n;
nis = ni * ni;
r += nis + ni;
r += (nis >> 1) + ni;
r += (nis >> 2) + ni;
r += (nis >> 3) + ni;
r += (nis >> 4) + ni;
r += (nis >> 5) + ni;
r += (nis >> 6) + ni;
r += (nis >> 7) + ni;
}
return r;
}
就是它了！这个代码可能会快一点，但是 profiler的结果不是那么的明显，清楚地是这个方法变得难懂了。或许这里还有更多可改进

的空间，但是让我们再看一下paint()方法，看看我们所学的里面有没有什么在这儿可以介绍的。
记住我们所学的关于局部变量的么？如果你被迫要用一个实例变量，而且你在一个方法中引用了那个变量多次，它可能值得你创建一个

局部变量来让 JVM只处理那个引用一次。你将引入一个声明和一个赋值，这会让程序变慢，但根据经验，如果一个变量被引用了超过

两次，我们将会使用这个技术。
我们同样可以在我们的paint()方法中运用降低强度，用一个循环移位计数器来代替取模运算符。这只有在我们的随机数暂存数组的长

度是2的倍数（令人惊讶地）的时候是可能的。最后，我们可以把我们的比较运算改成总是和零比较。这里是新的改进过的paint()方

法：
public void paint(Graphics g) {
StringBuffer sb = stringBuffer;
Graphics ig = imageGraphics;
char[] sc = stringChars;
int sl;
int ml = messageLength;
int ril = ri;
int iw = 0;
g.setColor( COLOR_BG );
g.fillRect( 0, 0, dw, dh );
if ( frameTime - oldFrameTime != 0 ) {
sb.delete( ml, stringLength );
sb.append( (int)frameTime );
sl = stringLength = sb.length();
sb.getChars( ml, sl, sc, ml );
iw = font.charsWidth( sc, 0, sl );
ig.setColor( COLOR_BG );
ig.fillRect( 0, 0, iw, ih );
ig.setColor( COLOR_FG );
ig.drawChars( sc, 0, sl, 0, 0, textAnchor );
}
for ( int i = DRAW_COUNT ; --i >=0 ; ) {
g.setClip( randomNumbersX[ril], randomNumbersY[ril], iw, ih );
g.drawImage( stringImage, randomNumbersX[ril],
randomNumbersY[ril], textAnchor );
ril++;
ril &= 255;
}
ri = ril;
oldFrameTime = frameTime;
}
此外，怀着对profiler结果的敬意，我们已经在路的尽头了。这些改变并不影响图形函数被调用的次数，所以最好情况下这个差别也

会很小。但是当我们把所有对我们的work()方法的改变组合起来并且装在新的JAR到设备上时，这个差别是很大的。我的motorola

i85s现在在14030毫秒内完成了测试----快了两倍多！
这个代码还有最后一点需要改变。我把它放到最后是因为它没有书写得特别好，并且我的经验是它的表现在不同的实现间不一样。看着

OCanvas中的start()和run()方法，你可以看到我已经用了一个单独的动画线程。这是Java中处理动画的传统方法。在游戏中用这个

技术的一个问题是，每当重复循环时，我们被迫等待系统事件，比如说按键或者一个命令被传输了。毕竟我们在一个同步块中调用

wait()方法等待。这是艰辛的优化代码。毕竟我们的困难工作优化了其他所有事情，但我们在最激烈的时候实际上什么正确的事情也

没能做。更坏的是，为WAIT_TIME得到一个好的数据并不简单。如果我们 wait()太长，游戏就变慢了。如果我们没有wait()足够的时

间,按键可能被错过然后游戏停止了对用户输入的响应。
J2ME提供了一个这个问题的解决方案，用Display.callSerially()方法。API声明callSerially (Runnable r)"导致了在repaint

周期完成不久之后，为了和事件流同步，Runnable对象r让其run()被推迟调用“[原文是："causes the Runnable object r to

have its run() method called later, serialized with the event stream, soon after completion of the repaint

cycle"]。通过使用callSerially()，我们可以完全的取消对wait()的调用。系统会保证我们的work()和paint()方法和用户输入程

序同步地被调用，那样游戏就会保持可响应性。这里是一些新的方法...
public void start() {
started = frameStarted = System.currentTimeMillis();
loopCounter = result = 0;
finished = false;
exitStatus = EXIT_DONE;
run();
}
public void run() {
frameTime = System.currentTimeMillis() - frameStarted;
frameStarted = System.currentTimeMillis();
if ( midlet.running && !finished ) {
result += work( numbers );
repaint();
display.callSerially(this);
loopCounter++;
finished = ( loopCounter > LOOP_COUNT );
}
else {
elapsed = System.currentTimeMillis() - started;
midlet.exitCanvas( exitStatus );
}
}
...此外我们还需要声明并得到一个Display的句柄：
Display display = Display.getDisplay( midlet );
没有了对wait()的调用，现在我的i85s在10180毫秒内完成了代码的运行---差不多省了40%。你可能希望更大的性能提升，在得知我

们刚刚消除了100次50毫秒的对wait()的调用，但是请记住这个技术也是关于用户输入响应的。
再次，让我强调一下这个动画方法需要小心使用。在使他在NOKIA上工作的时候我遇到的麻烦，而且他们所有的示例代码（即使是游戏

代码）都使用了wait()技术。即使是在Motorola上，我在动画Canvas上添加了命令对象的时候，使用callSerially()的时候也遇到

了问题。在你在家尝试这个之前请小心测试。

第五页

其他的技术
一个我不能在我的示例程序中包含的技术是，最佳的使用switch()。Switch非常普遍的用于实现有限状态自动机（Finite State

Machines），在为非玩家角色的行为控制做人工智能的代码时。在你使用switch的时候，像这样写代码是一个好的编程习惯：
public static final int STATE_RUNNING = 1000;
public static final int STATE_JUMPING = 2000;
public static final int STATE_SHOOTING = 3000;
switch ( n ) {
case STATE_RUNNING:
doRun();
case STATE_JUMPING:
doJump();
case STATE_SHOOTING:
doShoot();
}
这没有什么不对的，这些变量很不错而且离得很远，万一我们想要加一个在RUNNING和JUMPING之间的变量，像 STATE_DUCKING =

2500。但是显然switch选项可以被编译为一个两字节的代码，如果所用的整数紧靠在一起那么这个两字节的代码会更快，所以这会更

好：
public static final int STATE_RUNNING = 1;
public static final int STATE_JUMPING = 2;
public static final int STATE_SHOOTING = 3;
在使用定点数学库（Fixed Point math library）的时候，有一些优化你可以做。首先，如果你除了一个相同的数很多次，你应该计

算出那个数的倒数然后把运算改变为执行一个乘法。乘法要比除法快一点。所以不是...
int fpP = FP.Div( fpX, fpD );
int fpQ = FP.Div( fpY, fpD );
int fpR = FP.Div( fpZ, fpD );
...你应该把它重新写成这样：
int fpID = FP.Div( 1, fpD );
int fpP = FP.Mul( fpX, fpID );
int fpQ = FP.Mul( fpY, fpID );
int fpR = FP.Mul( fpZ, fpID );
如果你在每一帧要做数百次的除法，这会有所帮助。第二点，不要默认你的FP数学函数库不错。don't take your FP math library

for granted. 如果你有它的源代码，打开它然后看一下里面发生了什么。保证所有的方法都被声明为final static并看看有没有机

会优化它的代码。比如，你可能发现这个乘法方法需要把int强制转换为long然后再转换回来：
public static final int Mul (int x, int y) {
long z = (long) x * (long) y;
return ((int) (z >> 16));
}
那些转换要花时间。冲突检测使用边界圆球或者半球（bounding circles or spheres）包括将int的平方相加。那会产生一些大的

可能会溢出你的int数据类型的最大值的数字。要避免这个，你可以写下自己的返回一个long型数的平方函数：
public static final long Sqr (int x) {
long z = (long) x;
z *= z;
return (z >> 16);
}
这个优化的方法避免了两个转换。如果你要做大量的定点计算，你可能要考虑把所有的主游戏循环中的调用替换为long型的。那会节

约大量的方法调用和参数传递。你可能也发现当这个计算被手动写出的时候，你可以减少类型转换所需要的次数。如果你嵌套一些对你

的库的调用，这是尤其正确的。比如：
int fpA = FP.Mul( FP.toInt(5),
FP.Mul( FP.Div( 1 / fpB ),
FP.Mul( FP.Div( fpC, fpD ),
FP.toInt( 13 ) ) ) );
花一些时间Take the time来拆开这些像这样的嵌套调用，然后看你是否能减少类型转换的次数。另一个方式是避免到long类型的转

换，如果你知道涉及到的数字足够小以至于他们肯定不会导致溢出。
在高级优化上，你应该看一些游戏设计上的文章。大量的已知的游戏设计中问题，比如3D几何和碰撞检测已经被非常优雅和有效地解

决了。如果你找不到java源代码，你很可能会找到C源代码或者伪代码来转换。例如，边界检查是一个普通的技术，我们已经在paint

()方法中用到了。我们只需要清除帧到帧之间所改变的那部分屏幕，而不是每次都把整个屏幕清除。因为图形程序相对来说较慢，你

会发现这额外的管理的代价---需要明了屏幕上哪些部分需要被清除--值得付出。
一些手机制造商提供了一些私有的API来帮助程序员们处理一些J2ME表现出来的的限制，比如声音的欠缺，图片透明度的欠缺，等等。

例如， Motorola提供了一个浮点数学库来在芯片上做浮点运算。这个库比最快的定点数学库快很多，精度也高很多。使用这个函数会

完全破坏你代码的可移植性，当然，如果在许多不同的手机上运行不是关键，他们是一个可选项。
结论
*只优化需要的代码
*只在有价值的地方优化
*用profiler来找要优化的地方
*在具体的设备上profiler无能为力，在硬件上使用System timer
*在于用低级技术之前，总是先研究你的代码并且试着改进算法
*绘图是慢的，所以尽量节俭地使用图形调用
*在可以减少绘制区域的地方使用setClip()
*尽可能的把东西放到循环之外
*拼命地预先计算和暂存
*字符串带来垃圾，垃圾不好，所以使用StringBuffers来代替
*什么都不假设
*可能就使用static final方法，避免synchronized修饰符
*传递尽可能少的参数到经常调用的方法
*如果可能，完全地去掉函数调用
*解开循环
*对2的幂的乘除运算用位移运算代替
*你可以使用位运算符代替取模运算来实现循环
*试着用零来代替和其他数的比较
*数组访问比C要慢，所以暂存数组元素
*消去公共的子表达式
*局部变量要比引用变量快
*如果可以callSerially()就不要wait()
*在switch()中使用小的变量作选项
*检查定点数学库并且优化它
*拆开嵌套的FP调用来减少类型转换
*除法比乘法慢，所以用乘于倒数来代替除法
*用使用过和测试过的算法
*为了保护可移植性，小心地使用私有高性能API

下一步去哪里？
优化是魔法。任何的计算机的心脏都是CPU，java的心脏在虚拟CPU，JVM（java虚拟机）。要榨干虚拟机的每点性能，你需要了解大

量的表层以下的事情是如何工作的。特别地，你需要知道哪些事情JVM可以做得快，哪些慢。寻找有java里层工作的可靠信息的网站。

你不必要学习如何按字节来写程序，但是你懂得越多，就越容易跟上优化你的程序性能的新方式。
没有什么能够代替经验。你会及时地发现关于J2ME的性能特性和所开发的手机的你个人的秘密。即使你不能编出有独特特性的代码，

你可以用它设计你的下一个游戏。在开发我的游戏的时候，我发现调用5次drawImage()来分别绘制5个有25像素的图片要比调用它一

次来绘制一个五倍大小的图片慢得多。这个只是肯定会帮助我设计我的下一个游戏。
祝你好运，玩得开心！
资源：
1. J2ME's official web site contains the latest on what's happening on this front.
2. Like wireless games? Read the Wireless Gaming Review.
3. Discuss J2ME Game Development at j2me.org
4. A great site on many aspects of Java Optimization
5. Another great site on Optimization
6. Many articles on J2ME performance tuning
7. The amazing Graphics Programming Black Book by Michael Abrash
8. The Art of Computer Game Design by Chris Crawford