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