冰浪

      说到移动网络应用，前几年大家首先想到的就是WAP应用。最近随着市场上手机的可编程能力越来越强，手机软件开发平台和产业链的逐渐成熟，手机上的网络应用软件逐渐多了起来，如移动QQ、PICA、掌讯通等等。这些客户端软件凭着丰富的应用、以用户为中心的体验、良好的业务感知度逐渐成为WAP业务之后的又一类重要网络应用。目前的移动软件开发已经逐渐从传统的嵌入式开发中相对独立出来, 主要指手机上的上层应用软件开发，最近也成为了软件行业的新兴热点。

       作为业务运营的手机网络应用客户端软件要求能够部署到大量的手机终端，并注重和网络服务器端业务的结合，目前这方面的开发参考资料还比较少。本文以手机报项目为基础，简单探讨一下手机网络应用客户端软件开发实践中的几个关键问题，希望对新进入者有所帮助。假设我们需要开发一个高可用的手机网络应用客户端软件，用于在线定购和阅读电子报刊业务，覆盖目前移动梦网用户中占有率最高的几十款手机，下面结合KJava开发介绍一下我们的一些实践心得。

用户界面设计

        问题：目前很少有人有手机客户端软件的用户界面（UI）的设计经验，UI设计开发的原则和流程是怎么样的？

         手机客户端软件的UI设计和开发在整个软件开发过程占据相当重要的比重，对于没有相关积累的团队来说，我们估计，软件UI开发占软件全部工作量的40％左右。和其他面向最终用户的软件一样，客户端软件UI设计的原则是：以人为本，保证简单易行的操作方式，同时兼容最大范围的手持设备。目前的手机用户界面主要分为两类：通过导航键单手操作方式和触摸屏方式。这两者在操作方式上有着较大区别，但实际项目中如果软件的UI不是太复杂，出于开发成本考虑，UI设计可以主要针对方向键操作的手机，在此基础上再稍做改动以兼容触摸屏手机，这样也是可以接受的。除此之外，手机客户端软件的UI开发还有如下几点经验：

     程序开发人员早期介入

         目前市场占有率较高的手机大部分还只提供KJava开发接口，它的高级UI控件很难满足我们的要求，如果要达到设计的效果一般需要直接使用底层API自己实现。在UI设计开发的流程上，对于没有UI开发经验积累的团队，建议在需求阶段以后先进行原型界面开发，一是为了确认用户的体验需求；二是通过开发人员早期介入确保UI设计人员的设计效果是可以在确定的时间内实现的。第二点很重要，在手机这样一个资源和能力都受限的平台上如果仅仅从UI人员的角度去设计界面，很容易导致无法按时实现或者在真机上的效果太差。UI界面开发阶段一般的流程是这样的：先由UI工程师和开发人员自由讨论，定义出UI元素和大致操作流程，接下来是由开发人员进行实现，最后再由UI人员在已经实现的基础上进行美学创作。

       建议制定一个适合项目实际情况的UI设计开发流程，注意和UI相关的功能一定要在真机上多测试。

   程序界面的有限设计原则

         我们的客户端软件不是浏览器，这点要时刻牢记。客户端软件所能处理的服务器端的内容和业务流程都是相对受限的，也正是因为客户端应用软件对于其他环节的限制要求，才能保证客户端应用相对于浏览器应用更好的用户体验。例如，在实践中无论是服务器传回的内容格式，还是客户端界面层次级别，都是可以要求确定的，其他如软件报刊阅读界面上的字体大小、间距、可下拉屏幕的最大长度等都是可以在需求的时候就确定下来的。

     支持多款手机平台

      问题：KJava平台上的程序离“一次编写，到处运行”还差得很远：不同手机的屏幕大小相差很大，程序需要重新调整界面；不同终端的能力层次不齐；即便是同样的功能，不同型号手机在具体支持程度和方式上也有差别；有些手机终端还有自己特有的BUG。如何让我们的程序支持这几十款手机？

     一般在开发的时候我们先基于SUN公司的标准WTK或者是某款非常典型而且移植性比较好的手机（一般是Nokia）来开发一个基础版本，然后在此基础上按照目标终端的大类做移植，再在大类的基础上做更细的移植，移植的过程如一颗树状展开，最后达到支持所有目标手机终端的目的。以下是一些开发和移植过程中的心得。

     MVC设计模式 模型－视图－控制器（Model-View-Controller，MVC）设计模式及其派生无疑是UI模型的最佳实践，手机应用软件上更是如此。不同手机的屏幕大小差异非常大，在手机客户端应用程序移植的过程中最大的困难就来自于UI界面的移植，MVC设计模式可以很好地使UI界面和程序的数据、控制相分离，从而把后期应用程序的移植这个难题基本控制在界面移植这个范围之内。 MVC设计模式这里就不介绍了，要注意的是整个应用程序大小的限制可能会约束设计模式的实现，即使是最小的类也会使整个应用程序的尺寸增大200字节。实际中可能需要减少类的层次来保持JAR文件在一个合理的大小范围之内，也尽量不要使用单独的类或者匿名类来做控制器，我们的实践中使用一个控制器类来处理所有的业务逻辑，虽然这个类看起来有点臃肿，但是在这种限制条件下，有时候不得不做这种让步。

     建立设备库资料库

       所谓磨刀不误砍材功，对于开发跨平台的应用来说，建立一个目标手机设备资料库非常重要，其中至少要包含我们的应用软件所要用到的各种终端能力特性。网上能查到各种手机终端所支持的Java API等资料，这很方便但是除了屏幕大小外有时候有些参数不可*，而手机设备的一个错误的参数或者BUG会耽误我们开发调试过程中大量的时间。根据我们的客户端应用程序所要用到的终端能力，可以做一个测试程序，用来测试各款手机终端对于这些能力的支持情况，例如：KJava平台的RMS存储限制、最大内存限制、程序所能使用的屏幕大小、支持本地播放的多媒体内容类型、支持网络在线播放的多媒体类型、对联网能力的支持、程序运行时系统对电话呼入的处理以及对Push Registry程序自启动的支持情况和表现等等。我们可以通过自己的测试工具来建立目标终端上的这些属性的资料库，并不断扩充。注意，以真机上运行的结果为准，很多时候模拟器的表现和真机的表现是不一致的，基本上模拟器普遍都存在“缺陷”。

       规范使用资源文件

        为了方便移植，可以将所有的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和互联网都是相当受限的。

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