通常情況，一個項目開始的時候策劃出了需求，美工出了圖片，程序員的代碼也開始寫了，程序員需要圖片時，美工給的圖片都為一張張靜態的圖片，然後通過引擎（或者一些工具）導成程序需要的動畫序列，和圖片數組，程序在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圖要節省的多而且不需要復雜的引擎。在未來，我會繼續寫一些我們項目中的經驗。
