晕，终于见识到了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类，用于管理地图数据的类。
目前基本上就是这样，正在考虑合并问题，有进一步考虑后再说。
本来设计的结构的中，动画播放有一个数据层，一个视图层，数据层里存放的就是精灵自身的固定结构，属于统一的一个接口类，而视图层就是具体的动画播放，视图层与数据层的交互就是精灵自身的状态切换管理，针对视图层，因为每个视图层是一组动画的管理集合，说白了就是一大堆图片数组的分类管理。而对于图片自身，因为引入到了精灵的概念，图片每一张都有不同的特定数据，这说明，必然地，要分派出三个类：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类，用于管理地图数据的类。
目前基本上就是这样，正在考虑合并问题，有进一步考虑后再说。
