初步接觸Android，自己嘗試做了幾個DEMO，感覺到很興奮。剛剛翻開書的時候，看到Android的五個部件，加上一些文字的描述，感覺很抽象，似乎這個程序不好開發，當我開始動手做了第一個demo之后，就深深的被Android的開發模式吸引了，個人理解是按照Android的開發模式開發了之后放到JAVA編譯器，然后再經過DX編譯器編譯最后簡單的部署到手機上。我曾是一個Web開發工程師，非常熟悉基于C#的網絡開發，也曾經接觸過普元的SOA開發，其實他們之間都有一些類似之處。ASP.net也是將aspx先轉為C#的代碼然后轉換到MSIL中去，普元的SOA是自己擴展了Eclipse的插件，然后把一些編程模式放到工具去，通過普元的解釋器解釋成java代碼然后轉換成字節碼，但是這個解釋器做的相當不完善，同時java的中間編譯經常出錯，而且速度還跟不上來。

手機是一種特殊的設備，因為它資源的有限性，使得它運行的程序都有很大的限制，開發程序的時候必須考慮到它的硬件。以Sun為主的Java陣營提出了J2ME的開發模式，充分的考慮了開放性和兼容性，于是廣博的胸懷得到了業界的認可，但是卻沒有得到業界的大力推動，J2ME僅僅是附屬于各大手機操作系統的一個小產品，它的功能僅僅在提供非主流的程序應用，并不是工程師們不想去做，而是他天生就是作為一門錦上添花的工具來設計的，http://rgruet.free.fr/public/BD-J/，因為JAVA本來就是設計在一個沙箱里頭的，所以J2ME只能獲得有限的能力，不管是CLDC1.0還是CLDC1.1，區別只在CLDC支持浮點數運算，以及支持浮點數運算的相關的方法的支持，盡管MIDP的出現能夠使得圖形圖像的變化變得更加容易，更加適合做游戲，但是還是無法變成主流的MMI的開發語言。

由于本人對MMI的基礎才剛剛開始，對MMI的理解還不夠深刻，但是覺得Java在手機MMI的出現還是不太現實的，因為畢竟JAVA的執行還必須有一個VM的支持，一般來說這個VM是獨立于手機操作系統的，本來手機的操作系統就很受局限，主要有多任務的操作系統和非多任務的操作系統，有的可能是簡單的任務調度系統，在這樣的機器上就不可能對VM以及java有太多的幻想。

現在出現的主流的智能手機的操作系統像Nokia的Symbian，MS的Windows Phone/Windows Mobile，Plam的PlamOS，Moto使用的ucLinux，BlackBerry的blackberry，IPhone的mac，Android大系的Android系統大部分是基于C/C++來開發的，MMI似乎都沒有用java的，這就是由于主流的Java移動開發的天生的定義而導致的。無論是智能機還是非智能機，對于java的描述都是Java擴展，這個擴展就意味著Java不能登大雅之堂。結合我們對java的用戶體驗來說，java程序的用戶體驗一般來說都是比較糟糕的，就移動開發而言，每次運行java程序，都需要一個較長的加載時間和退出的時間，相比起其他程序，這在用戶體驗中就相當的不利，而且遇到異常的是總是哐當一下就彈出一個莫名的窗口死掉了，這樣的人機交互是相當糟糕的。

這或許跟Sun推行的Java策略在市場上不太好的緣故，對Java缺乏一個大的愿景，不斷的有組織開會提議加一個JSR，然后就費了很長時間制定一個JSR，而且這個JSR往往在敲定的時候又已經落伍了。前段時間看到一幅漫畫，心中真是難受，那幅漫畫說的是Duke（Java的吉祥物，有個紅鼻子的小家伙）站在Sun的墓碑前掉淚。雖然Java作為現在最廣泛使用的編程語言，就移動這一塊來說，真的很有局限。

操作系統和VM的結合是Java受阻的原因之一，.Net戰略的優勢也在于在Windows Mobile里頭有一個很好的CLR。或許你有一個這樣的用戶體驗，在Windows上運行的程序，Java寫的往往要感覺比.net寫的運行得慢，就是因為CLR是對操作系統和硬件做了優化的，而JVM必須支持通用的操作系統和通用的硬件，毫無疑問地說，Eclipse是一個非常優秀的使用java來寫的IDE。因此MS的Windows Mobile的優勢在于，只要.Net Framework有什么新的東西，對應的CF就有新的東西，而且Windows的UI已經讓人非常習慣了。

