谷歌（Google）的Android是針對可攜式裝置所提出的軟體平台（Platform），更具體說是一個軟體疊層（Software Stack），若軟硬體商均支持與遵循此平台規範，則可以達到軟硬體高度分離、分立的理想，即軟體商所開發的應用程式可以在各種支援Android的硬體上執行，達到與爪哇（Java）程式語言相同的原初理想：程式撰寫一次後，可以在各種硬體上執行，達到最精省的程式心力開發，同時讓程式的潛在執行機會達最大化。雖然Java已相當適合，然卻有開放性及版權顧慮，因此Google才決議推行Android。

Android的目標應用

Android雖以可攜式裝置為其推行目標，然本質上也適用於小型固接裝置，如數位相框（DPF）、視訊機頂盒（STB）等，不過實務上仍以可攜式裝置為主，特別以智慧型手機為主，可攜式媒體播放器（PMP）、個人導航器（PND）、個人數位助理（PDA）則次之。值得注意的是，由於2008年小筆電（Netbook）風潮興起，因此Netbook也成為高度矚目的潛在應用。

《圖一　Google Android的標誌（吉祥物？）為一個機器人》 圖片來源：Google

疊層最底層：Linux核心

瞭解Android的目標應用，即進入疊層架構的正題，整個Android平台區分成4層、5個區塊，並用不同的顏色進行標示。

首先說明紅色的最底層：Linux核心，此包含一套用於用可攜式裝置的嵌入式Linux外，其餘均為硬體裝置的驅動程式，如音訊驅動程式、Wi-Fi無線通訊驅動程式等，另也有較核心的行程間通訊（IPC）驅動程式、電源管理驅動程式。

整個Linux核心都以紅色標示，表示Linux核心的各軟體元件，均是以C語言撰寫成，整個紅色層均是由晶片業者，或可攜式裝置的系統硬體開發商所負責，即音訊晶片商在銷售音訊晶片時，也當附上Android的音訊驅動程式，而如宏達電子（HTC）之類的可攜式裝置開發商，也必須針對特有的硬體功能，而自行開發驅動程式。

《圖二　Google Android軟體疊層圖》 圖片來源：Google

函式庫層

接著是綠色的函式庫層，此處收納了諸多偏重於硬體的基礎軟體函式，如網路傳輸安全性的SSL加解密、FreeType字型、SQLite資料庫、WebKit網頁排版引擎等，這些綠色軟體元件是以C或C++語言撰寫成，並依循libc標準開發、放置。

至此有個疑問：紅色的Linux核心層，可依據不同的硬體架構與配置而進行修改、擴充，而綠色的函式庫層能否如此呢？對此答案是肯定的，然擴充與修改也必須合乎libc標準。此外，一旦對原有函式庫進行修改或擴充，則平台的移攜性（Portability）將降低，此必須事先瞭解。

《圖三　第一個支援Google Android平台的手機：宏達電子的G1》 圖片來源：英文維基百科作者Michael Oryl

Android執行階段層

與函式庫屬同層的為Android執行階段，然卻用不同的黃、藍色標示，黃色為Dalvik虛擬機器（簡稱DVM），對應至Java架構則與Java Virtual Machine（簡稱JVM）角色相同，用來執行中介程式碼（Managed Code）。

DVM與作業系統有相依性，換不同的作業系統必須再行調修，才能達到最佳化表現。不過，DVM的諸多特性都需要倚賴Linux才能發揮（如多行程執行），因此DVM多只能在不同的Linux上執行，而不易在其他類型的作業系統上使用，此點與Java不同。

在黃色區塊內另有一個藍色的核心函式庫，該函式庫是以Android的類Java語言所寫成（撰寫語法上約有85％～90％相似度），事實上更上的兩層藍色層，其元件亦同樣以Android的類Java語言所寫成，只是核心函式庫屬更例行、常用的共同函式。

要注意的是，Android執行階段無法直接與紅色層溝通聯繫，而是凡事都要透過其左側的綠色函式庫層代勞才行。

《圖四　Android採行與Java類似的語法》 圖片來源：Google

應用程式框架層、應用程式層

以藍色的Android類Java語言撰寫成的軟體元件即具有移攜性，即無論Android的硬體設計如何改變，藍色軟體部分均不需要修改，即可在不同的硬體上執行。相對的，紅色、綠色、黃色層則具有硬體相依性，不同的硬體需要不同的編譯、調修，甚至可運用硬體電路方式使此三者加速執行。

