J2ME的相关概念
作为一种跨平台的语言,Java近年来得到了广泛关注和快速发展,为了适应不同级别计算机硬件的开发需要,Java平台形成了三个分支,J2EE,J2SE和J2ME。
针对企业级应用的J2EE,是一个适合分布式的、多用户、企业级应用系统运转的平台,针对桌面应用的J2SE,针对移动终端领域的J2ME。
那么,到底什么是J2ME?简单来讲,J2ME是一个支持Java应用程序的运行环境,是为了支持象PDA、手机等小型的嵌入式或移动设备而推出的一系列的技术和规范的总称。
由于J2ME要支持的硬件平台有很大差异,其中有比较高端的设备,如机顶盒,也有比较低端的,如手机,因此为了满足不同硬件的开发要求,J2ME规定了Configuration(配置)的概念,Configuration对不同级别的硬件在所使用的虚拟机和基础API集合方面做了规定。对于高端的设备,采用CDC(Connected Device Configuration),对于低端设备,则采用CLDC(Connected Limited Device Configuration),旨在为只能获取有限连接的设备提供基础配置。
CDC和CLDC仅仅是对各类设备中最具共性的配置提供了基本的功能集合。在实际应用中,不同的设备之间仍旧存在着很大的差异性。因此,在Configuration的基础上,又提出了Profile(简表)的概念。Profile规定的内容,是针对某一类设备所制订的规范和API,有了Profile以后,才真正有了可以建立一个可运行J2ME应用程序的完整环境。MIDP(Mobile Information Device Profile移动信息设备简表)以CLDC为基础,它是第一个制订完成的Profile,也是第一个可供使用的J2ME应用程序运行环境。
总的来说,J2ME的技术组成,包括如下三个要素:
◆ 置(Configuration):为大部分移动终端提供了虚拟机的能力和最基础的函数库,如通信能力、联网能力;
◆ 表(Profile):位于Configuration之上,为移动终端提供了一系列API,通常包含显示所需的图形库;
◆ 选包(Optional Package):与特定技术相关的一系列API,如多媒体播放,蓝牙传输能力等。
图1是对以上内容的一个直观表示。
当前绝大部分手机都是基于CLDC+MIDP的配置,在这二者的基础之上,实现了各种不同的可选包,从而使得丰富多彩的Java应用运行在移动终端成为可能。
J2ME的规范体系介绍和现状
前面已经提到过,可以将J2ME理解为一系列的技术和规范的总称。那么这些技术规范是怎么产生的,又是由谁来维护的呢?由在国际上,有一个由Sun主导的标准化组织JCP(Java Community Process),该组织根据领域的不同,分为三个大的工作方向,即J2EE,J2SE和J2ME。而J2ME领域的标准的制定者,包括业界知名的运营商,如Vodafone,Orange,中国移动等;终端制造商,如Nokia,Motorola,Sumsung等;提供Java虚拟机的厂商,如IBM、Aplix、Esmertec等;以及一些感兴趣的公司团体。
JCP中的每个规范被称为JSR(Java Specification Request)。各个JSR分别从不同的角度对Java虚拟机的能力进行了规范,并对应一个数字编号,如JSR75规定了Java应用如何通过虚拟机提供的接口访问终端操作系统的PIM数据和文件系统。此外,还包括针对对蓝牙、多媒体、短信、彩信等的JSR。而这些规范的发布、更新和维护由JCP来统一管理,确保了让业界不同角色的厂商能够共同参与定义J2ME平台的能力,共同推进Java技术向前发展。
虽然Java是本着跨平台的目的而产生的技术,但是在移动终端领域却没能完全实现这一宏伟的目标。由于设备没有一个统一的标准的软件运行环境,导致了API的分裂。开发者在针对某些机型进行开发之前还必须要查询这个设备到底支持什么功能,有哪些是标准的API,哪些是可选包和厂商提供的API。这无疑给开发带来了不便,同时使得程序的可移植性大大降低。如果你得程序中使用了Nokia的API那么程序很难在其他厂商的机器上跑。所以,J2ME在不同的移动终端平台上由于实现的不同而造成的分裂局面成了待解决的问题。
J2ME发展的里程碑
为了解决如上的问题,在J2ME的发展过程中,产生了以下几个具有里程碑意义的JSR:
1. JSR185 -- JTWI(Java Technology of Wireless Industry)
该规范于2003年7月发布。JTWI并没有提出新的技术,也没有提供新的API,它对J2ME的运行环境作了规范,提供了一个标准的更加严格的运行环境,这有效地减小了API的分裂并提高了程序的可移植性。JTWI包含以下规范:
JSR30 -- CLDC1.0:提供了基本的语言类库,但是不支持浮点运算。可以用CLDC1.1替代1.0;
JSR118 -- MIDP2.0 :提供了图形用户界面、持久性存储、游戏和多媒体等功能模块的支持;
JSR120 – WMA (Wireless Messaging API):提供了短消息功能的支持
JSR135 – MMAPI (Mobile Media API):提供了对多媒体的全面支持,MIDP2.0中的多媒体部分是MMAPI的子集,该规范是JTWI中可选的部分。
JTWI的体系架构如图2所示。
2. JSR248 – MSA1.0 (Mobile Service Architecture 1.0)
该规范于2006年12月发布,由于JSR185是针对当时的市场状况而制定的,主要针对低端市场,而终端的硬件能力是一直不断的往前发展的,所以JSR248制定的初衷就是为了满足不断发展变化的市场需求,增加了能充分体现新上市的终端的硬件能力的需求。JSR248在JSR185架构的基础上,增加了新的JSR,在充分考虑到市场现状的同时,也对未来的市场发展做了预测,所以在规范的制定上留了一定的空间,延长了规范的生命周期。这些变化,在规范上具体体现在架构设计上。JSR248规定了两个级别的架构,MSA Subset和MSA,如图3所示。
除此之外,对其架构中包含的每一个JSR,MSA1.0都做了相应的澄清,例如,在CLDC中规定,分配给虚拟机的堆大小为32k字节,而随着终端能力的发展,32k字节的堆大小已经不再是瓶颈,而且这样的大小,已经不足以支持一些游戏和多媒体类应用的流畅运行,所以,在MSA1.0里面,对CLDC做了将堆大小调整为1024k字节的澄清,充分满足了应用的需求,同时也有利于Java业务的开展。
如果说图3是从终端能力的角度对JSR248进行了表示,那么图4则从不同功能的角度对JSR248进行了另一种表示,可以看出,JSR248在制定的过程中,比较全面的考虑到了多元化的功能,如安全和电子商务,图形处理,多种通信方式,用户的个人信息等。
J2ME编译技术的发展
因为Java语言的设计初衷是使用解释的方式支持应用程序的可移植性,早期 Java 运行时的性能级别远低于C和C++之类的编译性语言。而Java 应用程序的性能也经常成为讨论的热点。如图5所示,Java虚拟机每次遇到一条字节码指令,就将其转换成机器码,然后给CPU进行执行,执行完机器码之后,就把这些机器码丢了,接着再翻译下一条字节码的指令,继续下去,如此这般,自然效率低下。
近年来,为了提升Java的性能,在编译技术方面有了一些新的突破,这一节将介绍一些比较流行的编译技术。
1. JIT(Just In Time)编译方法
从传统的虚拟机处理字节码的过程可以看出,即使下次执行到以前执行过的 bytecode 指令,依然要重新翻译成机器码才能执行,如此一来,效率当然不好。JIT编译方法的原理是,程序运行时,JIT 编译器选择将最频繁执行的方法编译成本地代码。运行时才进行本地代码编译而不是在程序运行前进行编译(用 C 或 C++ 编写的程序正好属于后一情形),保证了可移植性的需求。
Java 运行时供应商开发了一些复杂的动态编译器,通常称作JIT(Just-in-time,JIT)编译器。程序运行时,JIT 编译器选择将最频繁执行的方法编译成本地代码,运行时才进行本地代码编译而不是在程序运行前进行编译(用 C 或 C++ 编写的程序正好属于后一情形),保证了可移植性的需求。以后再次执行到这里时,就不用再翻译,直接从内存取出机器码即可执行。这么一来,只要内存够大,JIT 编译器的技术够好,那么Java 字节码的执行速度也可以逼近纯编译式的语言。
2.AOT(Ahead Of Time)编译方法
虽然 JIT 编译技术已经能够提供与静态语言性能相当的性能水平,但是动态编译并不适合于某些应用程序,如 GUI 接口之类交互式应用程序就是这样的例子。在这些情况下,AOT编译可能是合适的解决方案。该方法的原理是,在程序执行前生成 Java 方法的本地代码,以便在程序运行时直接使用本地代码。目的在于避免 JIT 编译器的运行时性能消耗或内存消耗,或者避免解释程序的早期性能开销。
J2ME未来的发展趋势探讨
从本文的分析可以看出,不管是标准化组织、终端厂商、运营商,还是应用开发者,都在促进J2ME跨平台特性,减少各平台间的分裂性,繁荣Java应用方面,做出了不少努力。而作为Java业界的领头羊,Sun Micro Systems也计划打造一款整个操作系统都是由Java实现的纯Java终端,而arm公司也有推出专门针对Java 指令的加速芯片,通过硬件加速来提高Java的执行效率。由此可见,虽然目前J2ME还没有百分之百地实现跨平台性和执行的高效性,相信随着业界的共同努力,Java的发展空间会越来越大。