开发J2AVA ME 程序最需要关注的是内存的占用，开发性能高，适配多种机型的软件不是件容易的事情，我在国庆时间整理下我的开发思路写了这个类，给大家参考下


package com.gggeye.util;

import java.util.Hashtable;
import java.util.Stack;
import java.util.TimerTask;
import java.util.Vector;

import com.gggeye.demo.Logger;

 

 
 /**
  *  内存管理，工具类，主要是用于项目的内存控制，
  *  此类相对重要点，因为涉及到各个方面的内存回收
  *  此类除了提供一些常用的方法进行回收外，还还提供一个自动回收的机制，不过不建议采用，自动回收机制是是当
  *  空闲内存小于指定内存大小时候，释放内存，回收的时间是5秒回收一次<br/>
   */
public   class MemoryManager implements Runnable {
   
    /**
     * 释放内存，当内存小于addtionMemory时候，进行垃圾回收，主动回收
     * @param addtionMemory
     */
    public final static void release(long addtionMemory) {
        long freeMemory = Runtime.getRuntime().freeMemory();
        //如果空闲的内存小于指定的内存，则回收
        if(freeMemory<=addtionMemory){
            Logger.println("回收前的内存==>" +MemoryManager.freeMemoryKByte());
            System.gc();
            Logger.println("回收后的内存==>" +MemoryManager.freeMemoryKByte());
        }
    }
   
    /**
     * 释放指定缓存对象
     * @param addtionMemory
     * @param cache
     */
    public final static void release(long addtionMemory, Object cache){
        release(addtionMemory);
        if(cache != null){
            if(cache instanceof java.util.Hashtable){
                Hashtable i = (Hashtable)cache;
                i.clear();         
            }else if(cache instanceof java.util.Vector){
                Vector i = (Vector)cache;
                i.removeAllElements();
            }else if(cache instanceof java.util.Stack){
                Stack i = (Stack)cache;
                i.removeAllElements();
            }        
            cache = null;
            System.gc();
        }   
    }
   
    /**
     * 得到系统空闲内存，单位是k
     * @return 返回空闲内存的大小
     */
    public final static String freeMemoryKByte(){
        return freeMemoryByte()/1024 + "k";
    }
   
   
    public final static long  freeMemoryByte(){
        return Runtime.getRuntime().freeMemory();
    }
   
   
 

    private static MemoryManager instance ;
    private static TimerTask task;
    /**
     * 自动回收内存机制,此方法，应该在系统第一次调用的时候调用，如果重复调用则会抛出异常
     * @param time
     */
    public static void autoGC(long time) throws java.lang.RuntimeException{
        if(instance == null){
            instance  = new MemoryManager();
            task = TimerTaskManager.getInstace().create(instance, time);
        }else
            throw new RuntimeException("GC is starting...");
    }
   
    public static void colse(){
        if(instance != null) instance = null;
        if(task != null){
            task.cancel();
            task = null;
        }
       
    }

    /**
     * 实现对内存的自动化管理
     */
    public void run() {
        //小于12k内存的时候释放内存
        release(1200000);
         
    }

}

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

码，来榨干兼容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] = 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[i] = getRandom( dw );
  randomNumbersY[i] = 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[i] * n[i] / divisor + n[i];
      }
      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[i] * n[i]  + n[i]; }
  for ( int i = 0 ; i < n.length ; i++ ) { r +=  (n[i] * n[i] >> 1) + n[i]; }
  for ( int i = 0 ; i < n.length ; i++ ) { r +=  (n[i] * n[i] >> 2) + n[i]; }
  for ( int i = 0 ; i < n.length ; i++ ) { r +=  (n[i] * n[i] >> 3) + n[i]; }
  for ( int i = 0 ; i < n.length ; i++ ) { r +=  (n[i] * n[i] >> 4) + n[i]; }
  for ( int i = 0 ; i < n.length ; i++ ) { r +=  (n[i] * n[i] >> 5) + n[i]; }
  for ( int i = 0 ; i < n.length ; i++ ) { r +=  (n[i] * n[i] >> 6) + n[i]; }
  for ( int i = 0 ; i < n.length ; i++ ) { r +=  (n[i] * n[i] >> 7) + n[i]; }
  return r;
}
有两个重点，第一，你会发现解开我们的循环需要我们复制一些代码。这是你在J2ME中想要的最后一件事，程序员们总是在与JAR作战

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

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

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

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

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

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

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

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

