暈，終於見識到了J2me的代碼容量限制 這段時間都忙著研究J2ME游戲，發現一個令人非常不快的問題：代碼大小。基本上，這是第一次見識到連代碼都要有限制的開發，在Nokia S40上，排除其它要求外，代碼容量基本上要求不超過30K。核計了一下，不禁郁悶，一個類，裡面什麼也不寫，都要占掉200多字節，這樣折騰辛苦啊。
本來設計的結構的中，動畫播放有一個數據層，一個視圖層，數據層裡存放的就是精靈自身的固定結構，屬於統一的一個接口類，而視圖層就是具體的動畫播放，視圖層與數據層的交互就是精靈自身的狀態切換管理，針對視圖層，因為每個視圖層是一組動畫的管理集合，說白了就是一大堆圖片數組的分類管理。而對於圖片自身，因為引入到了精靈的概念，圖片每一張都有不同的特定數據，這說明，必然地，要分派出三個類：Sprite,SpriteView,ImageFrame，換而言之，光是為了精靈這個最抽象的實現，就必須制造3個類來管理。為什麼要把Sprite與SpriteView中分離呢？因為在手機中讀取圖片的速度非常非常之慢，要有效地管理內存，在每一關之前就必須預先加載圖片等數據，臨時加載會造成游戲中的停頓，故又因為節省內存的關系，采用對象池管理Sprite，自然又產生了一個SpritePool類，這個類主要是用於管理死亡的敵人，保證暫時不用的對象不回收，從而可以預先創建幾十個對象類的實例，先放在內存裡，因為它們都是要用到的，同時也占不了多少內存，但實際上會大大地提高性能。SpirteView通過一個預處理器事先分析好關卡數據，決定事先要緩存的View，然後只需給Sprite指明用哪一個SpriteVIEw，就可以很簡單地實現統一管理狀態。這樣可以把內存中的利用率提至最高。必然地，游戲既然考慮是一個通用的框架，又不得不多出一個GameConfig類，再考慮一個要把通用函數都集中在一起的類，那自然又多了一個工具類。游戲必然要有個世界，很顯然，GameWorld類又出來了。
現在最基本的游戲核心實現就需要Sprite、SpriteVIEw、SpritePool、GameConfig、GameWorld幾個類，然後，很顯然地是有兩個必須的類，一個是GameMidlet，一個是GameCanvas。這一口氣就產生了7個類，換算下來就有了平白失去了1.4K的空間。我真不知道Java怎麼實現這些的，但確實讓人窩火。然後就是讓人郁悶的Menu類，即繪制菜單用的，Map類，用於管理地圖數據的類。
目前基本上就是這樣，正在考慮合並問題，有進一步考慮後再說。
