苦水潭

概述 J2ME 是 Java 2 Micro Edition 的缩写，最新的官方名称是 JavaME（Sun 似乎很喜欢改名字，从 Oak 到 Java，从 Java 到 J2?E，再到现在 Java?E），可 以认为是 Java 为移动设备（手机、PDA 以及其它计算能力和能源供应都受限的设备）剪裁的一套 API。基本上，如果有 J2SE 的开发经验，上手 J2ME 会非常快。除了个别类或方法，J2ME 基本上是 J2SE 的一个子集。Java 在保持语言体验统一性这一点上，做得确实非常好。 J2ME 采用比较混乱的方式来描述自身的版本。整个 J2ME API 被划分为 Configuration 和 Profile。而 Configuration 和 Profile 又各自拥有其版本。关于混乱现象的解释，一两句话难以说清，有兴趣的同学可以随便抓本 J2ME 的书过来，第一章必然有大篇文字解释这些匪夷所思的现象[1]。 J2ME 最吸引人的地方（或者说是吸引我的地方），就在于其针对的平台计算能力有限。这并不是受虐。运算速度、可用内存、以及最终生成字 节码尺寸的限制使得 J2ME 应用通常比较小巧玲珑。以早期支持 J2ME 的设备为例，可用的 Heap不过 200k，最终生成的代码（包含各种资源文件，如图片）不得超过 64k，这就使得面向这种平台开发的 J2ME 应用规模基本上不会超过一个人的能力范围。这样可以有效避免协作、过程等等令人不胜其烦的软件工程概念的引入，从而使开发人员重新回归到编写代码的乐趣中去。 开发环境 抛开感情因素，Windows 是进行 J2ME 开发的首选平台。为什么呢？ 首先，开发 J2ME 所必须的开发包，只有 Sun 官方的 WTK（Wireless ToolKit）[2]对 Linux 提供了良好的支持。其它如 Nokia，与 Windows 版本的更新速度来看，其 Linux 版本更新相当慢且陈旧，而其它如 SonyEricsson[3] 和 Motorola[4] 则根本没有 Linux 版本的开发包。 其次，数据线。J2ME 的开发是离不开真机测试的。模拟器上在完美的代码到了真机上还是有可能运行得一塌糊涂。因此开发人员应该要有一个比较便捷的将 J2ME 部署到手机的途径。这些途径当中，数据线显然首选。而众多的数据线中，提...

ok，我承认题目是用来吸引眼球的。但是，不能不承认的是，这篇文章会很有用，很有用……尽管目前可能只是对我有用……因为我记性不够好…… 下面记载的都是手机 java 实现中各种奇怪的毛病，bug，或者……特性，是根据某项目的开发经验总结出来的。但是涵盖的手机型号还是有限。因此很有可能某些“特性”会存在于更多的采用了相同 JVM（比如平台相同、生产厂商）的手机上。 == 早期 S60 的内存泄漏 == 这个 bug 可以上溯至 2003 年，甚至更早。表现为 java 应用中如果使用了 Class.getResourceAsStream("本地文件") 无法释放其占用的内存，是的，没有任何办法，无论是调用获得的的 InputStream 实例的 close() 或将其设为 null，甚至显式强制 System.gc()，都没有效果。结果就是至少和本地文件同尺寸的内存成为了无法回收的垃圾。这个问题还影响到以 Class.getResourceAsStream() 为基础的 Image.createImage()（这个是最要命的，如何能够不使用图片资源呢！）。 这个 bug 据说在新的 S60 上已经解决了。但是 Nokia 3230（4.0526.2ch）、Nokia 7610（6.0525.0ch）都存在这个问题。对于这些个有问题的机型，在 java 程序中是无法完美解决这个问题的，只能尽量避免。比如集中、统一载入资源，永不释放（也就是说，尽量控制泄漏的次数）。当然，这会对已有代码造成很大影响。毕竟手机 java 应用是内存受限系统的典型，大多数情况下，珍贵的内存中应该只保留需要的资源。 == 键盘响应事件 == 在 MIDP1 中，获取键盘事件只能自己实现 Canvas.keyPressed()。但是 Motorola E398 和 SonyEricsson K700c 的实现却很奇怪。表现为左右软键有可能在这个方法中捕获不到。而是否能够成功捕获，取决于 keyPressed() 方法中代码的行数…… 我承认我没彻底搞清楚这其中的玄机。鬼知道 Motorola 和 SonyEricsson 是怎么实现的 JVM。我只知道把 keyPressed 中的所有代码提取到另外一个函数中，在 keyPressed 只把参数传递给新函数，问题就消失了…… =...