安排他们，像这样...
  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[i];
      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[i];
      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
关于作者：
Mike Shivas has been playing video games since before the advent of the 8-bit home microcomputer. He has been

programming in Java since 1996, has consulted for MasterCard on wireless solutions and is the published

author of several J2ME video games. Readers may contact Mike at mailto:mshivas@hotmail.com?subject=FastCode.

 

        对 代码进行优化的最简单办法就是首先不要调用这些代码。这并不是说要删除这些代码，也许可以用其他办法来调用它们（后者事实减少对它的调用）。游戏的主循环 是游戏运行的最主要做的事情，应该更多地考虑是否可以不用或减少对属于这个区域内的代码的调用。在前一片文章中介绍了方法和内存评测工具的使用，但它们只 能帮助我们找出究竟是哪段代码降低了程序的运行速度，下面的内容是参考了其他资料整理出来的优化代码的方法。

 

    代码优化的技术大致分为两个主要方面：高级优化，从使用的整体算法和结构出发进行的优化；低级优化，集中于孤立的代码片断（通常为方法中的代码）的优化。下面分别讨论两方面的优化：

一，高级优化

1，  感觉到就是真实

对于电影来说，我们通过摄像头看到的都是完美的，而在拍摄现场我们看到的却是木头，泡沫和胶带。所以对于电影来说，感觉到就是真实。

游戏也一样，只需要处理游戏需要的东西。在游戏开发的各个方面这都是实用的。把精力集中在使游戏有趣和完美运行的问题上，始终只做需要做的而丢弃其他的部分。

2，  不要创建对象

减少对象创建的总数量和频率，结果能够大大地提高游戏的性能。还必须小心在不经意的情况下产生String对象。

例如:graphics.drawString( 0,0,”Score:” +score  );

这一句代码会在每次被调用的时候产生一个新的String对象，在这里就是每一桢画面显示时都会产生新的String对象。因此最好是只是在分数改变的时候才构造这个String。

3，  绘制屏幕

通常，在对游戏完成大量的优化工作以后，收获的将是一个大量时间耗费在屏幕绘图上的游戏。这是因为一个游戏的主要时耗大都集中在绘制图像的工作上（或其他的一些基本的绘图调用）。因此，如果一开始就可以避免绘制工作，那将是对游戏的很好的优化。

还有就是要减少屏幕绘制，循环检测屏幕图像是否在某个部分发生了改变，如果没有，就不要对那部分的屏幕进行更新。另一个方法就是增加绘制图像的尺寸来减少单独的绘制调用的次数。

4，  算法

最好的，也是使用最多的高级优化是对游戏的算法方面。

 

二，低级优化

1，  提前绘制复杂图像

我们已经知道，使用LCDUI绘制图像是很慢的，因此最好是能够避免这种绘制。其中的一个方法就是用一个预生成图像来减少复杂图像的绘制。进一步来讲，举例：将所有的游戏状态信息整合到一个面板中（得分，生命数，能量值等），然后对这些信息进行一次性同时更新。

2，  保持类和内存之间的平衡

产生新的类会增加JAR包文件的大小，因此应该尽量避免。有的时候增加了额外类的开销可能节省了额外的内存开销，这也是值得的。

3，  复杂值的预计算

节省运算的一个好方法就是对数值进行预运算，从而无需再调用大开销的计算方法。一个很好的例子就是：主窗口画布的高度和宽度就是很好的 缓存对象。例如：可以调用getHeight方法和getWidth方法一次，然后将它们的结果缓存起来，而不是在每一次绘图中都调用这两种方法。

4，  使用数组

