JBuilder2005 + CommentProcessor 開發J2ME

首先闡明的是，該文章僅僅是個人經驗之談，是我經過一段時間的J2ME游戲開發後總結的一些工具的應用技巧。文章給出了在開發的同時利用一些小工具來進行更好的項目配置治理的技巧，利用這些技巧可以保證項目具備更好的源代碼治理、修正、調試、宣布流程。

典范項目描寫

這裡簡要描寫項目標需求，分析項目特點，發明項目具備了應用CommentProcessor的條件。

目標平台：
諾基亞S30, 諾基亞S40,,諾基亞S40v2, 諾基亞S60, 諾基亞7600, 諾基亞7650, SonyK700, SonyF500,MotorolaV525, MotorolaV220, Morotola_i730, Motorola_i860, SharpGX10,SharpGX20, SIEmensC65, SeimensCX65. 同時每個平台配有5個以上多國語言包。 項目要害描寫：
模式：正上方俯視，固定輿圖塊大小，動作解謎過關游戲
要素：行走、跳躍、開門、兵器調換、射擊、敵人、回避視野、夜視模式
平台移植要素：屏幕分辨率、游戲視圖布局、輿圖塊大小、特定平台實現類庫（如：諾基亞UI包）、聲音格局支撐、按鍵映射、關卡設計、游戲數值差別、特定平台BUG差別 特點分析：各平台版本具有基礎雷同的游戲邏輯，不同的游戲視圖，不盡雷同的API，某些關卡設計稍有不同。平台代碼類似度80%

JBuilder2005環境配置

根據項目特點分析，決定應用CommentProcessor進行幫助開發，本節描寫了利用CommentProcessor的項目標配置方法

建立項目組(.bpgr) ，以游戲英文名稱全稱或縮寫命名。 為每個需要宣布的平台建立一個項目(.jpx)，分辨以目標機型命名項目名稱，同時根據語言（或其他要素）建立若干MIDlet打包工作項。若工程同時應用了其他工具（如：CommentProcessor）則同時需要添加一個"External Build Task"用來調用外部工具進行預處理。
在這個特定項目中由於應用了CommentProcessor，於是我們僅僅保護一套帶有預編譯內容的源代碼，我們把它放在"_src"目錄中，避免與JBuilder的默認源文件夾沖突，同時我們把經過CommentProcessor預處理過的源文件輸出到"src"文件夾中作為一個項目編譯需要的的源文件。當然，項目需要的其他資源（如：文檔、腳本等文件）則需要按照實際情況安排到項目中。
要害項目組織樹形結構如下所示：
圖例：
▓：項目資源 ▒：Build過程
<GameName>.bpgr
    ├──諾基亞S40.jpx
    │        ├──▓<Project Source>
    │        ├──▓_src
    │        ├──▓res

│        ├──▒<GameName>_諾基亞S40_CH.jar/.jad
    │        ├──▒<GameName>_諾基亞S40_EN.jar/.jad
    │        ├──▒External Build Task(Comment Process)
    │        └──...
    ├──諾基亞S60.jpx
    │        ├──▓<Project Source>
    │        ├──▓_src
    │        ├──▓res
    │        ├──▒<GameName>_諾基亞S60_CH.jar/.jad
    │        ├──▒<GameName>_諾基亞S60_EN.jar/.jad
    │        ├──▒External Build Task(Comment Process)
    │        └──...
    ├──SonyK700.jpx
    ├──...
    ├──...

要害項目工程文件夾組織樹形結構：
圖例：
■：文件夾  ⌡：文件
■<GameName>
    ├──■_src //唯逐一套預編譯之前的源文件夾，需要保留在VCS中
    ├──■res   //資源文件夾，包含圖片、腳本等其他資源，需要保留在VCS中
    ├──■src   //臨時文件夾，用於存放臨時天生的經過預編譯的源代碼文件，這些文件將在相應平台項陌天生的時候被Javac編譯，不必保留
    ├──⌡諾基亞S40.jpx //JBuilder特定平台項目配置文件，需要保留在VCS中
    ├──⌡諾基亞S60.jpx
    ├──⌡SonyK700.jpx
    ├──...
    ├──...

流程配置治理

源代碼配置治理

永遠保護一套且僅有一套預編譯之前的源代碼，不要采用復制-粘貼的做法導致代碼版本的混亂；

經過一段時間積累，我們已經形成了許多可重用的靜態方法庫，而日積月累，這樣的庫會變得很大。單獨引用它們不僅不會方便開發，還只會增大不必要的容量。所以，應用已經完善的靜態方法庫時，可以奇妙的利用CommentProcessor的"//#+" , "//#-" , "//#prefix+", "//#prefix-"的功效來裁剪不必要的代碼來簡化天生的源代碼；

為每個平台定義一個預編譯領導文件，裡面包含了預編譯所需要的名稱、常量、字符串等一系列相干定義，來領導預編譯過程。同時，必需把預編譯過程放在"Compile"之前履行，才干保證每次Rebuild都能天生最新的相應平台源代碼；

所有調試代碼均可以應用"//#ifdefine DEBUG"和"//#endif"的方法包裝，以便天生最簡捷的目標代碼；

安排配置治理

JBuilder進行MIDletSuit打包時可認為打包的資源文件重命名，在程序中一般采用為不同的打包版本同一資源文件名（如：人物圖片文件名為"chr"，腳本文件名為"script"），但是針對不同的打包版本的資源文件一般應用不同的具有代表性的文件名（如：諾基亞40人物圖片名為"chr_S40.png"，諾基亞S60人物圖片名為"chr_S60.png"），所以在打包時應當將打包的資源文件重命名為尺度名稱（即："chr_S40.png"->"chr" ,"chr_S60.png"->"chr"），這樣做，縮短了文件名長度，在必定程度上還可以減少一點點程序的Size；

 

項目總結

利用了CommentProcessor之後，可以更好、更高效的重用已經成型的方法庫，並能夠天生盡可能高效簡潔的目標代碼； 更好的利用JBuilder供給的“項目組治理”功效和"Borland Make"等功效可以更快捷方便的天生目標代碼和治理項目；