通常情况，一个项目开始的时候策划出了需求，美工出了图片，程序员的代码也开始写了，程序员需要图片时，美工给的图片都为一张张静态的图片，然后通过引擎（或者一些工具）导成程序需要的动画序列，和图片数组，程序在Canvas中把图片数组按照图片序列标志的顺序、位置、桢数表现出来。动画是组成游戏的非常重要的部分。因而图片资源的大小、存储方式等对程序生成的jar文件的大小和耗费内存的多少有非常大的影响。在forum.nokia.com和 J2ME WTK2.2的一些文档中我们可以看到一些关于图片资源如何优化的例子，在此我不予详述，但是提及，重点讲述我们的项目经验。
在一些文档中建议我们把所有的资源都放在一张足够大的PNG图片里面，我们对图片进行分割，这样做有非常大的好处，但是有一些缺点，比如我们把一张大图片读入我们的程序里面的时候，我们在菜单部分仅仅需要和菜单那部分资源，不需要其他的资源，这样我们读出的部分显得就非常的浪费内存，我们可以采取把各种图片资源分别存放到几个大图片中，这样我们需要的时候把需要的部分从jar中读到内存，不需要的时候释放出去，这样可以保证一些运算内存比较小的设备使用很多图片资源，不会发生out of memory的异常或者错误。举个例子，一个游戏有菜单、玩游戏、排行榜这样三个部分，完全可以把图片分成三组存储，和菜单相关的存储为 menu.png，游戏中的存储为game.png，排行榜需要的图片存储为range.png，我们进入菜单状态只读区menu.png这样程序浪费的内存相当少，进入游戏时先释放掉menu.png占用的资源，再调入game.png。在项目中这是非常好的应用实例。
在我们的项目中，有时不需要使用切割图像，我们乐于使用一些大小一样的矩形方块状的图片（一些小的公司没有良好的引擎设计时，一般采用这种方式，一些大公司有专门做引擎的e，所以一般采用上面的方法且优化了上面的办法）。因为一些压缩算法、和图片存储格式等众多原因造成了如下状况：把很多png图形放到一张png图片里面省更多的空间。我们如何省空间呢？答案是：自己设计一个资源读取器，把需要的所有png图片读取成2进制码并且按照我们能够简单使用的格式写成一个二进制文件，我们只需要在程序中读取这个二进制文件，在把里面的png还原出来即可。我在我们的项目中发现，单独使用21张14*14的png 图像，与巴这21张png重新写成一个二进制文件（不采用任何压缩算法），后者比前者在jar中节省了10KB。所以说，我们在做游戏的时候，如果没有非常好的引擎，可以采用我们办法来节省空间——把松散的图片用程序写成一个二进制文件，在j2me程序中把这些资源读取出来。
综上，我叙述了两种不同的节省资源的方法，前一种需要比较强大的引擎支持，后一种则不需要，但是后一种确实节省的不如前一种多，但比单纯的用好多png图要节省的多而且不需要复杂的引擎。在未来，我会继续写一些我们项目中的经验。