J2ME内存占用详解及优化方法
首先了解一下分析内存占用的方法，一般有两种：模拟器自带工具和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。