设备兼容性

  java老鸟们大多应该对java的所谓写一次到处运行留下了深刻的印象,我们已经习惯了所谓按照某种规范开发,然后写一次,到处调试的的模式。好吧,非常不幸的是,kjava设备的差异性要远高于 j2ee中各种应用服务器和平台之间的差异,现在的规则可能会变成,写一次, 到处修改。搞不好工作量的三分之一都会花费在这个上面。
  大的厂商,比如nokia和索爱, 会提供定制版本的模拟器以及相关文档,在定制版本模拟器上运行可以节约一部分工作量,虽然很遗憾的是,他们的速度通常不怎么样,小问题也比较多。 而其他一些厂商可能完全没有模拟器和文档说明,特别是wm上的第三方kvm实现,那就只能自求多福了。

  你必须认识到
   * 模拟器和真机永远是有差异的, 只有在真机上运行过才知道后果,尤其是运行速度,网络连接方面。
   * 不同手机的kvm实现之间是有巨大差异的,规范对这种差异基本上不做控制,UI的实现尤甚。

  作为企业应用开发的一个惯例在j2me上也适用,尽早的确定设备型号,并一直持续在这些型号上进行测试。不要到交付用户的时候再最后做兼容性测试。

内存管理

  大部分手机都是严格的内存受限设备,可用内存通常在256k-2m之间。 好吧,老java程序员的怀旧时光又开始了,你会发现在hotspot vm出现之前的一些概念也同样对kvm有效,主要是关于内存回收部分的代码,你需要打破你臭美的代码风格,强制设置一些已经在j2se世界抛弃的东西。
   *  对需要回收的资源,需要强制将变量设置为null, 这样gc会优先回收。所以对于个头稍微大点的变量,都记得找个地方设置为null。
   这事情比较极端的做法是甚至你确定不需要某个资源了,给变量重新赋值之前也需要设置为null。比如
   
       Boy boy = new Boy("good");
       boy = null; //这样gc才会知道先回收good
       boy = new Boy("bad");
   

   *  必要的时候调用System.gc进行强制回收, 信不信由你,在很多机型上它确实很有效。在内存消耗比较大的操作之后,调用这个效果很明显。
   顺便说一句的是,在j2se的hotspot 的实现里,这样做的结果往往是让系统呆住。
   *  尽量不要一次使用大型数组,尽可能拆分成小数组操作。
     尤其是对图像的操作,诸如旋转之类,很容易内存死光光。
 
以上这三条已经可以让你的代码具有典型的异教徒风格了。另外一些final,static,访问方法和实例变量的差别,确实有一些书籍介绍如何如何,但是据我阅读的某本书籍中的测试,这些都是跟机型和kvm实现相关的,没有绝对标准。

   
异常处理
  j2me的异常处理和j2se迥然不同。 一方面是因为设备通常没有什么控制台和文件输出的概念,约束你随意的打堆栈, 另外一方面,midp中的异常类的规范并不要求异常附带堆栈信息,只要求异常的堆栈包含类名而已。 这2条让异常很难准确定位。

 少许幸运的是,一般模拟器都有debug的模式,这种模式一般有附带不完整的异常堆栈信息,这也是你可以在pc上开发看到一些异常堆栈的原因。但是在手机上则看不到,除非你安装debug版本的kvm。即便是这种debug模式,也不会附带常在j2se中出现的文件和行列信息, 问题定位也要繁琐一些。即便如此,你也应该庆幸可以在模拟器上发现大部分问题。

  最后归结于设备兼容性的问题, 初次在设备上运行时,发生各种runtimExcepiton的概率非常高,而一个类名很难让你准确定位问题,所以编程习惯必须有所改变。

  我的做法是
  *  尽可能的对方法中的参数和变量进行检查。 防止空指针和索引之类的异常出现。
  在j2se中我们一般只强调对入口参数的检查,不会太强调对过程中变量值的检查。这样毕竟会增加代码量。
  *  尽可能的对一些入口出,网络部分, ui部分这些和设备依赖比较高部分的代码还有一些关键代码做runtimeException的捕获,方便定位调试。

  而在j2se中的开发中,根据Effective java的表述, 对runtimeException,我们应该视为编程性错误,应该不做处理,让其尽早的暴露。问题是在j2me的环境很难暴露准确位置,所以还是自力更生比较现实一点,这样好过你到时候满世界的去怀疑异常是从何处代码而出的。

  *  尽可能多的做单元测试也是个好路子。 要比在手机上去找问题节约时间。
 
== 日志 ==

 受限于设备的特性, j2me中没法直接把日志输出到控制台或者文件. 而j2me的调试困难度决定了一个合理有效的日志机制显然是必须的,而且应该在程序开发初始就必须认真考虑。

 实现日志的方式大致有3种
  1. c/s模式, 将日志发送回后台存储, 在jdj中有篇文章介绍这种模式,优点是查找问题非常方便,在后台看就好了,缺点当然是资源消耗问题,还有有些错误有可能发生在联网之前,或者联网处理中。
  2. 将日志输出到 rms中,  事后通过程序查看,但是注意rms一般都有大小限制,从几十k到几百k不等
  3. 将日志输出到一个屏幕对象, 可以是form也可以是canvas,需要的时候调出来看。也可以和2结合使用。

 我选择了第三种方式,将日志输出到一个日志屏幕,日志屏幕附带了一个sms发送日志的功能,这样出了问题,可以方便让用户直接把日志信息以短信的方式发送给我定位,呵呵, 至于短信费用,哪不是我考虑的问题:)。
 另外为了方便内存的跟踪, 在测试阶段,日志应该可以自动生成一些内存使用情况信息。

  有一些第三方的log4j实现 比如 Jadabs Log4 J2ME,log4jMini, Microlog4j。 有兴趣也可以参考一下。