概述: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已經是個很好的例子。
當然一點折中和改變都沒有也是不可能的, 后面關于內存回收的部分我會繼續講.
.
.