谷歌（Google）的Andr​​oid是针对可携式装置所提出的软体平台（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资料库、Web​​Kit网页排版引擎等，这些绿色软体元件是以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

应用程式框架层、应用程式层

以蓝色的Andr​​oid类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抱持过度可行性与过度信心。