在任何时候，只要可能，都应该使用数组而不是Vector，因为数组的运行速度更快。通常面临的唯一问题是，如果最初分配的数组空间不够大，将需要对数组的大小进行扩充。这可以做到，但它需要对整个数组进行重建。例如：

    Public final static int[ ] expandArray(int [] oldArray, int expandBy)

           {

                  int [ ] newArray = new int [oldArray.length + expandBy];

                  System.arraycopy(oldArray, 0, newArray, 0, oldArray.length);

                  Return newArray;

}

      任何时候，都应该尽量使用一维数组。访问二维数组变量的速度只有访问一维数组变量的一半。当然，仍然可以访问二维数组的对象，只是需要加入一点点计算。例如，与其使用这条语句：

              world[y][x] = 0；

       不如下面这条语句运行的快：

        world[y*tilesWide + x] = 0；

这条语句通过行列的位置将数值转换成一维值，实现了对数组同一元素的访问。

5，  不要使用数组

呵呵，尽管数组的访问比Vector快，但仍然比直接访问变量要慢，因此如果可能就应该删除对数组的访问，或者为一些常用方法中的数组寻求其他能提高性能的办法。

6，  使用快速方法

并不是所有Java调用的方法在性能上都是相同的，方法声明方式的不同对性能会会产生很多的影响。可以使用的最快的方法类型是静态方法，因此应该尽可能多地将代码置于静态调用方法中。运行速度仅次于静态方法的是声明为final的方法。运行最慢的两种方法是在接口中定义的方法和用关键字synchronized声明的方法，必须尽可能地避免使用这些类型的方法。

7，  其他优化

1）异常处理非常缓慢，不要为一半的游戏逻辑使用异常，只用它们来报告真正的错误状态。

2）使用switch表达式比使用if条件语句块的速度要快。

3）尽可能避免使用String对象进行运算，使用StringBuffer。

4）内嵌类的运行很慢，尽可能避免使用。

5）在完成一个引用的使用后将它设为null。

6）不要浪费时间来将一个对象初始化为null或0，java虚拟机会替我们完成这样的初始化

7）多思考新方法，这会使我们的大脑运转的更快。

8）如果可能，尽量使用static，它们运行都很快。它同时适用于方法和域，这条规则就是，如果它可以是静态的，那么就把它声明为静态的。

9）避免类型转换。

10）程序优化的时候要有所取舍，要多捉摸了。大家有什么好的建议？一起来壮大吧。共同探讨：zxhwolfe@hotmail.com

 

参考资料：

《J2ME游戏编程》

www.j2medev.com

 

 

 

附：关于j2me程序的调试

使用eclipseME+WTK2.1进行J2ME应用程序调试(debug)-- 引用mingjava的帖子。

选择windows->preferences->java->debug  不要选择suspend execution的前面两个选项，在debuger timeout选项中  第一个时间至少设置为15000ms  这样就可以调试了。

 

    本文是对J2ME游戏性能优化的初步探讨，有不足和错误之处还请及时指出。（请联系zxhwolfe@hotmail.com）.

本文目的是使我们的游戏能够更快更稳定的运行，J2ME的有限处理能力和存储能力，使得节省设备资源就显得尤为重要。对代码进行优化和提速我个人觉得是一件恐怖的事情，嘿嘿。但当你解决代码的性能瓶颈，使游戏能够流畅运行又是一件很有成就感的事情。

    本文共分两部分：第一部分介绍我们如何使用工具对方法和内存进行评测；第二部分和大家探讨些优化程序的方法。

 

    性能评测所要做的就是，在游戏运行的时候，记录代码每一部分对内存和处理器的使用情况。在评测的过程中，使我们知道什么地方内存使用过大，什么原因导致游戏运行变慢。

    进行评测我们使用的是Sun公司J2ME Wireless Toolkit（WTK2.2）。

J2ME Wireless Toolkit 提供了若干用于监视应用程序性能的工具。这些工具能够帮助您调试和优化代码。

• 事件探查器列出应用程序中每个方法的使用频率和执行时间。
• 内存监视器显示应用程序运行时内存的使用情况。
• 网络监视器显示应用程序传送和接收的网络数据。网络监视器支持多种网络协议，包括 HTTP、HTTPS、SMS 和 CBS。
• 跟踪将低级信息输出到 KToolbar 控制台。

提示：监视功能可能会降低应用程序的执行速度。

 

方法性能评测：