對于Java來說，除了Sun推出一個Solaris的移動版，有可能會使得Java變成手機移動開發的主力軍，但是他沒有。所以希望Symbian，ucLinux去完成這件事，事實證明，這個使命沒有完成。就用戶體驗來說，對于許多中低端的用戶會非常喜歡Nokia，就一個終端用戶而言，不期待能用手里微薄的工資買一個iPhone，Nokia的高端機，Nokia的市場戰略非常出色，就我自己而言，用過幾大牌子的手機，最后還是愿意情歸Nokia，就是因為它的MMI做的人性化。從網上的消息得知，Android的機器的售價應該是iPhone的一半，或者還能有所下降，相信它的市場會因為它友好的MMI見長。

Android在MMI開發中引入了Java，這個時候的Android并沒有拘泥于J2ME的一些死板的JSR，構建在Linux上的Android使用了一個相當優秀的操作系統，就內核而言Linux無疑是業界承認是相當穩定的。見網上的一篇帖子，說有公司對比了Android內核和標準的2.6.25版本的Linux內核，發現了Google修改了75個文件，增加了88個文件，該公司還對這些文件都做了對應的注釋，其中為Glodfish增加了44文件，這個是虛擬機的虛擬CPU，模仿的是ARM926t；為YAFFS2修改了35個文件，因為增加了對NANDFLASH的支持；為藍牙修改了10個文件；為調度器修改了進程調度和時鐘相關策略，5個文件；為Android的新子系統增加了28個文件，有IPC Binder，運行的進程能為其他進程提供服務，這個功能已經在Plam的軟件里被使用了；Low Memory Killer是在內存緊張的時候根據策略關閉某些程序的功能，內核有實現，Google重寫了；Ashmem，匿名共享內存，多個程序可以使用這個共享內存獲取信息；RAM Console and Log Device，Android增加的日志模塊；Android Debug Bridge，Android的調試工具；還有Realtime clock，timed GPIO等；Google還重寫了電源管理，文檔說，這個是最復雜難度最高的一個功能，放棄了APM、DPM；此外還有36個文件被修改了，設計Android的許多小功能。不過因為Android的內核屏蔽了太多的硬件驅動，會對很多Linux的硬件企業造成堡壘，Linux的內核維護者宣布將Android核心代碼從Linux內核中刪掉，同時很多企業正試圖從他們的代碼庫中去除Android的代碼。因此，Android的發展也不是一帆風順的，但是它漂亮的MMI是各大廠商都不愿意放棄的，因為實在沒有多少個廠商能做到這樣的一個系統而且還開源，縱然有缺點，我們也要包容這個可愛的綠色機器人。

一個強大的內核支持下的手機操作系統，相當的健壯，至少在底層是相當的強壯。仔細觀察Android的架構圖，藍色的部分是用Java來寫的，綠色的部分使用C/C++來寫的，紅色的部分是采用C來寫的，黃色的部分是采用Dalvik虛擬機來寫的。看Libraries是和Android Runtime在同一層，而且Android Runtime和Linux Kernel是沒有交集的，而是直接嵌入到Libraries的。我猜想，Android Runtime的Core Libraries，應該是利用native關鍵字引用Libraries的C/C++的函數，通過Dalvik虛擬機再編譯完后調用Libraries的函數。經過我對源碼的閱讀，的確發現有許多標有native關鍵字的方法。不得不相信Dalvik是一個非常優秀的虛擬機，否則是不足以完成這些工作的。

Dalvik虛擬機是Google的Android團隊的工程師設計的，和傳統的JVM不一樣的是，Dalvik虛擬機是基于寄存器的架構，而普通的虛擬機用的是基于棧的架構。在這里穿插一下虛擬機的設計方法，虛擬機既然被稱作機器，就是因為其輸入時滿足某種命令集架構的指令序列，中間轉為某種指令集架構的指令序列并加以執行，主要分為基于寄存器的設計和基于棧的設計，現在出現的大部分的虛擬機采用的都是基于棧的設計，虛擬機模擬的是硬件，從硬件來看，現在的CPU采用的都是基于寄存器的設計，其實也就是說采用寄存器的設計是有優勢的，但是為什么虛擬機都不采用寄存器的設計呢？首先，使用基于棧的架構的話，指令會變得簡單，不需要考慮指令中的源寄存器和目標寄存器，不需要考慮為臨時變量分配空間，求值的時候開辟棧空間就好了；此外，使用基于棧的架構用的是零地址指令，這樣的話比其他的指令形式更緊湊，節省資源；另外，考慮到移植性，即使是基于寄存器的架構的CPU，寄存器的個數也不一樣，32位X86的通用寄存器就只有8個，而32位的ARM處理器就有16個通用寄存器，然而SPARC卻有24個通用寄存器。假使一個虛擬機采用基于寄存器的架構，為了高效執行一般會希望把源架構的寄存器映射到實際機器的寄存器上，如果源架構的寄存器比實際機器的寄存器要多的話，寄存器就不能一一映射了，效率上肯定打了折扣，然而使用基于棧的架構的話，在實現虛擬機的時候就比較好分配實際機器的寄存器，作為優化，基于棧的虛擬機可以采用編譯的方法實現。