雖然藍色層具硬體平台移攜性、硬體中立性，然在Android平台上仍將藍色層區分為二，經常使用且需要統整一致性者，即歸屬至應用程式框架層，另一則是應用程式層，應用程式層的各應用程式即是應用創意的發揮場所，各應用程式可有極大的差異，而非追取一致。

另外，應用程式可呼用應用程式框架中的軟體元件為其服務，同時也可呼用Android執行階段內的核心函式庫為其服務。

而框架層內，活動管理員（Active Manager）即類似今日Windows作業系統內的事件管理器，負責應用程式上的操作事件（如一個按鈕被按、一個手寫輸入被辨識完成等）；視窗管理員（Window Manager）則負責各應用程式的視窗畫面等。

《圖五　Android的Dex（.dex）檔內部結構》 圖片來源：Google

進階探析DVM

瞭解整體疊層後，重新對整體進行檢視，可發現整個Android平台的重點即在DVM，因為綠色函式庫中的元件，多已是業界標準（如SSL）或約定成俗的標準（如WebKit、SQLite），而紅色核心也早用於諸多的Linux嵌入式應用上，藍色應用程式層則由廣大軟體商、程式師去發揮，藍色的框架及核心函式庫則會持續透過組織程序的制訂而增長、強化。

事實上Google是在2005年7月購併Palo Alto的新創公司，取得DVM後，才能構築、提出Android。

DVM的運作方式與JVM相同，DVM的程式語言類似於Java語法，原已有撰寫Java程式經驗者可較快適應，不過Java程式寫完後，於執行會轉譯成Byte Code的中介碼。同樣的，Android的類Java語法也會譯成其獨有的中介碼，此中介與Java Byte Code全然不同。

除語法相近、譯出的中介碼截然不同外，Android也不能使用Java的類別檔，而是自己獨特的.dex檔，所以若有程式師想直接把以前撰寫過的Java程式，直接重新編譯成Android可執行的程式，是不可能的，依然只能保有程式的邏輯、演算法，然後重新以Android、DVM作法重新撰寫才行。不過Android仍提供一個名為dx的工具程式，可將Java類別檔轉譯成.dex檔。

既然DVM與JVM如此相像，除開放性、版權問題外，是否仍以Java較合適？

其實不然，DVM作法的執行比Java更快速、更安全，DVM是以暫存器為基礎執行，即程式執行時的相關變數是放在暫存器中，相對的，JVM是堆疊為基礎的執行，變數存取需要透過Push、Pop等手續，速度不如DVM。

而安全性上，DVM讓每個應用程式均以一個行程來執行，如此某一應用程式因撰寫不良或外在因素而當機，則其當機問題不擴散、殃及DVM，DVM依然可正常執行其他應用程式。相對的，Java程式若發生問題，並導致JVM停擺，則其他的Java應用程式也將一同停擺。

《圖六　Dex檔與Java類別檔的結構對應》 圖片來源：Google

結語

DVM的相關技術特性與應用程式開發者密切相關，然對於想開發支援Android的硬體晶片商、系統商而言，則較在意紅色、綠色區塊。

紅色、綠色區塊除了可運用硬體電路獲取加速（以硬體加速執行，通常也意味著能比純軟體方式執行精省功耗）外，另一關注重點是能否換用不同的處理器架構。

對此其實具技術難度，Android目前是以ARMv5指令集架構的處理器（或稱執行單元、核心）為最低要求，雖然Android未硬性規定不可改用其他指令集架構的處理器，例如可用更前期的ARMv4指令集架構處理器，或可用於x86、MIPS等不同於ARM架構的處理器。

此外，紅、綠層是以C/C++語言寫成，重新編譯（Recompile）後即可在另一種架構的處理器上執行。然重點在於：重新編譯只擔保另一處理器能功效無誤地執行原程式，但卻不易做到效能最佳化，使程式流暢執行。

這也是今日許多技術狂熱者，雖將Android重新編譯成可在Eee PC（x86架構）執行、可在我本墨客（OpenMoko）手機（ARMv4）執行，但此作為僅能視為特技表演，難以普及，原因即在於效能最佳化不足，程式無法流暢執行、反應。

至此可以得出一些建議，一是不要天真認為Android語法類似Java，即可快速將原有Java程式進行移植，過程中仍需要發展、轉換心力。另一是Android現階段以ARMv5以上處理器為發展主力，其他架構處理器仍需自行強化精進執行效率。

另外現階段Android以可攜式產品應用為主，並以智慧型手機為主，另也可能跨入Netbook，其他的相關應用則為其次，若期望用Android發展其他應用，也同樣需要自行承擔較多的技術心力，這些在投入Android發展前須有所考慮，而不能對Android抱持過度可行性與過度信心。