事件探查器跟踪应用程序中的每个方法。对某次特定的应用程序运行，事件探查器都计算出每个方法占用的时间，以及调用每个方法的次数。当应用程序结束运行并关闭仿真器后，将弹出事件探查器，您可以从中浏览所有的方法调用信息。

要打开事件探查器，请从 KToolbar 菜单中选择“编辑”>“偏好...”。单击“监视”选项卡。（即Preferences）如果您想查看所有系统实现方法的配置处理信息，请选择“显示系统类”。否则，事件探查器将只显示包含对应用程序方法调用的系统方法。

要打开时间探查器也可以这样：%WTK安装路径%--〉binà prefs.exe来启动工具。

启动工具并选择“监视”，再勾选上事件探查器显示应该是这样：

 

确定后，即可以。下次启动手机模拟器运行游戏结束后就会弹出事件探查器，并显示有关应用程序中所有方法调用的信息。

提示：只要勾选了事件探查器每次模拟器结束的时候都会弹出，所以记得不用及时取消该功能，因为它影响模拟器的速度，内存监视器尤为明显。不论模拟器是在什么IDE中打开都会弹出方法事件探查器。

 

 

事件探查器显示两种类型的信息：

• 方法关系，显示在名为“调用图”的层次结构列表中。
• 事件探查器的右侧显示每个方法及其子代的执行时间和调用次数。

注－从仿真器中获得的配置处理值反映不出真实设备上的实际值。

调用图显示方法调用的层次结构。调用其他方法的方法显示为文件夹。双击某个方法将其打开，并查看该方法所调用的方法。没有调用任何其他方法的方法显示为灰色圆圈。

您可以搜索某个特定类或方法名。单击“查找...”，并填写名称。搜索从调用图中的当前选择开始执行，直到最后。如果您想搜索完整的调用图，请在单击“查找”按钮之前选中“环绕”。

在调用图中单击不同的节点时，事件探查器的右侧就会显示该节点方法的详细信息。

事件探查器窗口的右侧显示有关方法的详细信息。您可以看到方法名、方法调用次数以及仿真器使用该方法所用的时间。执行时间有四种不同的描述方法：

• 周期表示方法本身所用的处理器时间。
• %周期表示方法本身所用总执行时间的百分比。
• 周期（包括子类）表示某方法及其调用的方法所用的时间。
• %周期（包括子类）表示某方法及其调用的方法所用的时间占总执行时间的百分比。

单击任一列，按照该列进行排序。再次单击该列，可以在升序和降序之间切换。

右窗格显示调用图中当前所选节点中包含的方法。如果您想查看每个方法，请在调用图中单击 节点。

关于保存就不多说了。

 

内存性能评测

许多 MIDP 设备上的内存都不够用。J2ME Wireless Toolkit 中的内存监视器使您可以方便地检查应用程序内存的使用情况。您可以查看应用程序使用的内存总量，以及每个对象的内存使用情况详细列表。

要打开内存监视器，请从 KToolbar 菜单中选择“编辑”>“偏好...”，单击“监视”选项卡。选择“启用内存监视器”。

下次运行模拟器时，就会弹出内存监视器窗口，显示一幅随时间变化的应用程序内存使用情况图。由于创建的每个对象都被记录下来，因此内存监视器会使应用程序的启动速度变慢。最好不要同时勾选两种监视器。 

 

 

您将看到包含以下列的一个表：

• 名字。对象类名称。
• 存活。实例数目。有些可以进行资源回收。
• 总共。应用程序开始运行以来所分配的对象总数。
• 总计。对象使用的内存总量。
• 平均。对象的平均大小，由总计大小除以活动实例数目得到。

单击任一列标题，按照该列进行排序。

通过从内存监视器窗口菜单中选择“查看”>“查找...”，可以搜索某个特定的类名。

特别注意内存使用超出当前分配的堆（图像中红色虚线表示）的情况。

关于方法和内存的评测就到这里，希望大家在使用中的经验和心得能够共同交流。WTK中还有其他好用的功能哦。下一部分讨论下j2me的调试方法和优化方法。

 

本文参考资料：

 

《J2ME Wireless Toolkit 用户指南》

《J2ME游戏编程》  www.j2medev.com

  

