使Java代码可移植之二（转）

6.3 移植问题

这一节讨论一系列特定的移植问题，涉及UI（包括低级图像和高级UI组件）、可选的和第三方API以及下载大小限制。

为了创建能在一系列不同类型和功能的设备上运行的MIDlet，在MIDlet运行期间，识别设备的性能是非常有用的，这样它就能动态改变其行为，或者在提供MIDlet时，服务器能发送一个恰当的经过裁剪的JAR文件。

支持设备的运行期识别也是相当有限的：我们能使用System.getProperty()来识别JTWI或MIDP版本，并且我们可以使用Canvas.getHeight()、Canvas.getWidth()、Canvas.isDoubleBuffered，Display.isColor()和Display.numColors()来识别显示能力。

当前，当下载一个应用程序时，通常让用户点击手机上的链接来（例如，“BoyRacer for Sony Ericsson P800/P900”或“BoyRacer for Nokia 6600 or Series 60”）下载。然而，在每个HTTP处理期间，设备将自己的识别码加入用户代理字段（例如，“Sony Ericsson P900”或“Nokia 6600”），这能够被提供下载的服务器识别来发送恰当的JAR应用程序。针对设备识别的Composite Capability/Preference Profiles（CC/PP，参见www.w3.org/Mobile/CCPP）UAProf标准正在慢慢地形成，它将使提供下载的服务器能够获得一个手机的更详细的特性。

HTTP处理一个URI，它指向手机的详细信息，但是也能包含一些其他信息，这些信息能够标识出单个手机相对厂家标准可能进行了哪些修改。这就能使下载服务器为一个指定的手机动态创建一个量身定制的JAR文件。

通常，需要检查目标设备的设计标准并尽量服从这些标准。甚至开发者可能实现任何他们希望使用的低层GUI API，对用户而言，使用他们熟悉的界面会更容易。因此，对于不同的主机设备，尽可能地模拟菜单和命令的标准命名法。一些设备为用户提供一个一致的界面。例如，在Nokia手机上，右边的软键通常总是“导航”命令，如退出、后退和取消等，左边的软键用于“主动的”命令，如确定、选择和连接等。

6.3.1 低级图形内容

在游戏应用程序中，构成基本用户界面的便是图形内容。

尽管在一个游戏环境中，主要的Sprite一般都保持大小不变，但对于背景图像就不一定。背景构成了游戏的“世界”，并且随着屏幕尺寸不同而变化。例如，Nokia 6600显示像素为176×208，而Sony Ericsson P900显示像素为208×253，当显示软键盘时，尺寸变为208×173。

当UI被初始化后，需要使用Canvas.getHeight()和Canvas.getWidth()方法来查询设备屏幕的宽度和高度。这就为创建背景图像提供了足够的信息。使用TiledLayer时，我们能做以下两件事情：

· 我们能改变贴砖的大小来反映屏幕的尺寸。这最大限度地减少了对MIDlet的影响，虽然这对图形设计者增加了负担。更重要的是，游戏背景的贴砖可能变形。

· 我们能使TiledLayer更智能，在初始化时，通过查询设备屏幕尺寸，对背景作出合适的更改。新的贴砖背景的尺寸取决于单个的贴砖和屏幕尺寸。这种更好的方式允许我们调整视角来反映不同的屏幕尺寸，使MIDlet允许用户在一个较大的设备上有一个较大的游戏世界的视图。例如，一个迷宫游戏应当显示更多的迷宫。7.14节的LifeTime MIDlet就使用了这种方式，以在大屏幕设备上显示更多的游戏空间。

用于创建游戏的图像通常要根据目标手机的屏幕特性来裁剪，可能还要根据手机的内存和性能特性来裁剪。它们甚至要根据下载的JAR文件大小的限制来进行更改。因此我们需要针对一些手机采用小的黑白图像，但是对有更大处理能力的彩屏手机，（应当）采用更大的彩色图像。这需要针对每一个或者一组目标设备创建各自的JAR包。

MIDP 2.0的更有用的新特性就是游戏API。它允许通过一个包含所有帧的图像文件为一个角色或屏幕对象创建一个Sprite。在第5章的Racer MIDlet示例中，我们提供了一个4帧的序列，其中封装了动画所必需的所有帧。

Sprite的子类使用一个PNG文件初始化，并且根据自身已知的尺寸创建帧。这意味着如果屏幕尺寸改变而帧的数量不变，我们可以改变帧序列而不是改动代码，使得Sprite仍然保持比例。

我们已经讨论了改变图像以适应设备的必要性，但是Sprite可能也需要改变。如果Sprite类足够智能，能检测到它们自身的尺寸改变，那么一切将工作得很好。然而，它们可能会以不同的方式移动，这就需要改变移动的方法。Sprite间的碰撞检测也可能改变。例如，一个更小的图像可能需要一个更小的碰撞检测区。在一些情况下，使用整个图像来进行碰撞检测的处理太耗费时间，因此我们要使用defineCollisionRectangle()方法来定义一个更小的区域。Sprite大小的改变可能意味着其碰撞检测区也要随之改变。

屏幕尺寸的改变可能需要更少的Sprite的副本。可能会有更小的空间来显示敌方角色，或者那些应该出现在屏幕上的Sprite落在了屏幕外。例如，在一个典型的Space Invaders游戏中，较小的屏幕尺寸可能意味着较少的攻击玩家角色的敌人。你希望在更大的屏幕上得到更多的攻击和子弹吗？你认为在不增加游戏难度的情况下，MIDlet应该在初始化时计算出多少次攻击是合适的吗？应该隐藏更少的或更小的障碍吗？这些值可能被硬编码在Sprite类的成员变量中。考虑创建一个资源包来提供这些值，或者将它们添加到JAD文件，使MIDlet能够在启动时查询到它们，这是不是更明智？

尽可能地使用游戏动作。它提供了一个通用的游戏动作的映射，比如开火、上、下、左、右等，可以很容易地在键盘上实现，如对应2、8、4和6。一些键盘有不同的布局，比如MIDP 1.0手机Siemens SX-1，可能以不同的方式映射这些动作。甚至像Sony Ericsson P900这样主要使用基于操纵杆的设备，其操纵杆也能被用于游戏动作的向上和向下。游戏设计可能需要简化，或者可以使用可卷动的Choice列表作为游戏菜单让用户选择。

一些设备提供了持续检测一个键的状态是否为“按下”或“释放”的能力。持续检测一个键当前是否被按下使我们能给予用户“快速开火”的能力。不是所有的设备都有这个功能，因此需要注意。

6.3.2 输入方式的不同

开发者需要意识到，不同的设备有不同的输入方式。至少，他们需要编写保护式的代码以允许不同的输入方式。为一个指针设备或一个键盘设备进行测试是明智的。例如，如果一个MIDlet是针对Sony Ericsson P900的，那么需要将按钮置于屏幕上，并需要更大的图像使得用户选择时更加方便。在一个键盘设备上，例如Nokia 6600等，用户就要依赖操纵杆来导航，并且需要自动选中项目。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10294527/viewspace-126956/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10294527/viewspace-126956/