JBuilder2005 + CommentProcessor 开发J2ME

首先说明的是，该文章仅仅是个人经验之谈，是我经过一段时间的J2ME游戏开发后总结的一些工具的使用技巧。文章给出了在开发的同时利用一些小工具来进行更好的项目配置管理的技巧，应用这些技巧可以保证项目具备更好的源代码管理、修改、调试、发布流程。

范例项目描述

这里简要描述项目的需求，分析项目特点，发现项目具备了使用CommentProcessor的条件。

1. 目标平台：
   NokiaS30, NokiaS40,, NokiaS40v2, NokiaS60, Nokia7600, Nokia7650, SonyK700, SonyF500, MotorolaV525, MotorolaV220, Morotola_i730, Motorola_i860, SharpGX10, SharpGX20, SiemensC65, SeimensCX65. 同时每个平台配有5个以上多国语言包。
2. 项目关键描述：
   模式：正上方俯视，固定地图块大小，动作解谜过关游戏
   要素：行走、跳跃、开门、武器更换、射击、敌人、躲避视野、夜视模式
   平台移植要素：屏幕分辨率、游戏视图布局、地图块大小、特定平台实现类库（如：NokiaUI包）、声音格式支持、按键映射、关卡设计、游戏数值差异、特定平台BUG差异
3. 特点分析：各平台版本具有基本相同的游戏逻辑，不同的游戏视图，不尽相同的API，某些关卡设计稍有不同。平台代码相似度80%

JBuilder2005环境配置

根据项目特点分析，决定使用CommentProcessor进行辅助开发，本节描述了利用CommentProcessor的项目的配置方法

1. 建立项目组(.bpgr) ，以游戏英文名称全称或缩写命名。
2. 为每个需要发布的平台建立一 个项目(.jpx)，分别以目标机型命名项目名称，同时根据语言（或其他要素）建立若干MIDlet打包工作项。若工程同时使用了其他工具 （如：CommentProcessor）则同时需要添加一个"External Build Task"用来调用外部工具进行预处理。
   在这个特 定项目中由于使用了CommentProcessor，于是我们仅仅维护一套带有预编译内容的源代码，我们把它放在"_src"目录中，避免与 JBuilder的默认源文件夹冲突，同时我们把经过CommentProcessor预处理过的源文件输出到"src"文件夹中作为一个项目编译需要的 的源文件。当然，项目需要的其他资源（如：文档、脚本等文件）则需要按照实际情况安排到项目中。
   关键项目组织树形结构如下所示：
   图例：
   ▓：项目资源 ▒：Build进程
   <GameName>.bpgr
       ├──NokiaS40.jpx
       │        ├──▓<Project Source>
       │        ├──▓_src
       │        ├──▓res
       │        ├──▒<GameName>_NokiaS40_CH.jar/.jad
       │        ├──▒<GameName>_NokiaS40_EN.jar/.jad
       │        ├──▒External Build Task(Comment Process)
       │        └──...
       ├──NokiaS60.jpx
       │        ├──▓<Project Source>
       │        ├──▓_src
       │        ├──▓res
       │        ├──▒<GameName>_NokiaS60_CH.jar/.jad
       │        ├──▒<GameName>_NokiaS60_EN.jar/.jad
       │        ├──▒External Build Task(Comment Process)
       │        └──...
       ├──SonyK700.jpx
       ├──...
       ├──...
   
   关键项目工程文件夹组织树形结构：
   图例：
   ■：文件夹  ⌡：文件
   ■<GameName>
       ├──■_src //唯一一套预编译之前的源文件夹，需要保存在VCS中
       ├──■res   //资源文件夹，包含图片、脚本等其他资源，需要保存在VCS中
       ├──■src   //临时文件夹，用于存放临时生成的经过预编译的源代码文件，这些文件将在相应平台项目生成的时候被javac编译，不必保存
       ├──⌡NokiaS40.jpx //JBuilder特定平台项目配置文件，需要保存在VCS中
       ├──⌡NokiaS60.jpx
       ├──⌡SonyK700.jpx
       ├──...
       ├──...

流程配置管理

• 源代码配置管理

  1. 永远维护一套且仅有一套预编译之前的源代码，不要采取复制-粘贴的做法导致代码版本的混乱；

  2. 经 过一段时间积累，我们已经形成了许多可重用的静态方法库，而日积月累，这样的库会变得很大。单独引用它们不仅不会方便开发，还只会增大不必要的容量。所 以，使用已经完善的静态方法库时，可以巧妙的利用CommentProcessor的"//#+" , "//#-" , "//#prefix+" , "//#prefix-"的功能来裁剪不必要的代码来简化生成的源代码；

  3. 为每个平台定义一个预编译指导文件，里面包括了预编译所需要的名称、常量、字符串等一系列相关定义，来指导预编译过程。同时，必须把预编译过程放在"Compile"之前执行，才能保证每次Rebuild都能生成最新的相应平台源代码；

  4. 所有调试代码均可以使用"//#ifdefine DEBUG"和"//#endif"的方式包装，以便生成最简捷的目标代码；

• 部署配置管理

  1. JBuilder 进行MIDlet Suit打包时可以为打包的资源文件重命名，在程序中一般采取为不同的打包版本统一资源文件名（如：人物图片文件名为"chr"，脚本文件名 为"script"），但是针对不同的打包版本的资源文件一般使用不同的具有代表性的文件名（如：Nokia40人物图片名 为"chr_S40.png"，NokiaS60人物图片名为"chr_S60.png"），所以在打包时应该将打包的资源文件重命名为标准名称 （即："chr_S40.png"->"chr" , "chr_S60.png"->"chr"），这样做，缩短了文件名长度，在一定程度上还可以减少一点点程序的Size；

  2.  

项目总结

1. 应用了CommentProcessor之后，可以更好、更高效的重用已经成型的方法库，并能够生成尽可能高效简洁的目标代码；
2. 更好的应用JBuilder提供的“项目组管理”功能和"Borland Make"等功能可以更快捷方便的生成目标代码和管理项目；