最 近在做一个手机浏览器的客户端，最初以为一个浏览器的客户端不用考虑太多的内存使用，结果做完才发现在高端的手机上运行没有任何问题，在低端的手机上不是 响应速度过慢，就是内存溢出。所以就开始对代码进行优化，在这个过程总结一些自己的经验，希望对有困惑的朋友有所帮助，有好的办法也希望大家共同探讨，zxhwolfe@hotmail.com

 

以下内容有些是自己实践所得，有些是参考高人经验或书本上的经验，如有不正确请立即指正；如果侵犯了他人版权请高台贵手，借鉴您的经验不是用于商业，只是希望大家共同进步请不要追究呵呵。

 

       在写程序初期由于是面向midp2.0的手机而且不是游戏的开发，所以没有对性能方面做太多的考虑，大胆的使用了很多vector数组（使用起来方便：））等等，而且程序写的也是随心所欲，似乎不是在手机上开发j2me的东西。结果让我大跌眼镜，没办法只能重新优化，这期间可想而知浪费了很多时间，也使开发效率降低到了最低。说到这，只有一句话奉劝大家，不管你是开发什么样手机程序，一定要把性能放在第一位，不要重蹈我的覆辙。

 

       我的几个vector存放的是链接的内容，文本框的内容，图片的内容和普通文本的内容，每个vector中包含的其他信息还有它所占的行数，它的位置和它的标志。我用线程控制paint（只要目的是实现持续按键的机制），这样的话，每次重绘都要把所有内容重新画到屏幕上，而且还要对当前焦点进行重绘。在重绘的过程中每一次都要遍历一遍几乎所有的vector然后重绘，这样肯定是浪费资源。结果也一样，在稍微低端一点手机上响应明显的慢。优化这样程序，我首先想到的就是把vector用别的方法替换掉，正常的性能使用是字符串-〉一维数组-〉二维数组->vector。一维数组肯定是替代不了我的vector了，那只能是使用二维数组了。费了好大劲把vector转换位二维数组，发现性能上并没有提升多少。大概只节省了20k左右的内存，只能再想别的办法。这里简单说下在手机上获得当前内存和剩余内存的方式：

long tempMin = 1000000；

long temp = Runtime.getRuntime().freeMemory();

if (tempMin > temp) {

tempMin = temp;

   }

g.drawString("total = " + Runtime.getRuntime().totalMemory(), 10, 10, 0);

g.drawString("frees = " + temp, 10, 10 + lineHeight, 0);

g.drawString("hiegh = " + tempMin, 10, 10 + 2 * lineHeight, 0);

把这些东西画到你的画布上，在真机上运行的时候方便你查看内存的使用率。（每种机器的内存最大值是不同的）。

而且可以查看内存峰值。当然你也可以使用wtk自带的内存和方法查看器来判断。相关内容参考我的另外2篇文章：

   J2ME性能优化之--方法和内存的评测：

/Article/Class2/200603/1650.html

J2ME性能优化之—优化方法探讨：

/Article/Class2/200603/1658.html

 

既然转换vector不 能解决问题，那就继续优化。内存的主要使用看来是在每次重画的时候产生的，这样就要减少每次重画的内容，我采取的方式是把所有固定要重画的东西用双缓冲的 方式画到一张图片上，这样只有初始化的时候才去遍历数组，经过一次的遍历把所有内容画到一张图片上，然后每一次的重画都是在重画一张图片。经过这样的处理 性能上有了很大的提升。高兴还为时尚早，nokia的低端机器没有问题了，结果在moto的机器上出了问题，根本就不能初始化，也就是说创建那张图片的时候就应用程序错误了。继续查找原因，结果发现是因为moto的机器不支持创建一张那么大图片。也就是说你创建一张大图的时候，在moto的机器上根本就不能申请到内存。找到原因后，把大图分割为两个比较小的图，ok没有问题了。当然至于moto支 持创建多大的图片可能每种机器不同吧，只能在需要的时候自己测试了。对于浏览器，一张分割为两张需要做些代码的处理。实际上为了性能的更加优化可以把一张 大图分割为多张小图，每张小图的大小可以根据屏幕的几倍大小确定也可以根据机型固定。初始化的时候也可以先初始化一部分图。因人而异。

 

