一些J2ME开发的建议和说明

一些很好的建议和说明 by BlueWanderer

开发游戏的内存问题:
  尽量不要在会无限循环的部分建立新的对象,把建立对象的工作集中到状态改变的那一点。比如RPG游戏从地图切换到战斗的时候就该把战斗状态需要建立的对象都建立好,战斗进行中没特殊情况就不要建立对象了。
  另外要避免制造内存空洞。比如先建立了对象a,然后建立的对象b。如果这个时候释放了a,又建立了c,除非你的c和a一样大,否则就会产生一个“洞”。如果有大量的这种操作,内存中就会产生很多无法利用的小的“缝隙”。

  
线程问题
  很郁闷地发现,很多人甚至做了很久的手机游戏还搞不清楚自己写的程序有几个线程。如果你还不很了解Java的线程,请先去补习一下。
J2ME游戏一般来说应该有两个线程,但事实上应该保持在单线程工作的状态。没有特殊情况不要进行多线程操作,更不要使用超过两个的线程。线程总体上说是个昂贵的东西,而且是个陷阱重重的东西。

  
类的使用
没什么特殊情况应该只有两个类:MIDlet和Canvas。每多一个类就会多出一些冗余信息,而事实上又没有绝对必要使用更多的类。有人会说用两个类会导致代码编写的困难——不管用什么方法解决,作为职业游戏开发人员或者热血的游戏开发爱好者,现阶段尽可能减小游戏尺寸是你们的义务。

  
game包
  作为职业游戏开发人员或者热血的游戏开发爱好者,不使用它是你们的义务……这东西会大大限制游戏的性能,进而制约表现力,因为它的效率实在太差。尤其对于职业人员,如果你还抱着它不放,你很快就要饿肚子了——看吧,手游市场变革的时代已经来了,当无数使用Canvas的技术密集型精品游戏反攻中国市场的时候,想想吧。

  
资源:
  zip压缩是以文件为单元的,把资源合并为一个文件可以提高压缩效率。但同时注意,如果你需要的数据在文件的中间,你要获得它就必须把前面的所有数据解压。压缩比和读取效率怎么权衡就是你要做的工作了。
  另外,没特别要求不要用jar.exe打包,那个压缩参数有问题。

  
MIDP的事件处理机制
 
 这个是“API文档里说得很详细的东西”,因为比较重要,这里单提出来强调一下。先跟被我支到Display类的朋友们说声抱歉,发现这个是在
lcdui包里讲的。MIDlet的事件处理在随MIDlet一起建立的线程中进行,好像有类似“Repaint
Cycle”的叫法。对应每个MIDlet有一个事件队列,但是这个队列并不是逐个被处理的。事件的发送工作在这样一个循环中进行:每次循环都会扫描所有
可能的事件,如果队列里有这种事件,就会调用事件对应的callback方法,并把这个事件删除。一个比较脱离常识的现象就是:假如队列里先有了10个按
键事件,又被推进了10个重画事件,处理过程并不是先处理完10个按键事件,再去处理后加入的10个重画事件;而是处理一个按键事件,处理一个重画事件,
再处理下一个按键事件,再处理下一个重画事件,直道全都处理完。
  然后就是serviceRepaints方法,这是个非常重要的东西。它的功
能在于打破Repaint
Cycle。serviceRepaints的具体行为大概是这样:如果消息队列中有重画事件->如果有重画事件正在被处理->等待;否则等
待正在被处理的事件(如果有的话),然后在当前线程进行重画事件处理(就是说如果你在你建立的线程内调用了serviceRepaints,最终
paint方法也会在你建立的线程中被调用);最后删除消息队列中所有重画事件。基本上在游戏中repaint方法之后必须有一个seviceRepaints。

  
键值
  Game Action是个很初级的而且不确定的东西,商业游戏里不应该用它;而应该直接使用callback方法传过来的键值。对于有人说这会降低程序的通用性,J2ME程序本来就没通用性。

  
关闭程序
  关闭程序之前释放资源——不,不是好习惯——是种毫无意义的举动,这样只会增加你的代码。一般来说在关闭程序之前你要考虑的只有RMS
  另外,太多人有这种误解:主动关闭程序的流程是调用destroyApp然后调用notifyDestroyed。这个就是对平台不熟悉的结果,的确API文档中对notifyDestroyed的说明也有点误导。关闭程序只要一个notifyDestroyed就可以了,在前面调用destroyApp只是一种可选行为。

  
变量初始化
  Java的成员变量都会被系统初始化为0。这个0对于数据类型就是0,对于布尔型是false,对于引用是null。所以不要多此一举地把它们初始化成这些值,因为javac会非常愚蠢地把这些东西写进class文件。

  
关于调试
  不要漫无目的地去猜,也许你们没有过一天要改十几个乃至几十个bug,而程序又是别人写的这种经历——这种时候经验似乎永远是不够用的,更不要说我那个时候刚接触手机游戏根本没经验可言。怎么办?对于大多数错误,请先设法确定出错的具体位置,再去寻找导致错误的原因,这个时候还搞不懂问人也罢。请不要把stack trace贴出来,然后问一些让人诧异的问题,如果你是专业人员的话。

  
关于编译、执行、打包
  用IDE可以,不过对于专业人员这些操作你有自己搞通的义务。特别是要多少熟悉一下字符串编码问题。

  
关于画图
  Java的画图和本地代码有所不同的就是往往和游戏的运行速度直接相关的不是你画图的面积,而是你画图的次数。在个别手机上甚至你画一张全屏的图比画四五张只有一个像素的图片时间还短。

  
对于RMS
  不要当它是个数据库,这个就是存byte数组用的。