概述:j2me可以看作是一个比较原始版本的j2se,远不如现今在pc和服务器端流行的java教那么成熟,缺少自动化和傻瓜化,需要投入更多的精力去关心细节,寻找解决方案.这个过程,本身也是颇有趣的. 此处对这些经验做一些总结，写到哪算哪。
开发工具的选择
和j2se的开发一样, 你可以大拿方式的选择编辑器+sdk+脚本工具, 也可以选择完全傻瓜化可视化的ide工具,或则做一个折中.
wtk: 理论上只需要wtk就可以工作了, 很多tutorial也是以wtk为基础的. 如果之前缺少java开发的经验, 我建议从wtk开始,wtk的常见命令和工具都和j2sdk有对应, 比较容易理解. 如果想偷懒,大致学习一下wtk的基本配置,常见命令就可以了.结合antenna脚本,已经基本可以满足日常的开发工作.
某些开发,比如push registry , 签名,需要对wtk工具有深入一点的了解,用时查阅手册即可.
注意： 现有IDE工具可以屏蔽WTK的使用， 但是考虑到j2me开发是个对动手折腾要求比较高的过程，一开始花点时间折腾清楚wtk对你以后的工作绝对有好处。
netbean 6.1: 非常优秀的集成开发环境, 对j2m和j2ee的支持都非常好, 对于j2me的新手来说,可以提供一系列傻瓜化的向导和可视化图形界面帮助快速入手.提供的一些扩展包也相当有用.
nb现在还有的一个优势就是启动速度异常的快,对比越来越慢的eclipse,还是很有吸引力的.另外和svn的集成,也要比eclipse好.
eclipse+ eclipseMe: eclipseMe 和netbean 类visual studio 套装有很大不同,某种意义上,他更象是提供是一个图形化的脚本工具,帮助简化编译,测试和发布应用. eclipseMe也提供导出成antenna 脚本的功能，使用ant来做操作可以提高一些重复劳动的效率.
这2种ide都能很好的满足开发要求,还是依赖于你个人的喜好和团队成员的熟悉程度进行选择.对于我这样虽然懒,但是偶尔还是喜欢把玩具拆开来看的人来说, EclipseMe更适合, netbean复杂的向导和工具总是让我忍不住去瞎琢磨. 我建议nb的用户避免使用netbean哪堆花哨的向导,因为随着你对me的了解的深入,你就会发现很多东西还需要自己动手,这时向导生成的东西,反而成为了包袱.
代码风格
作为一个熟悉各种模式\规范\重构概念的java教成员, 我进入me的世界开始比较困惑, 突然发现受限于设备资源和一些老家伙的习惯, 规范式的设计和编码风格突然退到了次要位置.程序的可维护性和可扩展性不再是重要指标了. 嗯,你现在进入了一个异教徒的世界.
常见的问题如下
* 大方法和小方法的问题
me世界的很多程序员都喜欢写大的方法,这样据说可以提高代码的执行效率, 这种执行效率在pc上或许是微不足道的,但是在早期的kvm上影响还算显著.有趣的是受限于kvm,太长的方法也会有问题,所以现在某些程序员也倾向拆分做中等长度的方法.anyway, 这和普遍吸重构粉末上瘾, 5句话也要弄个方法的清教徒相比, 简直是邪教..
* 大类和小类的问题
这个问题和上一个问题类似, 很多书籍上都可以看到优化的建议,尽可能少的类可以压缩发布体积,减少启动和运行的时间. 但是大类的设计打破了oo的基本责任原则,导致系统难以维护和扩展.
以上2个问题导致不少kjava的代码都有典型的意大利面条风格, 而大量的kjava程序员是从c社区进入的,又进一步强化了此种面条风格. 这和强调千人一面信奉单一大神"规范"的java教,几乎是格格不如的
* 对象的重复使用和即用即弃的问题
你会看到久违了ojbect pool和 重用概念, 少创建对象,重复使用对象可以减少系统的堆消耗,提高系统性能. 和这个问题相关的就是midp的事件处理, 为了避免大量的创建event object
midp的设计不再使用我们熟悉匿名事件处理类的方式,而是倾向于集中式的事件处理,用一堆case语句进行分支处理, 所以很容易看到一些即便是强调mvc设计的me应用,也是一个巨大的eventhandle,里面遍布上百条case语句.
而对于现代的hotspot jvm来说, 对象的即用弃其是最简单高效的做法.
你需要在性能和可维护性\可扩展性之间做一个选择或者平衡. 我的选择是保留自我本色, 呵呵, 实际效果还好. 当然如果你的应用范围是要照顾一些老弱病残的手机,当我没说吧.
我的选择和对java教的虔诚度无关.
实际上,和手机硬件的高速发展相反, 最近2年j2me的发展几乎处于停滞状态,所以可以找到的相关书籍大部分都是基于3-4年前的硬件来讨论问题, 而大部分的j2me应用都是游戏, 为了考虑兼容, 更少的会去研究硬件的发展和更新. 因此很多所谓的代码优化策路, best practise 都有out的嫌疑.
对于kvm 需要认识一个概念, 区分kvm based 的手机 和 CLDC hi (hotspot implements)based 的手机.
大部分所谓的优化策路, 是对于kvm based的手机而言的, 这类手机一般对jar程序的体积要求在64k以下, 可用内存heap空间不超过512k-1m. 而新进的各种中高端的智能手机和娱乐手机,普遍使用了CLDC hi based的jvm设计,以s60系统为例 ,可用使用的最大内存空间可以超过8m,cpu也往往超过200mz, 对于这类手机这些所谓的优化影响和硬件的进步相比,都不再那么重要了.
在硬件允许的情况下, 应该充分考虑代码的可维护性和可扩展性. 现形的kjava只是一个过渡,随着移动设备硬件的高速发展, kvm的最终会发展成类似pc based java的全面平台. google 的gphone已经是个很好的例子。
当然一点折中和改变都没有也是不可能的, 后面关于内存回收的部分我会继续讲.
.
.