至此，程序的主要瓶颈已经找到，并且解决。正应了一句话，程序是花80%的时间在执行20%的代码。也就是说我们要把主要精力放在那20%的代码的优化上，但实际中我发现对另外80%代码的优化也很重要，主要是一些编程细节上的处理。在细节的代码书写上多注意些也有利于程序性能的提升。关于细节上觉得以下几个方面对程序性能的提升很有帮助。

首先系统垃圾回收的利用：关于堆内存（heap）与栈内存（stack）我们知道，heap存放的是对象实例与变量；而stack存放的是静态方法。堆内存在JVM启动的时候被创建，堆内存中所存储的对象可以被JVM自动回收。在这里，要手动把不用对象置为null，特别是较大的对象，如果不用一定要记得置为空。比如说较大的数组，vector或者是image对象。（切忌）在这里，浏览器中页面图片的读取我是采用的是后台读取，即先显示文字部分，而后后台读取页面中的图片，读取完成后再一起重新显示。重新显示的时候要重新构建那个双缓冲图片，而我当时就忘记了把原来创建的那个双缓冲图片置为null了，走了很多弯路才解决问题。所以要切忌至少把大的对象置空，不要指望垃圾回收。

 

其次是static的使用：静态变量在程序运行期间内存空间对所有该类的对象实例而言是共享的，即只在内存中保存一份拷贝，这样节约了不比要的内存开销。但是static生命周期较长，而且不容易被垃圾回收机制所回收，所以要合理运用，不要适得其反。建议在全部具备下列条件的情况下尽量使用静态变量：

1），变量所包含的对象体积较大，占用内存较多。

2），变量所包含的对象生命周期较长。

3），变量所包含的对象数据稳定。

4），该类的对象实例有对该变量所包含的对象的共享需求。

在我的程序中对静态变量的优化后，使程序占用内存量至少提升了5k-10k。所以也不容忽视。

 

还有就是String类相关的东西：1。字符串累加的时候一定要用StringBuffer的append方法，不要使用+操作符连接两个字符串。差别很大。而且在循环或某些重复执行的动作中不要去创建String对象，因为String对象是要用StringBuffer对象来处理的，一个String对象应该是产生了3个对象（大概是这样：））。

   2，字符串length()方法来取得字符串长度的时候不要把length放到循环中，可以在循环外面对其取值。(包括vector的size方法)。特别是循环次数多的时候，尽量把length放到循环外面。

int size = xmlVector.size();

for (int i = 2; i < size; i++) {

。。。

    }

 

在程序中我曾经误写了这样一句：if(i=5){...}，编译器没有报错，而且结果好像是把i的值改变了，没有记清，大家有兴趣可以测验下。书写上尽量认真，否则查找bug的时候可能会折腾死人的。

 

关于优化方面也就能想起这些来了，如果还有对大家有用的东西我再补充吧，希望大家多提宝贵意见。共同进步嘛。

　　我想做过J2ME的人，特别是像我这样做手机游 戏的，肯定会对OutOfMemoryError这个异常深恶痛绝，尤其是在老40这样变态的机型上，甚至对这个异常都产生了恐惧。还好我现在总算不做这 个机型了，对那些仍然在为这个机型移植游戏的同志们感到同情。为了能够稍微缓解一下他们的痛苦，也为了广大J2ME的从业者和爱好者能尽量减少与该异常的 见面次数，CoCoMo将把自己的经验分享一下。

　　首先了解一下分析内存占用的方法，一般有两种：模拟器自带工具和Runtime类方法。

　　模拟器自带工具：WTK貌似带了一个Memory Monitor，而且许多学者人士也夸夸其谈他的使用方法，但我不知道有多少人真正在用。就我对他的了解，首先运行他你的程序会 慢的一塌糊涂，这对游戏开发者来说简直是无法忍受的。但我出于研究目的仍然让他跑了半个小时才发现原来他根本无法显示正确的内存占用量，我载入一张很大的 图片后他的内存线好像只出现了微微的波动又停留在原位，呵，看来的确是拿出来秀的。我一般使用的是7210模拟器自带的内存监视器，模拟的很准，但唯一的 缺点是内存太少，才200K。我也见某些人使用3220的模拟器监视内存，好像内存稍微大一点，我还没来得及尝试就再也不用为老40写程序了，庆幸。
Runtime类方法：我经常用这个语句System.out.println(Runtime.getRuntime().freeMemory());后来集成进了我的引擎，他能够显示当前剩余内存。不记得有多少次我用它在老40上来寻找内存占用峰值。

