透視Java手機(jī)終端技術(shù)發(fā)展
J2ME的相關(guān)概念
作為一種跨平臺的語言,Java近年來得到了廣泛關(guān)注和快速發(fā)展,為了適應(yīng)不同級別計算機(jī)硬件的開發(fā)需要,Java平臺形成了三個分支,J2EE,J2SE和J2ME。
針對企業(yè)級應(yīng)用的J2EE,是一個適合分布式的、多用戶、企業(yè)級應(yīng)用系統(tǒng)運轉(zhuǎn)的平臺,針對桌面應(yīng)用的J2SE,針對移動終端領(lǐng)域的J2ME。
那么,到底什么是J2ME?簡單來講,J2ME是一個支持Java應(yīng)用程序的運行環(huán)境,是為了支持象PDA、手機(jī)等小型的嵌入式或移動設(shè)備而推出的一系列的技術(shù)和規(guī)范的總稱。
由于J2ME要支持的硬件平臺有很大差異,其中有比較高端的設(shè)備,如機(jī)頂盒,也有比較低端的,如手機(jī),因此為了滿足不同硬件的開發(fā)要求,J2ME規(guī)定了Configuration(配置)的概念,Configuration對不同級別的硬件在所使用的虛擬機(jī)和基礎(chǔ)API集合方面做了規(guī)定。對于高端的設(shè)備,采用CDC(Connected Device Configuration),對于低端設(shè)備,則采用CLDC(Connected Limited Device Configuration),旨在為只能獲取有限連接的設(shè)備提供基礎(chǔ)配置。
CDC和CLDC僅僅是對各類設(shè)備中***共性的配置提供了基本的功能集合。在實際應(yīng)用中,不同的設(shè)備之間仍舊存在著很大的差異性。因此,在Configuration的基礎(chǔ)上,又提出了Profile(簡表)的概念。Profile規(guī)定的內(nèi)容,是針對某一類設(shè)備所制訂的規(guī)范和API,有了Profile以后,才真正有了可以建立一個可運行J2ME應(yīng)用程序的完整環(huán)境。MIDP(Mobile Information Device Profile移動信息設(shè)備簡表)以CLDC為基礎(chǔ),它是***個制訂完成的Profile,也是***個可供使用的J2ME應(yīng)用程序運行環(huán)境。
總的來說,J2ME的技術(shù)組成,包括如下三個要素:
◆ 置(Configuration):為大部分移動終端提供了虛擬機(jī)的能力和最基礎(chǔ)的函數(shù)庫,如通信能力、聯(lián)網(wǎng)能力;
◆ 表(Profile):位于Configuration之上,為移動終端提供了一系列API,通常包含顯示所需的圖形庫;
◆ 選包(Optional Package):與特定技術(shù)相關(guān)的一系列API,如多媒體播放,藍(lán)牙傳輸能力等。
圖1是對以上內(nèi)容的一個直觀表示。
當(dāng)前絕大部分手機(jī)都是基于CLDC+MIDP的配置,在這二者的基礎(chǔ)之上,實現(xiàn)了各種不同的可選包,從而使得豐富多彩的Java應(yīng)用運行在移動終端成為可能。
J2ME的規(guī)范體系介紹和現(xiàn)狀
前面已經(jīng)提到過,可以將J2ME理解為一系列的技術(shù)和規(guī)范的總稱。那么這些技術(shù)規(guī)范是怎么產(chǎn)生的,又是由誰來維護(hù)的呢?由在國際上,有一個由Sun主導(dǎo)的標(biāo)準(zhǔn)化組織JCP(Java Community Process),該組織根據(jù)領(lǐng)域的不同,分為三個大的工作方向,即J2EE,J2SE和J2ME。而J2ME領(lǐng)域的標(biāo)準(zhǔn)的制定者,包括業(yè)界知名的運營商,如Vodafone,Orange,中國移動等;終端制造商,如Nokia,Motorola,Sumsung等;提供Java虛擬機(jī)的廠商,如IBM、Aplix、Esmertec等;以及一些感興趣的公司團(tuán)體。
JCP中的每個規(guī)范被稱為JSR(Java Specification Request)。各個JSR分別從不同的角度對Java虛擬機(jī)的能力進(jìn)行了規(guī)范,并對應(yīng)一個數(shù)字編號,如JSR75規(guī)定了Java應(yīng)用如何通過虛擬機(jī)提供的接口訪問終端操作系統(tǒng)的PIM數(shù)據(jù)和文件系統(tǒng)。此外,還包括針對對藍(lán)牙、多媒體、短信、彩信等的JSR。而這些規(guī)范的發(fā)布、更新和維護(hù)由JCP來統(tǒng)一管理,確保了讓業(yè)界不同角色的廠商能夠共同參與定義J2ME平臺的能力,共同推進(jìn)Java技術(shù)向前發(fā)展。
雖然Java是本著跨平臺的目的而產(chǎn)生的技術(shù),但是在移動終端領(lǐng)域卻沒能完全實現(xiàn)這一宏偉的目標(biāo)。由于設(shè)備沒有一個統(tǒng)一的標(biāo)準(zhǔn)的軟件運行環(huán)境,導(dǎo)致了API的分裂。開發(fā)者在針對某些機(jī)型進(jìn)行開發(fā)之前還必須要查詢這個設(shè)備到底支持什么功能,有哪些是標(biāo)準(zhǔn)的API,哪些是可選包和廠商提供的API。這無疑給開發(fā)帶來了不便,同時使得程序的可移植性大大降低。如果你得程序中使用了Nokia的API那么程序很難在其他廠商的機(jī)器上跑。所以,J2ME在不同的移動終端平臺上由于實現(xiàn)的不同而造成的分裂局面成了待解決的問題。
#p#
J2ME發(fā)展的里程碑
為了解決如上的問題,在J2ME的發(fā)展過程中,產(chǎn)生了以下幾個具有里程碑意義的JSR:
1. JSR185 -- JTWI(Java Technology of Wireless Industry)
該規(guī)范于2003年7月發(fā)布。JTWI并沒有提出新的技術(shù),也沒有提供新的API,它對J2ME的運行環(huán)境作了規(guī)范,提供了一個標(biāo)準(zhǔn)的更加嚴(yán)格的運行環(huán)境,這有效地減小了API的分裂并提高了程序的可移植性。JTWI包含以下規(guī)范:
JSR30 -- CLDC1.0:提供了基本的語言類庫,但是不支持浮點運算??梢杂肅LDC1.1替代1.0;
JSR118 -- MIDP2.0 :提供了圖形用戶界面、持久性存儲、游戲和多媒體等功能模塊的支持;
JSR120 – WMA (Wireless Messaging API):提供了短消息功能的支持
JSR135 – MMAPI (Mobile Media API):提供了對多媒體的全面支持,MIDP2.0中的多媒體部分是MMAPI的子集,該規(guī)范是JTWI中可選的部分。
JTWI的體系架構(gòu)如圖2所示。
2. JSR248 – MSA1.0 (Mobile Service Architecture 1.0)
該規(guī)范于2006年12月發(fā)布,由于JSR185是針對當(dāng)時的市場狀況而制定的,主要針對低端市場,而終端的硬件能力是一直不斷的往前發(fā)展的,所以JSR248制定的初衷就是為了滿足不斷發(fā)展變化的市場需求,增加了能充分體現(xiàn)新上市的終端的硬件能力的需求。JSR248在JSR185架構(gòu)的基礎(chǔ)上,增加了新的JSR,在充分考慮到市場現(xiàn)狀的同時,也對未來的市場發(fā)展做了預(yù)測,所以在規(guī)范的制定上留了一定的空間,延長了規(guī)范的生命周期。這些變化,在規(guī)范上具體體現(xiàn)在架構(gòu)設(shè)計上。JSR248規(guī)定了兩個級別的架構(gòu),MSA Subset和MSA,如圖3所示。
除此之外,對其架構(gòu)中包含的每一個JSR,MSA1.0都做了相應(yīng)的澄清,例如,在CLDC中規(guī)定,分配給虛擬機(jī)的堆大小為32k字節(jié),而隨著終端能力的發(fā)展,32k字節(jié)的堆大小已經(jīng)不再是瓶頸,而且這樣的大小,已經(jīng)不足以支持一些游戲和多媒體類應(yīng)用的流暢運行,所以,在MSA1.0里面,對CLDC做了將堆大小調(diào)整為1024k字節(jié)的澄清,充分滿足了應(yīng)用的需求,同時也有利于Java業(yè)務(wù)的開展。
圖3 JSR248 MSA1.0體系架構(gòu)圖 -- 終端能力
如果說圖3是從終端能力的角度對JSR248進(jìn)行了表示,那么圖4則從不同功能的角度對JSR248進(jìn)行了另一種表示,可以看出,JSR248在制定的過程中,比較全面的考慮到了多元化的功能,如安全和電子商務(wù),圖形處理,多種通信方式,用戶的個人信息等。
圖4 JSR248 MSA1.0體系架構(gòu)圖 – 功能范圍
#p#
J2ME編譯技術(shù)的發(fā)展
因為Java語言的設(shè)計初衷是使用解釋的方式支持應(yīng)用程序的可移植性,早期 Java 運行時的性能級別遠(yuǎn)低于C和C++之類的編譯性語言。而Java 應(yīng)用程序的性能也經(jīng)常成為討論的熱點。如圖5所示,Java虛擬機(jī)每次遇到一條字節(jié)碼指令,就將其轉(zhuǎn)換成機(jī)器碼,然后給CPU進(jìn)行執(zhí)行,執(zhí)行完機(jī)器碼之后,就把這些機(jī)器碼丟了,接著再翻譯下一條字節(jié)碼的指令,繼續(xù)下去,如此這般,自然效率低下。
近年來,為了提升Java的性能,在編譯技術(shù)方面有了一些新的突破,這一節(jié)將介紹一些比較流行的編譯技術(shù)。
1. JIT(Just In Time)編譯方法
從傳統(tǒng)的虛擬機(jī)處理字節(jié)碼的過程可以看出,即使下次執(zhí)行到以前執(zhí)行過的 bytecode 指令,依然要重新翻譯成機(jī)器碼才能執(zhí)行,如此一來,效率當(dāng)然不好。JIT編譯方法的原理是,程序運行時,JIT 編譯器選擇將最頻繁執(zhí)行的方法編譯成本地代碼。運行時才進(jìn)行本地代碼編譯而不是在程序運行前進(jìn)行編譯(用 C 或 C++ 編寫的程序正好屬于后一情形),保證了可移植性的需求。
Java 運行時供應(yīng)商開發(fā)了一些復(fù)雜的動態(tài)編譯器,通常稱作JIT(Just-in-time,JIT)編譯器。程序運行時,JIT 編譯器選擇將最頻繁執(zhí)行的方法編譯成本地代碼,運行時才進(jìn)行本地代碼編譯而不是在程序運行前進(jìn)行編譯(用 C 或 C++ 編寫的程序正好屬于后一情形),保證了可移植性的需求。以后再次執(zhí)行到這里時,就不用再翻譯,直接從內(nèi)存取出機(jī)器碼即可執(zhí)行。這么一來,只要內(nèi)存夠大,JIT 編譯器的技術(shù)夠好,那么Java 字節(jié)碼的執(zhí)行速度也可以逼近純編譯式的語言。
2.AOT(Ahead Of Time)編譯方法
雖然 JIT 編譯技術(shù)已經(jīng)能夠提供與靜態(tài)語言性能相當(dāng)?shù)男阅芩?,但是動態(tài)編譯并不適合于某些應(yīng)用程序,如 GUI 接口之類交互式應(yīng)用程序就是這樣的例子。在這些情況下,AOT編譯可能是合適的解決方案。該方法的原理是,在程序執(zhí)行前生成 Java 方法的本地代碼,以便在程序運行時直接使用本地代碼。目的在于避免 JIT 編譯器的運行時性能消耗或內(nèi)存消耗,或者避免解釋程序的早期性能開銷。
J2ME未來的發(fā)展趨勢探討
從本文的分析可以看出,不管是標(biāo)準(zhǔn)化組織、終端廠商、運營商,還是應(yīng)用開發(fā)者,都在促進(jìn)J2ME跨平臺特性,減少各平臺間的分裂性,繁榮Java應(yīng)用方面,做出了不少努力。而作為Java業(yè)界的領(lǐng)頭羊,Sun Micro Systems也計劃打造一款整個操作系統(tǒng)都是由Java實現(xiàn)的純Java終端,而ARM公司也有推出專門針對Java 指令的加速芯片,通過硬件加速來提高Java的執(zhí)行效率。由此可見,雖然目前J2ME還沒有***地實現(xiàn)跨平臺性和執(zhí)行的高效性,相信隨著業(yè)界的共同努力,Java的發(fā)展空間會越來越大。
【編輯推薦】