Dalvik虛擬機的許多設計是考慮到與JVM的兼容性的，采用了基于寄存器的架構，指令碼采用二地址和三地址混合形式，目標機器架構明確，主要是針對ARM處理器的支持，ARM9有16個32位通用寄存器而Dalvik虛擬機也是用16個虛擬寄存器，因此它也不需要考慮很多可移植性的問題，優先考慮在ARM9上以高效的方法的實現，這個戰略和微軟的技術戰略是非常象的。

看以下代碼：

經過javac的編譯后，可以看到Demo.class的foo（）的代碼是：

接著使用Android SDK的tools目錄里頭的工具dx工具，這里是SDK的tools不是根目錄的tools文件件，這個DX工具可以是Android 1.5/1.6/2.1的，使用DX工具來講Demo.Class轉化為dex格式，轉換的時候可以直接以文本的形式dump出dex的內容，使用下面的命令：

可以看到foo()的字節碼是：

另外Dalvik的.dex問價在未壓縮的狀態下的體積通常比同等內容的.jar問價在deflate壓縮后還要小，但是光從字節碼來看，java的字節碼總是要比dex的小，這主要是.dex使用了共享的常量池，使得相同的字符串數字常量只會出現一次有效的壓縮了文件的大小，不過在JSR200也提到了這樣的壓縮方法。

回到五彩斑斕的Android架構圖上，剩下的兩層都是純藍色的，一層是Application Framework，一層是Applications。我們經常說的使用Eclipse結合ADT開發的是Applications層，它的開發模式和眾多的功能是由Application Framework來支持的，我猜想應該這兩層就是Android的MMI了吧，這兩層都是純JAVA來開發的，這兩層的資料相當的多。應該贊嘆一下這個框架，因為這個框架下的人機交互相當的友好，看起來讓人賞心悅目，雖然很多公司都在做手機的MMI，能做得如此人性化的真的很少，而且還無私的開源。另外值得一提的是，這個框架的源代碼是開源的，但是要通過Git和repo來獲得，repo必須在linux環境執行，因為repo是個shell文件，至于Git有Windows版本的，但是在公司我下載了很久都無法連接上，不知道是不是由于公司的網絡管制比較嚴格的緣故。說起網絡的問題，Android模擬器的上網我也遲遲沒有弄成功，使用了網上說的三種方法都不成功，加上平時使用的經驗發現，除了IE，好像其他程序都無法連到外網。使用網上下載的源碼包可以在開發程序的時候看到框架的源代碼，但是網上的源碼只更新到2.0版本，一直傳聞Google沒有對2.1進行開源。從網上下載的代碼也不過只有20來兆大小，但是這20多兆的代碼沒有辦法在Eclipse里頭編譯，只能在Linux下編譯，聽說編譯的臨時文件非常大。由于沒有辦法拿到源碼和參與預編譯的文件，我也無法驗證這一說法的真偽。因為在Windows里頭搭建編譯環境也不是沒可能的，已經有高人，使用Windows的環境模擬Linux的來編譯了Android的模擬器，這個模擬器的最新代碼無法獲得，只能獲得之前的一個舊版本，我拿回來之后，按照高人的方法去編譯，果然出現高人說的一些問題，但是高人把編譯好的模擬器截圖，并說明要最新的代碼。

最后說說這個開發模式，因為這是純java的MMI，這個時候的Java就可以大顯身手，沒有J2ME的局限，也沒有沙箱，這給了Java很大的空間。由于本人之前開發過較長時間的Web程序，發現了很多很熟悉的地方，使用XML來布局可以類比JSP里頭的Html布局，使用AndroidManifest.xml來做配置文件，就像J2EE里頭的web.xml一樣規定著什么可以運行，如何去運行，還有一個自動生成的管理資源的R文件就像ASP.NET里頭自動生成的代碼，呈現和業務的分開，另外使用了SQLite，就如同在Web開發的數據庫開發一樣，和Web開發不同的是，Android 的應用開發有獨特的Service組件和Intent的消息傳遞。這樣的開發模式的好處在于每個程序都有相當大的獨立性，而且程序之間是非常平等的，這個很重要，在J2ME里頭，Java程序和其他程序可不是平等的，如果你愿意，你可重寫Android的每一個應用程序，包括撥號，短信息，聯系人等等，也給了開發人員相當大的自由度。另外，Android的Java開發使用了很多Java5的新特性，也大大的加速了java程序的開發。