　　了解了分析内存的方法，来看看内存占用的罪魁祸首：程序和资源。

　 　程序：类会被编译成class字节码文件随MIDlet的启动加载进内存，而且是一次性全部加入。也就是说MIDlet里类个数越多、单个类程序越长、 类内字符串常量及数据越多，编译后的class文件就越大，载入后占用的内存也越多。我经常在MIDlet类的构造函数里用Runtime方法来查看 MIDlet启动后整个程序占用内存量。

　　优化方法：

　　1.某些同志将MIDlet程序写成两个类来减少内存占用 量，但是以牺牲Java的OOP特性为代价的。在程序比较大时这种弊端将尤为显见。而且CoCoMo曾经遇到过单个类过大，载入时间过长而违反百宝箱有关 Logo 6秒时间限制的情形。因而我现在的程序加带引擎一般都是6-7个类。

　　2.尽量编写优雅的代码，减少函数数量，在程序发布时去掉try catch，最大限度的减少程序行数，这一般都是在老40上没有办法的办法，现在CoCoMo已经不靠这个来省内存了。

　　3.将数据及字符串写进文件，在用时方载入内存，不用时设为null。

　 　4.I/O操作getClass().getResourceAsStream(file);、数据库操做 RecordStore.openRecordStore(name, true);、声音创建Manager.createPlayer();、图像创建Image.createImage(file);会在短时间内占用大 量内存且过后释放，如果MIDlet程序内存剩余量不足则会在这些函数频繁调用时发生内存溢出，产生所谓的内存峰值，尤其在老40上比较普遍。当你再次与 讨厌的OutOfMemoryError碰面时，多用Runtime查找内存峰值发生位置并尽量将这些语句分开调用，并灵活运用System.gc()来 及时回收。

　　资源：

　　图片：是占用内存的大户，尤其是手机游戏图片资源众多。对图片资源在内存中占用量的计算成为J2ME游戏开发者的经常性工作，CoCoMo来解释一下如何计算图片在内存中的占用量：

　　内存占用量=宽*高*像素字节数，其中像素字节数因机型而异。

　 　例如一张64*64的图片在7210上的内存占用量=64*64*1.5=6144(字节)=6K、在S60上的内存占用量=64*64*2=8192 (字节)=8K。像素字节数因机型而异，例如7210是4096色机型，也就是说用12位来表示一个像素，所以乘上1.5，而S60是65536色的机 型，用16位来表示一个像素，所以乘上2。

　　优化方法：

　　有些人认为压缩图片可以节省内存，这种想法是错误的。根据上面的解释图片载入内存后只和宽高有关系，和图片数据量大小没有任何关系，压缩图片只能减少jar大小而不能见少内存占用量。

　　1.静态法：减小图片大小，宽高小了结果当然小了。根据这个思路出现了动画编辑器之类的工具，像gameloft的波斯王子，人物被分割后使人体的部位可以重用，各部位紧凑放置都是为了较少图片大小，充分利用图片中的每一寸空间。

　 　2.动态法：减少同一时刻载入内存的图片数。CoCoMo曾经在火影武士项目中遇到过这种情况，当时有6种怪物，如果同时载入内存在老40上肯定爆掉 了，但是每关只出现两到三种怪物，所以每一关只需要载入该关出现的怪物图片即可。现在想起来当时做这个项目在老40上溢出频出，真把我搞死了。

　 　 声音：声音也是比较耗用内存的资源，声音中音轨所占的byte会转化成字节流被载入到内存中。因而减少音轨所占byte即可减少内存耗用量。目前 gameloft的做法是用声音转化工具将mid转化为ott，然后变为ByteArrayInputStream字节流来创建Player。