规范使用资源文件

为了方便移植，可以将所有的UI界面的图片、提示文字等元素都抽取为资源文件，采用资源文件可以使得资源和代码相分离。在设计阶段注意制定UI元素资源的命名规范，这样移植的时候就可以方便地替换。这种“Skin”的方式，也便于后期方便地更换程序的界面风格。对UI元素资源的规范也有利于UI开发人员的素材积累。

关注投入产出比

客户端软件开发面对众多不同的手机平台不是一个理想的平台，因此也很难有一个理想的结果，我们所能做的是在可以接受的范围内寻找一个最佳的投入产出比。按照我们前面提到的移植思路，第一次移植按照程序可以使用的屏幕大小分类，选择五个大类手机进行针对性的开发和移植就可以了，如果一款手机离这五个大类差距都比较大而又不是非常流行的话，不如放弃算了。

代码移植

通常我们需要使用一些针对于手机终端特性的程序代码来创建优化的应用程序。例如在只支持Nokia-UI API的手机上播放midi格式声音的方式和支持MMAPI的手机上播放midi格式声音的方式是不同的，后者上可以运行的代码到前者就无法运行。又如某一款手机上通过接口获取的字体高度和实际显示的字体高度是不一致的，同样的代码在不同的手机上就会出现美丑不一的UI界面，这意味着我们不得不在程序中针对终端特性或者缺陷编写一些代码。怎么来完成这个任务？两款手机屏幕的大小相差两倍都不止，如何来做UI界面的代码移植？以下分析几种方法：

1. 每款手机或者每类手机都各自维护一套代码 这种方法可以最好地发挥程序的性能，也可以避免无用的代码导致编译后的程序大小膨胀。但是将来如果要添加一个新的程序功能，就不得不在每套代码中都实现一遍。后期的版本跟踪和维护是一件非常困难的事情。

2. 利用编译器优化来调整代码 通过使用带有static final 变量的if else 语句，Java编译器在编译的时候可以去除那些永远也不可能被执行到的代码。例如使用if (Configuration.IS_SUPPORT_XXXX)，来表示后面是针对支持XXXX特性的手机的代码，否则编译时这段代码就会被精简掉。这个方法不错，但是每款手机都要维护一个Configuration源代码文件，随着支持设备的增多，某些情况下又要对Configuration文件进行分类合并，另外一个问题是，不能“动态”地import类，也不能“动态”使用类变量类方法，在开发过程中的开发环境不能针对于某个具体的手机类型。

3. 第三方预编译工具 这种方法和上面一种方法有点类似，在代码中加入判断的预编译指令，所不同的是它在程序编译之前就对代码做了修改，这样可以实现“动态”地使用类和类的变量、方法。这种方法对于每一款手机也需要一个设备的配置文件，里面描述我们关注的一些设备的能力和参数，和上面的方法不同的是它的配置文件不需要作为源代码导入，可以保存为XML格式的文件，通过将各种手机终端设备配置文件汇聚起来，就是前面提到的设备资料库，一般是XML形式组织，随着项目的进行代码管理的复杂度不会增加。我们实践中使用的一个第三方工具J2MEPolish就是使用了使用预处理标记来区分不同手机的代码，使用预处理器对代码进行处理，使得其生成针对某一款或某一类机型的特定代码，然后再由编译器进行编译。

智能网络客户端

手机的网络条件目前还是不乐观的，一方面是速度慢，另一方因为手机信号原因，不能保证网络的稳定，用户的一次网络交互可能需要等待很长时间返回或者根本不会返回。如果采用浏览器的方式，必然导致用户体验的大幅下降。客户端之所以最近会兴起，其中一个原因就是客户端可以更智能，可以在离线和在线状态之间切换，并且在离线情况下仍然有一定的可用性。要改善用户的移动网络业务的体验必须要在这个环节下功夫。

微软的Smart Client架构是这方面一个非常强大的架构，在我们的手机报实践中，借鉴了Smart Client的思路和部分设计模式，使得用户的网络服务请求和界面操作独立开来，通过合理的服务调用流程，可以让用户获得最佳的体验：用户无需花时间等待任何网络服务请求操作，在网络服务器请求完成以后以最合理的方式通知用户而不打扰用户使用手机报。基于客户端的应用还有一个好处就是可以接收服务器Push的消息，这也使它看起来更“智能”。可以通过短信等方式将客户端软件远程唤醒并传递消息。这些功能都是传统浏览器应用所不具备的。可以预见，服务器端也需要针对于智能客户端的新特性提供新功能。

下面列出一些智能客户端环节需要关注的一些问题：

如何缓存用户操作数据，以应对网络异常，并保证用户体验？

用户的网络操作返回以后，如何判断是否要提醒用户？

如何检测网络状态，以改变客户端的工作状态？

如何针对运营商网络优化应用层通信协议，选择数据包的大小，保证通讯效率的同时保证成功率？

小结

前面简单介绍一下基于KJava的手机网络应用客户端软件开发实践中的几个关键问题上的心得，在实际程序开发、调试过程中还有很多关于开发环境、各种终端以及网络的非常规的问题，只能*自己在实践中去体会。另外因为KJava平台和手机终端本身的限制，有些问题在上层应用开发层面是没有办法解决的。最近“智能手机”的兴起，大多给了开发者提供了除JavaME平台以外的选择，发挥的舞台也更大，将来的趋势也是手机的可开发性越来越好，限制越来越少，但目前的移动终端和移动网络相比于PC和互联网都是相当受限的。

回到手机的网络应用上来看，客户端软件可以提供更好的用户体验，但是和服务器还是一个整体，一般业务的核心是还都是在服务器端。在客户端基本功能完善以后，剩下的就是如何完善针对于客户端应用的服务器的功能，这一块相比之下更值得挖掘，意义更大。我相信这是未来最具潜力的软件架构之一，基于客户端的移动互联网应用才刚刚拉开帷幕。