Java ME(Java 2 Micro Edition）是Java 2的一个组成部分，与J2SE、J2EE并称。与J2SE和J2EE相比，JAVA ME总体的运行环境和目标更加多样化，但其中每一种产品的用途却更为单一，而且资源限制也更加严格。为了在达到标準化和兼容性的同时儘量满足不同方面的需求，JAVA ME的架构分为Configuration、Profile和Optional Packages（可选包）。它们的组合取捨形成了具体的运行环境。

Configuration主要是对设备纵向的分类，分类依据包括存储和处理能力，其中定义了虚拟机特性和基本的类库。已经标準化的Configuration有- Connected Limited Device Configuration（CLDC）和Connected Device Configuration(CDC）。

Profile建立在Configuration基础之上，一起构成了完整的运行环境。它对设备横向分类，针对特定领域细分市场，内容主要包括特定用途的类库和API。CLDC上已经标準化的Profile有Mobile Information Device Profile (MIDP）和Information Module Profile（IMP），而CDC上标準化的Profile有Foundation Profile(FP）、Personal Basis Profile(PBP）和Personal Profile(PP）。

可选包独立于前面两者提供附加的、模组化的和更为多样化的功能。目前标準化的可选包包括资料库访问、多媒体套用、蓝牙等等。

根据Sun的定义：Java ME是一种高度最佳化的Java运行环境，主要针对消费类电子设备的，例如蜂窝电话和可视电话、数字机顶盒、汽车导航系统等等。JAVA ME技术在1999年的JavaOne Developer Conference大会上正式推出，它将Java语言的与平台无关的特性移植到小型电子设备上，允许移动无线设备之间共享应用程式。

今天，不止是桌面上的电脑，手中的电话、汽车中的通信设备、家中的冰柜、洗衣机等都将连入网际网路，这是一个移动的网际网路。J2ME（Java2平台微型版）就是Java程式在这些连线设备上的执行平台和开发环境，其基本思想和J2SE类似，就是在各种设备上安装适合它的Java虚拟机，应用程式则在虚拟机之上运行。

Java本来就是为了嵌入式系统而生，1990年12月，Sun公司内部由James Gosling、Patrick Naughton以及Mike Sheridan成立了一个叫做Green Team的小组。Green Team小组的主要目标，是要发展一种新架构，而这种架构必须能够在消费性电子产品作业平台上运行，现在我们普遍认识的PDA、手机或是信息家电（IA），都是属于这种架构的目标平台。虽然在1999年，Java被分割成J2ME、J2SE、J2EE，所以有了J2ME这个名词的出现。但是Java并非1999年才开始发展嵌入式系统上的套用。其实，Java本来就是为了嵌入式系统而发展的一种架构。即使目前大家多半将Java的套用聚焦于企业上的J2EE套用。但是严格来说，J2ME才是Java真正“回归本心”的领域。

Sun公司将J2ME（Java 2 Micro Edition）定义为“一种以广泛的消费性产品为目标的、高度最佳化的Java运行时环境”。J2ME是Sun公司为嵌入式开发所定义的一个框架，由一系列标準的规範组成。所以J2ME是一系列技术规範的总称，而不是单一的规範。

J2ME的所有技术标準都由JAVA社区过程（Java Community Process，JCP）制定，JCP是一个开放的国际组织，主要由Java开发者以及被授权者组成，职能是发展和更新Java技术规範、参考实现（RI）、技术兼容包（TCK）。Java技术和JCP两者的原创者都是SUN计算机公司。

JCP维护的规範包括J2ME、J2SE、J2EE、XML、OSS、JAIN等。组织成员可以提交JSR（Java Specification Requests），通过特定程式以后，进入到下一版本的规範里面。

J2ME使用配置（CDC或CLDC）和简表（Profile）定製JRE，一个完整的JRE由配置和简表组成，配置决定了所使用的JVM（可能是CVM或KVM），而简表通过定义特定的类来为应用程式提供功能上的支持，一个简表定义了设备所提供的API集合。例如：CLDC规範目前分为v1.0 JSR 30、v1.1 JSR 139；CDC规範目前分为v1.0 JSR 36、v1.1 JSR 218；MIDP规範目前分为v1.0 JSR 37、v2.0 JSR 118。

J2ME 在设计其规格的时候，遵循着「对于各种不同的装置而造出一个单一的开发系统是没有意义的事」这个基本原则。于是 JAVA ME 先将所有的嵌入式装置大体上区分为两种 ：一种是运算功能有限、电力供应也有限的嵌入式装置（比方说PDA、手机）；另外一种则是运算能力相对较佳、并且在电力供应上相对比较充足的嵌入式装置 （比方说冷气机、电冰柜、电视机顶盒 (set-top box））。因为这两种型态的嵌入式装置，所以Java 引入了一个叫做Configuration 的概念，然后把上述运算功能有限、电力有限的嵌入式装置定义在Connected Limited Device Configuration(CLDC）规格之中；而另外一种装置则规範为 Connected Device Configuration(CDC）规格。也就是说， JAVA ME 先把所有的嵌入式装置利用Configuration 的概念区隔成两种抽象的型态。

Java ME书籍

其实在这里大家可以把Configuration 当作是JAVA ME 对于两种类型嵌入式装置的规格，而这些规格之中定义了这些装置至少要符合的运算能力、供电能力、记忆体大小等规範，同时也定了一组在这些装置上执行的 Java 程式所能使用的类别函式库、这些规範之中所定义的类别函式库为 Java 标準核心类别函式库的子集合以及与该型态装置特性相符的扩充类别函式库。比方就CLDC 的规範来说，可以支援的核心类别函式库为java.lang.* 、java io.*、java.util.*，而支援的扩充类别函式库为javamicroeditionio.*。区分出两种主要的Configuration 之后，JAVA ME 接着在定义出Profile的概念。Profile 是架构在Configuration 之上的规格。之所以有Profile的概念，是为了要更明确地区分出各种嵌入式装置上Java 程式该如何开发以及它们应该具有哪些功能。因此Profile 之中定义了与特定嵌入式装置非常相关的扩充类别函式库，而 Java 程式在各种嵌入式装置上的使用者介面该如何呈现就是定义在Profile 里头。Profile 之中所定义的扩充类别函式库是根据底层Configuration 内所定义的核心类别函式库所建立。

我们先从整体上了解J2ME在运行中Java程式、Profile（MIDP是其中的一类描述）、Configuration（CLDC是其中的一类配置）、虚拟机、作业系统以及实体机器之间的关係，即J2ME的运行环境。

· MID：移动信息设备硬体；

· 原生代码的系统软体：包括作业系统和系统使用的库档案；

· CLDC：包括KVM和由CLDC规範定义的相关库函式，CLDC是MIDP和OEM特定类的基础；

· Java API：这部分提供上层所需的最底层Java功能；

· MIDP：一个Java API集合，处理诸如用户界面、持久存储和网路等方面的问题；

· OEM特殊类：扩展了MIDP所定义的功能，这些类可能由OEM为某一给定的设备提供，是不可移植的。

（1）KVM

KVM是一个紧凑的、可移植的Java虚拟机，专用于小型的资源受限的设备，如蜂窝电话、寻呼机、个人组织机、移动网际网路设备、POS终端和家用电器等。KVM设计的高级目标是生成儘可能小且完整的Java虚拟机，它需要维护Java核心语言所有的核心方面，并且仍能在资源受限的设备中运行，儘管它只有几十或几百千位元组的存储空间。

KVM设计的目标：

· 小，虚拟机核心所占用的静态存储空间在40～80 KB之间（与编译选项和目标平台有关）；

· 清晰的，具有良好的注释和高可移植性；

· 模组化，可定製；

· 在不牺牲其他设计目标的前提下，儘可能的“完整”和“快”。

KVM实现所需的最小记忆体空间大约是128 KB，包括虚拟机、最小的库和运行Java应用程式所需的堆空间。一个更加典型的实现是需要总共256 KB记忆体空间，其中32KB作为应用程式运行时的堆空间，60KB～80KB用于虚拟机本身，剩余的为类库保留。由于受到严格的记忆体容量限制，KVM缺乏JVM所提供的完整特性。使用CLDC的开发者在编译程式之后必须预先採用J2ME开发工具包所提供的一种检查工具对它们的原始码进行预校验。

Sun的KVM参考实现可以在Solaris和Windows两个平台上进行编译和测试，这两个平台都可用于KVM的开发、调试、测试和使用。它们包含了大量的开发工具，并且由于强大的工作站级性能，因而能够快速地进行KVM的移植和开发。Solaris和Windows版本的KVM作为基本的官方CLDC参考实现，可被用户移植到特定的设备之上。

由于KVM是一个支持CLDC库的后台Java虚拟机，因此，CLDC中不支持的性能在KVM中也不支持。这些不支持的性能包括：浮点支持、最终化支持以及设备特定的错误管理。除此之外，由于J2ME提供了有限的Java安全模型版本，因此一些可能会造成安全问题的性能也被KVM所删除，这些性能包括：Java本地接口（JNI），用户自定义类装载器，反射、RIM或对象序列化，执行绪组或Daemon执行绪，以及弱引用等。

（2）CLDC/CDC

可用的Configuration有两个：CDC和CLDC设备。CDC设备主要面向有较大记忆体和较强处理器的移动设备；CLDC设备则主要面相向较小记忆体和小萤幕、较弱处理器的移动信息设备。同时，CLDC和CDC的大部分功能都继承自J2SE，每个继承自J2SE平台的类，不是等价于J2SE相应的类，就是J2SE的子集，而且CLDC和CDC还加入了一些自身特有的特性。

CLDC：这个配置致力于低端的消费类设备。从设备的用途和功能角度看，它针对的设备主要包括个人的、移动的、电池供电的、互联的信息设备，如手机、PDA和POS机，其特点是无线连线，没有稳定的电源供应（通常使用电池）、设备资源极少。从设备的硬体功能角度看，它主要针对16bit、32bit，主频在16MHz以上的处理器，设备的记忆体比较小，可能小于512 KB。这个配置包括一些新的类，并非全部来自J2SE的API，而是特别为适应小型设备而设计的。

CDC：这个配置致力于高端的消费类产品。从设备的用途和功能角度看，它针对的设备主要包括共享的、互联的信息设备，如电视机机顶盒、Internet电视和高端的通信设备，其特点是有线连线、电源稳定、设备资源比较受限。从设备的硬体功能角度看，它主要针对32 bit，主频在75 MHz以上的处理器，记忆体可能在1～4 MB。这个配置包含了比CLDC更加複杂的Java库和虚拟机的集合。

（3）MIDP

区分出两种主要的Configuration之后，J2ME接着定义了Profile的概念。Profile是架构在Configuration之上的规格。之所以有Profile的概念，是为了更明确地区分出各种嵌入式设备上Java程式该如何开发以及它们应该具有哪些功能。因此，Profile之中定义了与特定嵌入式设备非常相关的扩充类函式馆，而Java程式在各种嵌入式设备上的用户接口该如何呈现就是定义在Profile里的。Profile之中所定义的扩充类函式馆是根据底层Configuration内所定义的核心类函式馆所建立的。

从CLDC所衍生出来的Profile主要有两种，一种是PDA Profile，大多数用在PDA上；而另外一种是Mobile Information Device Profile（MIDP），这个Profile是针对移动设备所定义的，如寻呼机（Pager）、行动电话等，都是属于移动设备。i-mode是日本电信（NTT）的子公司DoCoMo在日本市场推出的无线通信服务，相应于MIDP中的MIDlet，i-mode把其专用的J2ME应用程式称为i-Appli。

另外，我们可以看出Embedded Java与Personal Java没有包含在两个Configuration的任何一个底下，但它们还是归类在J2ME的範畴之中，而且也衍生出了Java的实时版本（Real time Specification for Java）。其实Embedded Java与Personal Java会慢慢被架构在CDC之上的Profile所取代。就Personal Java来说，它的规格与Personal Profile的规格是兼容的。之所以目前还存在Embedded Java与Personal Java这两个名词的主要原因在于，市场上已经有大量採用这两种规格的产品，所以短期内Personal Java仍然会不断发展，一时间还无法立刻归类到J2ME的特定Profile之下。

MIDP1.0包含以下7个包，其中前4个是CLDC核心包，后3个是MIDP特有的包。

·java.io；

·java.lang；

·java.util；

·javax.microedition.io；

·javax.microedition.lcdui；

·javax.microedition.midlet；

·javax.microedition.rms。

一个MIDP应用程式称作MIDlet——MIDP小应用程式，这个概念与J2SE中的Applet十分类似。它们不能单独运行，都必须运行在特定的运行环境之中，或者说运行在一个容器中。可以把这个容器看作是个大的应用程式，它运行在Java虚拟机之上，但不能完成任何特定的任务，因此需要程式开发者编写代码以完成一项工作，这些编写的程式就称作小应用程式。这样设计的目的是为了让它能在所有的容器中运行，这些容器实现可能不同，但它能运行在多种环境中。容器的作用就是适配小应用程式和它的大运行环境之间的差异。MIDlet中这个容器就是MIDP实现，它以Sun公司发布的CLDC规範和MIDP规範为标準，然后针对设备进行移植，从而提供给所有MIDlet都一样的容器内部接口。MIDP实现提供了一套机制用来管理MIDlet，如运行、暂停、销毁等。因此对MIDP小应用程式来说，也应该遵照一个标準，如必须实现一定的接口套用管理软体才可识别并调用它。

编写MIDP应用程式的要求就是必须扩展MIDlet类，这个类定义了一些接口，套用 管理软体可以通过这些接口对MIDlet进行控制。MIDlet类位于javax.microedition.midlet包中，因此，在所有的MIDlet中，都必须引入这个包javax.microedition.midlet.*。

J2ME并没有为移动设备定义一个全新的作业系统或完整的系统软体栈，而是从满足消费者和嵌入式市场弹性和定製需求角度出发，採用模组化、可扩展性设计。J2ME技术这种模组化和可扩展性是通过一个3层软体模型来实现的，这个3层软体模型构建于设备本地作业系统层之上。

（1）主机作业系统层

这一层为移动信息设备的作业系统，通过它可以直接控制硬体设备，实现硬体设备的功能。

在最底层的是移动设备的主机作业系统，目前主要有Symbian、Windows Mobile、Linux和Palm 4大手机作业系统。Symbian公司是由诺基亚、摩托罗拉、西门子等几家大型移动设备製造商共同出资组建的合资公司，专门研发手机作业系统。Symbian作业系统在智慧型移动终端上拥有大量的应用程式以及强大的通信处理能力，它有一个非常健壮的核心：强大的对象导向系统、企业用标準通信传输协定以及完美的Sun Java语言支持。Windows Mobile包括Pocket PC、SmartPhone以及Pocket PC Phone 3大平台体系。此系列作业系统功能强大，具备音频播放、视频档案播放、上网冲浪、MSN聊天和电子邮件收发等功能。Windows Mobile是在Windows作业系统上变化而来的，它们的操作界面非常相似，因此，採用此作业系统的手机方便易用。由于Windows Mobile本身对资源的巨大吞噬作用，所以在能耗方面，Windows Mobile系统要明显逊于其他作业系统。Linux手机作业系统是由计算机Linux作业系统“变化”而来的。Linux作业系统具有稳定、可靠、安全等优点，有强大的网路功能。Linux凭藉其自由、免费、开放原始码的优势，已经得到众多知名厂商的支持。Palm作业系统是由Palm公司自行开发的，并授权给Handspring、索尼和高通等设备厂商。Palm是一种32 bit的嵌入式作业系统，主要运行于移动终端上。这种作业系统是一种更倾向于PDA的作业系统。

（2）Java虚拟机层（JVM）

这一层是针对设备本地作业系统定製的Java虚拟机的实现，支持特定的J2ME配置。Java语言的一个非常重要的特点就是与平台的无关性。而使用Java虚拟机是实现这一特点的关键。JVM以软体的形式实现了硬体的功能，是硬体的软体抽象，可以认为，JVM就是J2ME软体化的处理晶片。由虚拟机直接负责和移动设备的接口，而J2ME应用程式只能和JVM打交道。

（3）配置层（Configuration）

配置层对用户来说是能见度不高的一层（比较透明）。但是对简表的实现却非常重要。它定义了某一类设备所用的Java虚拟机和Java类库的最小集合，这类设备代表了某一特定水平市场，在某种程度上，配置定义了这一範围内能套用于所有设备的Java平台功能和类库的“最小公分母”。

Configuration规範中定义了硬体所必须具备的能力，例如：硬体至少具备多少ROM、RAM，CPU的时钟周期最少应该是多少，连线网路时频宽至少要多宽。Configuration规範之中定义了一组低级的API，这代表Java至少必须提供的低级功能，这组低级的API就是核心类库的子集合。由于消费性电子产品的差异性极大，Sun认为对于不同硬体特性的电子产品，应该有不同的设计规格，因此，Configuration针对硬体的数据处理能力、存储容量、网路连线能力和用户输入输出设备将这些电子产品区分为不同的类。目前已经定义出来的Configuration有两种，分别是CDC（Connected Device Configuration）与CLDC（Connected Limited Device Configuration），前者包含的设备对硬体资源的支持较大，例如网路电话、Set-top Box、车用计算机等，后者则可以涵盖一般的个人移动设备，如手机及PDA等。Configuration除了定义硬体支持程度之外，还定义了对Java语言所支持的程度、对Java Virtual Machine所支持的程度和对核心类库所支持的程度。

（4）简表层（Profile）

对用户和套用开发者来说，简表层是能见度最高的层。它定义了能够套用于某一类设备上的API的最小集合，这一类设备代表了一定的垂直市场。简表都是在某一特定配置基础之上的实现，针对某一简表开发的应用程式可移植到任何设备，只要此设备也支持这个简表。另外，一个设备可以同时支持多个简表。在J2ME设备中，Java虚拟机的实现和构建于虚拟机之上的配置规範联繫十分紧密，它们一起代表了某一种类设备的基本能力。而更进一步的设备分类上的区别是通过简表层所提供的API规定的。为了满足更多新的、激动人心的套用的需要，简表可以通过扩充类库来增强自己的功能。

Profile针对各种不同机器的特性定义了高级API，这些高级API通常都是与其他平台不相关的扩充类库。这些高级API决定了该种机器上Java程式的撰写方法，例如移动通信设备（手机、PDA等）上Java程式的撰写方式，以及能够调用的API都定义在MIDP（Mobile Information Device Profile）之中。

（5）可选包（Optional Package）

Optional Package是指这是一组和其他规範（或API）没有任何依存性的类库，如果厂商愿意提供这样的功能给程式设计师（通常是因为硬体具有充分的能力可以完成规範之中所制定的功能），就会将这组类库实现出来，程式设计师也可以利用这些类库开发出功能更多的应用程式。

我们知道，任何Java程式都是在JVM中被执行的。那幺对于J2ME来说，情况又是如何呢？CDC仍然使用与J2SE相同的JVM，对于CLDC，由于设备资源受到限制，Sun专门开发了一个新的名叫KVM（K Virtual Machine）的虚拟机。这是个不同于传统的Java虚拟机：

● 虚拟机本身仅仅需要40-80KB记忆体；

● 只需要20-40KB动态记忆体（堆）；

● 能够运行在16位25MHz处理器上。

当然KVM只是一个由Sun实现的符合CLDC规範的Java虚拟机而已，它并不是唯一的，还存在很多类似的虚拟机，你也完全可以自己实现一个这样的虚拟机，只要它符合CLDC规範就可以。

开发Java ME程式一般不需要特别的开发工具， 开发者只需要装上Java SDK 及下载免费的 Sun Java Wireless Toolkit 2.xx系列开发包，就可以开始编写Java ME程式，编译及测试， 此外目前主要的IDE(Eclipse及 NetBeans）都支持 Java ME 的开发，个别的手机开发商如 Nokia、Sony Ericsson、摩托罗拉、Android系统 都有自己的SDK， 供开发者再开发出兼容于他们的平台的程式。

Java开发工具

手机游戏可以根据游戏本身的不同，而分成文字类游戏和图形类游戏两种。

文字类游戏：

文字类游戏是以文字交换为游戏形式的游戏。这种游戏一般都是通过玩家按照游戏本身发给您的手机的提示，来回复相应信息进行的游戏。举一个简单的例子，目前很知名的简讯游戏“虚拟宠物”就是典型的文字类游戏。在游戏中，游戏服务商会给您一些简讯提示，比如服务商可能会给你传送如下简讯“您的宠物饥饿度：70，饑渴度：20，疲劳度：20，餵食请回复内容为数字‘1’的信息，餵水请回复内容为数字‘2’的信息，休息请回複数字‘3’……”等等，那幺，您回複数字“1”之后，游戏会给您回一个信息“您的宠物已经餵食完毕，您的宠物的饥饿度变为20”，如此类推，您便可以通过手机简讯的方法来进行游戏了。

文字类游戏主要分为两种：

a，简讯游戏:

就好像“虚拟宠物”那样。简讯游戏是通过玩家和游戏服务商通过简讯中的文字的内容来交流，达到进行游戏的目的的一种文字游戏。

由于简讯游戏的整个游戏过程都是通过文字来表达，造成简讯游戏的娱乐性较差。但是简讯游戏却是兼容性最好的手机游戏之一。只要您的手机可以发简讯，您就可以畅快的享受简讯游戏给您带来的快乐了。

b，wap浏览器游戏:

wap是一种手机拨接的网路服务。而wap浏览器游戏就好像我们用电脑上网，并通过浏览器浏览网页来进行的简单游戏一样，也属于一种文字游戏。其进行方法和简讯游戏类似，玩家可以根据wap浏览器浏览到的页面上的提示，通过选择各种不同的选项的方法来进行游戏。wap游戏也有简讯游戏不够直观的缺点。

综观文字类游戏，其都有着一个共同的特点，即游戏是通过文字描述来进行的。游戏过程中，需要玩家进行过多的想像，使得游戏相对比较单调。虽然目前已经有了彩信等特殊服务可以让这类游戏更加人性化，但是其本质依然无法改变。而且，对于文字类游戏来说，其不低的价格门槛依旧是制约其发展的一大瓶颈。

图形类游戏：

图形类游戏更接近我们常说的“电视游戏”，玩家通过动画的形式来发展情节进行游戏。由于游戏採用了更为直观且更为精美的画面直接表现，因此图形类游戏的游戏性和代入感往往较文字类游戏高。因此广受玩家们的欢迎。

图形类游戏主要分为：

a，嵌入式游戏：

嵌入式游戏是一种将游戏程式预先固化在手机的晶片中的游戏。由于这种游戏的所有数据都是预先固化在手机晶片中的，因此这种游戏无法进行任何修改。也就是说，您不能更换其它的游戏，只能玩您的手机中已经存在的游戏，且您也不能将它们删除。

诺基亚早期手机中的“贪吃蛇1.2”就是嵌入式游戏的典型例子。

b，可变安装式游戏：

用户可以通过GPRS，3G网路或者电脑等方式，下载Java ME手机游戏安装到自己的手机里，这是现在比较流行的趋势，使自己的手机拥有更多的游戏套用，百玩不厌。

java是一种程式语言，具体是什幺程式语言我们完全没有必要知道。作为游戏一族，我们只需要知道两件事：

第一，您的手机是否支持java，要了解这一点您可以查阅您的手机的说明书，或者直接询问经销商。

第二，您挑选的java游戏是否支持您的手机，要了解这一点，您可以参阅“为什幺手机游戏也会有兼容性问题”以及“如何从游戏下载符合您的手机型号的手机游戏”部分。

c，brew游戏

我们也不用知道brew是什幺东西，要使用brew，您只需要了解您的手机是否支持它就可以了。目前，只有cdma的手机才支持brew，但是同时，cdma也支持java，于是为了减小成本，一般的开发商还是愿意选择基于java的游戏进行开发。因此，brew支持的游戏还不是很多。

d，uni-java游戏

uni-java是中国联通刚刚为其手机準备的一个新的通用开发平台，目前还处于开发阶段，还没有基于uni-java的手机推出。但是在不久的将来，uni-java必将是联通的一把利器。

记忆体占用主要有两种，即程式和资源。

类会被编译成class位元组码档案随MIDlet的启动载入进记忆体，而且是一次性全部加入。也就是说MIDlet里类个数越多、单个类程式越长、类内字元串常量及数据越多，编译后的class档案就越大，载入后占用的记忆体也越多。我经常在MIDlet类的构造函式里用Runtime方法来查看MIDlet启动后整个程式占用记忆体量。

最佳化方法：

⒈将MIDlet程式写成两个类来减少记忆体占用量，但是以牺牲Java的OOP特性为代价的。在程式比较大时这种弊端将尤为显见。而且CoCoMo曾经遇到过单个类过大，载入时间过长而违反百宝箱有关Logo 6秒时间限制的情形。

⒉儘量编写优雅的代码，减少函式数量，在程式发布时去掉try catch，最大限度的减少程式行数，这一般都是在老40上没有办法的办法，现在CoCoMo已经不靠这个来省记忆体了。

⒊将数据及字元串写进档案，在用时方载入记忆体，不用时设为null。

⒋I/O操作getClass().getResourceAsStream(file）；、资料库操做RecordStore.openRecordStore(name,true）；、声音创建Manager.createPlayer()；、图像创建Image.createImage(file）；会在短时间内占用大量记忆体且过后释放，如果MIDlet程式记忆体剩余量不足则会在这些函式频繁调用时发生记忆体溢出，产生所谓的记忆体峰值，尤其在老40上比较普遍。当再次与OutOfMemoryError碰面时，多用Runtime查找记忆体峰值发生位置并儘量将这些语句分开调用，并灵活运用System.gc()来及时回收。

图片：是占用记忆体的大户，尤其是手机游戏图片资源众多。对图片资源在记忆体中占用量的计算成为J2ME游戏开发者的经常性工作，CoCoMo来解释一下如何计算图片在记忆体中的占用量：

记忆体占用量=宽*高*像素位元组数，其中像素位元组数因机型而异。

例如一张64*64的图片在7210上的记忆体占用量=64*64*1.5=6144(位元组)=6K、在S60上的记忆体占用量=64*64*2=8192（位元组）=8K。像素位元组数因机型而异，例如7210是4096色机型，也就是说用12位来表示一个像素，所以乘上1.5，而S60是65536色的机型，用16位来表示一个像素，所以乘上2。

最佳化方法：

认为压缩图片可以节省记忆体，这种想法是错误的。根据上面的解释图片载入记忆体后只和宽高有关係，和图片数据量大小没有任何关係，压缩图片只能减少jar大小而不能减少记忆体占用量。

⒈静态法：减小图片大小，宽高小了结果当然小了。根据这个思路出现了动画编辑器之类的工具，像gameloft的波斯王子，人物被分割后使人体的部位可以重用，各部位紧凑放置都是为了减少图片大小，充分利用图片中的每一寸空间。

⒉动态法：减少同一时刻载入记忆体的图片数。CoCoMo曾经在火影武士项目中遇到过这种情况，当时有6种怪物，如果同时载入记忆体在老40上肯定爆掉了，但是每关只出现两到三种怪物，所以每一关只需要载入该关出现的怪物图片即可。现在想起来当时做这个项目在老40上溢出频出，真把我搞死了。

声音：声音也是比较耗用记忆体的资源，声音中音轨所占的byte会转化成位元组流被载入到记忆体中。因而减少音轨所占byte即可减少记忆体耗用量。目前gameloft的做法是用声音转化工具将mid转化为ott，然后变为ByteArrayInputStream位元组流来创建Player。

得到一个证书后就可以对Java ME的jad档案进行签名。这里有一些与签名相关的需要注意的一些问题。

⒈想要安装签过名的软体，就必须通过jad来安装。

我们知道Java ME程式生成后会有jad和jar两个档案，一般情况下我们只需要安装jar档案就可以了。例如我会将jar档案通过蓝牙传到手机上，再进行安装。但如果想通过手动安装签过名的档案，就要通过jad来安装，而且要确保jad和jar档案是在相同目录下。我的做法是通过数据线将两个档案拷入手机的记忆体或存储卡上，然后通过jad来安装，这样安装好的软体就是签过名的软体了。不会再有总是很烦人的询问用户是否允许操作的提示信息。

但就我看过的手机看来，应该是不同的手机有不同的表现。例如索爱的手机关于提示仍然是需要用户自己设定的。诺基亚也是。只是诺基亚的在使用非签名软体时用户无法设定为“总是允许”或“只提示一次”。而签了名的就可以设定了。

⒉编程人员需要注意，像很多功能在未签名前是可以使用的，例如gps，网路连线，档案读写等。

⒊签过名的软体有什幺好处。

签名就是告诉我们这个软体是可信的，对用户最直接的感受就是联网或访问手机档案的时候，收发简讯，彩信，蓝牙等，但签名后这些功能就不可用了。

这就是jad中MIDlet-Permissions属性的问题。当未签名时对这个属性的要求并不严格，但签名后就一定要注意。必须把所要使用到的许可权加入进去，否则这个功能就不能使用了。